From: Ma X. <dam...@gm...> - 2013-05-27 16:03:22
|
Hi, all. The command "sdcc foo.c" generates "foo.ihx". And "packihx foo.ihx > foo.hex" is needed to generate the .hex file. As some may know, STC-51's VB written Windows-only ISP software accepts .bin and .hex only. I have no idea about the situation of other vendors' 8051. The question is, why generates .ihx by default? Is it preferred by some programmers or some vendors' 8051? Or there are other reasons? Regards, |
From: Henry H. <he...@pe...> - 2013-05-27 18:21:40
|
I believe .ihx and .hex are the same thing. (.ihx is short for Intel Hex). Packihx just rearranges it some, making sure there aren't more than 16 bytes per line and removing redundant extended address records. The SDCC hex output is often non-contiguous and out-of-order, i.e. the addresses aren't always increasing as you go through the hex file, which I've found a bit confusing sometimes and can occasionally cause problems with naive programmer or bootloader utilities. Packihx doesn't fix that, though. You can use makebin to convert to a binary file which is contiguous. Henry On Mon, May 27, 2013 at 9:02 AM, Ma Xiaojun <dam...@gm...> wrote: > Hi, all. > > The command "sdcc foo.c" generates "foo.ihx". And "packihx foo.ihx > > foo.hex" is needed to generate the .hex file. > > As some may know, STC-51's VB written Windows-only ISP software > accepts .bin and .hex only. I have no idea about the situation of > other vendors' 8051. > > The question is, why generates .ihx by default? Is it preferred by > some programmers or some vendors' 8051? Or there are other reasons? > > Regards, > > ------------------------------------------------------------------------------ > Try New Relic Now & We'll Send You this Cool Shirt > New Relic is the only SaaS-based application performance monitoring service > that delivers powerful full stack analytics. Optimize and monitor your > browser, app, & servers with just a few lines of code. Try New Relic > and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user |
From: Georg O. <ge...@ot...> - 2013-05-27 20:26:21
|
I am experimenting with the STM8 Port of sdcc. Therefore I am porting a firmware application from IAR to SDCC. When looking at the .map File I notice that there are a lot of unused functions included. Any Idea to overcome this problem? best wishes, Georg |
From: Philipp K. K. <pk...@sp...> - 2013-05-28 14:35:12
|
On 27.05.2013 22:26, Georg Ottinger wrote: > I am experimenting with the STM8 Port of sdcc. Therefore I am porting a > firmware application from IAR to SDCC. When looking at the .map File I > notice that there are a lot of unused functions included. Any Idea to > overcome this problem? > > best wishes, Georg Just like for any other target, teh linker should do this: * Put everything from any .rel file into the result. * Take just as many modules as needed to satisfy dependencies from any .lib files and put it into the result. Can you give an example where the linker puts unused functions from .lib files into the result? Philipp |
From: Georg O. <ge...@ot...> - 2013-05-28 14:44:02
|
What I was doing - compiling a number of c-files and using sdar I put them in a lib. each .c file results in a .rel file - containing a number of functions. But it seems that final linking stage takes all functions from each .rel file. Is this observation correct? I use the "STM8 StandardPeripherals Driver" - and as a workaround a produced a "Minilib" .c-file containing only the needed functions. My code uses two Interrupt Sources UART2 RX and TIM4 OVERFLOW - it compiles without troubles but the code is not running. Any suggestions where to start looking. Code is hosted on sourceforge: http://sourceforge.net/p/oggstreamer/oggs-stm8-firmware-001/ci/master/tree/ I am using this firmware for an OpenHardware-Project called OggStreamer (http://oggstreamer.wordpress.com) - so it would be really nice to get rid of IAR-Kickstarter Version and use SDCC instead. best wishes, Georg On 28.05.2013 16:34, Philipp Klaus Krause wrote: > On 27.05.2013 22:26, Georg Ottinger wrote: >> I am experimenting with the STM8 Port of sdcc. Therefore I am porting a >> firmware application from IAR to SDCC. When looking at the .map File I >> notice that there are a lot of unused functions included. Any Idea to >> overcome this problem? >> >> best wishes, Georg > Just like for any other target, teh linker should do this: > > * Put everything from any .rel file into the result. > * Take just as many modules as needed to satisfy dependencies from any > .lib files and put it into the result. > > Can you give an example where the linker puts unused functions from .lib > files into the result? > > Philipp > > > ------------------------------------------------------------------------------ > Try New Relic Now & We'll Send You this Cool Shirt > New Relic is the only SaaS-based application performance monitoring service > that delivers powerful full stack analytics. Optimize and monitor your > browser, app, & servers with just a few lines of code. Try New Relic > and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user |
From: Philipp K. K. <pk...@sp...> - 2013-05-28 15:13:32
|
On 28.05.2013 16:43, Georg Ottinger wrote: > What I was doing - compiling a number of c-files and using sdar I put > them in a lib. > each .c file results in a .rel file - containing a number of functions. > But it seems that final linking stage takes all functions from each .rel > file. > Is this observation correct? Yes. Each .rel from the .lib is either fully included or left out. Philipp |
From: Georg O. <ge...@ot...> - 2013-05-28 18:17:33
|
Is the generation of the interrupt vector table already implemented in sdcc-stm8? On 28.05.2013 17:13, Philipp Klaus Krause wrote: > On 28.05.2013 16:43, Georg Ottinger wrote: >> What I was doing - compiling a number of c-files and using sdar I put >> them in a lib. >> each .c file results in a .rel file - containing a number of functions. >> But it seems that final linking stage takes all functions from each .rel >> file. >> Is this observation correct? > Yes. Each .rel from the .lib is either fully included or left out. > > Philipp > > > ------------------------------------------------------------------------------ > Try New Relic Now & We'll Send You this Cool Shirt > New Relic is the only SaaS-based application performance monitoring service > that delivers powerful full stack analytics. Optimize and monitor your > browser, app, & servers with just a few lines of code. Try New Relic > and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user |
From: Valentin D. <val...@gm...> - 2013-05-29 02:20:19
|
29.05.2013 01:17, Georg Ottinger пишет: > Is the generation of the interrupt vector table already implemented in > sdcc-stm8? > > > Sure. It was added in #8577. |
From: Georg O. <ge...@ot...> - 2013-05-29 08:17:15
|
i am using #8680 - I compile a number of .c files into .rel and link them afterwards. for example main.c holds the main-function. rx_ringbuffer.c the uart interrupt and led.c the timer interrupt. When looking at the final .ihx File only the RESET-Interrupt Vector is filled in with the address of the initializer code. All other interrupt vectors are 00 00 00 Source is at http://sourceforge.net/p/oggstreamer/oggs-stm8-firmware-001/ci/master/tree/ On 29.05.2013 04:20, Valentin Dudouyt wrote: > 29.05.2013 01:17, Georg Ottinger пишет: >> Is the generation of the interrupt vector table already implemented in >> sdcc-stm8? >> >> >> > Sure. It was added in #8577. > > ------------------------------------------------------------------------------ > Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET > Get 100% visibility into your production application - at no cost. > Code-level diagnostics for performance bottlenecks with <2% overhead > Download for free and get started troubleshooting in minutes. > http://p.sf.net/sfu/appdyn_d2d_ap1 > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user |
From: Valentin D. <val...@gm...> - 2013-05-29 08:22:17
|
This case is described in the section 3.9.1 of SDCC user's manual: > If you have multiple source files in your project, interrupt service > routines can be present in any of them, but a > prototype of the isr MUST be present or included in the file that > contains the function main. On 29.05.2013 15:17, Georg Ottinger wrote: > i am using #8680 - I compile a number of .c files into .rel and link > them afterwards. > > for example main.c holds the main-function. rx_ringbuffer.c the uart > interrupt and led.c the timer interrupt. > > When looking at the final .ihx File only the RESET-Interrupt Vector is > filled in with the address of the initializer code. All other interrupt > vectors are 00 00 00 > > Source is at > http://sourceforge.net/p/oggstreamer/oggs-stm8-firmware-001/ci/master/tree/ > > |
From: Georg O. <ge...@ot...> - 2013-05-29 08:31:24
|
thanks - i will try this later today On 29.05.2013 10:22, Valentin Dudouyt wrote: > This case is described in the section 3.9.1 of SDCC user's manual: >> If you have multiple source files in your project, interrupt service >> routines can be present in any of them, but a >> prototype of the isr MUST be present or included in the file that >> contains the function main. > On 29.05.2013 15:17, Georg Ottinger wrote: >> i am using #8680 - I compile a number of .c files into .rel and link >> them afterwards. >> >> for example main.c holds the main-function. rx_ringbuffer.c the uart >> interrupt and led.c the timer interrupt. >> >> When looking at the final .ihx File only the RESET-Interrupt Vector is >> filled in with the address of the initializer code. All other interrupt >> vectors are 00 00 00 >> >> Source is at >> http://sourceforge.net/p/oggstreamer/oggs-stm8-firmware-001/ci/master/tree/ >> >> > > ------------------------------------------------------------------------------ > Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET > Get 100% visibility into your production application - at no cost. > Code-level diagnostics for performance bottlenecks with <2% overhead > Download for free and get started troubleshooting in minutes. > http://p.sf.net/sfu/appdyn_d2d_ap1 > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user |
From: Georg O. <ge...@ot...> - 2013-05-29 12:40:14
|
Thanks - after putting the prototypes on the right place the prog compiles and in the hex file I see the adresses added in the vector table. Although it compiles it is not working yet ... investigating further. I feature request for the is that the unused ISR vector table entries are pointing to a function like "while(1);" - at the moment all the entries point to 00 00 00 which is the beginning of the RAM - resulting in unexpected behavior in the case of an "unwanted" Interrupt. Also investigating the vector table further - the Interrupt numbering seems to be different from IAR. - But I already stumbled upon a this issue with IAR before. I think the IAR numbering is strange ... trying further ... On 29.05.2013 10:31, Georg Ottinger wrote: > thanks - i will try this later today > > On 29.05.2013 10:22, Valentin Dudouyt wrote: >> This case is described in the section 3.9.1 of SDCC user's manual: >>> If you have multiple source files in your project, interrupt service >>> routines can be present in any of them, but a >>> prototype of the isr MUST be present or included in the file that >>> contains the function main. >> On 29.05.2013 15:17, Georg Ottinger wrote: >>> i am using #8680 - I compile a number of .c files into .rel and link >>> them afterwards. >>> >>> for example main.c holds the main-function. rx_ringbuffer.c the uart >>> interrupt and led.c the timer interrupt. >>> >>> When looking at the final .ihx File only the RESET-Interrupt Vector is >>> filled in with the address of the initializer code. All other interrupt >>> vectors are 00 00 00 >>> >>> Source is at >>> http://sourceforge.net/p/oggstreamer/oggs-stm8-firmware-001/ci/master/tree/ >>> >>> >> ------------------------------------------------------------------------------ >> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET >> Get 100% visibility into your production application - at no cost. >> Code-level diagnostics for performance bottlenecks with <2% overhead >> Download for free and get started troubleshooting in minutes. >> http://p.sf.net/sfu/appdyn_d2d_ap1 >> _______________________________________________ >> Sdcc-user mailing list >> Sdc...@li... >> https://lists.sourceforge.net/lists/listinfo/sdcc-user > > ------------------------------------------------------------------------------ > Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET > Get 100% visibility into your production application - at no cost. > Code-level diagnostics for performance bottlenecks with <2% overhead > Download for free and get started troubleshooting in minutes. > http://p.sf.net/sfu/appdyn_d2d_ap1 > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user |
From: Valentin D. <val...@gm...> - 2013-05-29 15:17:48
|
Please check that you unmasked the interrupts by using the following code: __asm; rim __endasm; 29.05.2013 19:40, Georg Ottinger пишет: > > Although it compiles it is not working yet ... investigating further. > > |
From: Georg O. <ge...@ot...> - 2013-05-29 15:47:26
|
Thanks for your thought - I decided to run a simpler programm - I took the whole project and ripped everything off until a simple LED Test is running. This test already uses a TIMER Interrupt for multiplexing the LEDs and freetimer. And it works. I will try to add bit by bit of functionality to the code back to identify the problematic sections. On 29.05.2013 17:17, Valentin Dudouyt wrote: > Please check that you unmasked the interrupts by using the following code: > __asm; > rim > __endasm; > 29.05.2013 19:40, Georg Ottinger пишет: >> Although it compiles it is not working yet ... investigating further. >> >> > > ------------------------------------------------------------------------------ > Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET > Get 100% visibility into your production application - at no cost. > Code-level diagnostics for performance bottlenecks with <2% overhead > Download for free and get started troubleshooting in minutes. > http://p.sf.net/sfu/appdyn_d2d_ap1 > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user |
From: Maarten B. <sou...@ds...> - 2013-06-01 12:07:36
|
Hi, The .ihx extension is what sdcc used since it's original start. You can override it though with the -o option. You can also use srecord (http://srecord.sourceforge.net) to create contiguous hex files (or many other types). Maarten > I believe .ihx and .hex are the same thing. (.ihx is short for Intel > Hex). Packihx just rearranges it some, making sure there aren't more > than 16 bytes per line and removing redundant extended address > records. The SDCC hex output is often non-contiguous and > out-of-order, i.e. the addresses aren't always increasing as you go > through the hex file, which I've found a bit confusing sometimes and > can occasionally cause problems with naive programmer or bootloader > utilities. Packihx doesn't fix that, though. You can use makebin to > convert to a binary file which is contiguous. > > Henry > > > On Mon, May 27, 2013 at 9:02 AM, Ma Xiaojun <dam...@gm...> wrote: > > Hi, all. > > > > The command "sdcc foo.c" generates "foo.ihx". And "packihx foo.ihx > > > foo.hex" is needed to generate the .hex file. > > > > As some may know, STC-51's VB written Windows-only ISP software > > accepts .bin and .hex only. I have no idea about the situation of > > other vendors' 8051. > > > > The question is, why generates .ihx by default? Is it preferred by > > some programmers or some vendors' 8051? Or there are other reasons? > > > > Regards, |