Developing/compiling software
in [Embedded]
|
From: ChrisQ on 25 Sep 2009 09:56 FreeRTOS info wrote: > > GCC and IAR compilers do very different things on the AVR - the biggest > difference being that IAR use two stacks whereas GCC uses one. This > makes IAR more difficult to setup and tune, and GCC slower and clunkier > because it has to disable interrupts for a few instructions on every > function call. Normally this is not a problem, but it is not as elegant > as the two stack solution for sure. GCC is very popular on the AVR > though, and is good enough for most applications, especially used in > combination with the other free AVR tools such as AVRStudio. > Can you elaborate a bit as to why 2 stacks are used with IAR ?. Haven't user avr, so have no real experience. The AVR 32 has shadow register sets, including stacks for each processor and exception mode. Thus, separate initialisation on startup, but so do Renasas 80C87 and some arm machines. How does gcc work for arm, for example ?. Regards, Chris
From: Grant Edwards on 25 Sep 2009 11:49 On 2009-09-25, ChrisQ <meru(a)devnull.com> wrote: > If this is a chess game :-). Is the issue that you should > declare conflicts of interest when expressing opinions about > proprietary products. No reason to do so otherwise... I'm not talking about expressing opinions. I'm talking about being actively involved in working with/on open-source tools and attempting to hide one's affilliation while doing so. It turned out the maintainer of one of the key libraries that was holding back progress in the effort to support JTAG debugging was a TI employee who didn't disclose the fact and declined to answer when asked directly. Offers to help with development of the library (even if it required signing an NDA) or offerst to beta-test the library were ignored. I can't speak for others involved, but that left a pretty bad taste in my mouth. -- Grant Edwards grante Yow! This PORCUPINE knows at his ZIPCODE ... And he has visi.com "VISA"!!
From: ChrisQ on 25 Sep 2009 11:28 Grant Edwards wrote: > On 2009-09-25, ChrisQ <meru(a)devnull.com> wrote: > >> If this is a chess game :-). Is the issue that you should >> declare conflicts of interest when expressing opinions about >> proprietary products. No reason to do so otherwise... > > I'm not talking about expressing opinions. I'm talking about > being actively involved in working with/on open-source tools > and attempting to hide one's affilliation while doing so. > > It turned out the maintainer of one of the key libraries that > was holding back progress in the effort to support JTAG > debugging was a TI employee who didn't disclose the fact and > declined to answer when asked directly. > > Offers to help with development of the library (even if it > required signing an NDA) or offerst to beta-test the library > were ignored. > > I can't speak for others involved, but that left a pretty bad > taste in my mouth. > Wasn't implying criticism - just my warped sense of humour found the thread amusing for some reason ~). Can't comment on TI, but they all have agendas and usually the bigger they are the worse they can be. Add to that the infantile postering and arrogance of some of them and it's off to the next vendor if possible. Some of the worst are those who don't want to deal with you as a small company, or a bit offbeat, but are all over you if you mention the client. I feel it's unethical and should never have to do it, but sometimes you have to pull rank just to get stuff done. I really can't be bothered with "front". The recommendation in all such cases is for the client to look elsewhere in the future. Business depends on mutual trust and cooperation and breaks down if one side or the other is being devious or economical with the truth. Having said that, there are some really good companies out there who have brilliant resources and are easy to do business with. I guess you have to accept that some vendors and individuals are just hard work and learn to live with it or leave it :-)... Regards, Chris
From: FreeRTOS info on 25 Sep 2009 12:22 "ChrisQ" <meru(a)devnull.com> wrote in message news:sK4vm.199649$AC5.36013(a)newsfe06.ams2... > FreeRTOS info wrote: > >> >> GCC and IAR compilers do very different things on the AVR - the biggest >> difference being that IAR use two stacks whereas GCC uses one. This >> makes IAR more difficult to setup and tune, and GCC slower and clunkier >> because it has to disable interrupts for a few instructions on every >> function call. Normally this is not a problem, but it is not as elegant >> as the two stack solution for sure. GCC is very popular on the AVR >> though, and is good enough for most applications, especially used in >> combination with the other free AVR tools such as AVRStudio. >> > > Can you elaborate a bit as to why 2 stacks are used with IAR ?. Haven't > user avr, so have no real experience. The AVR 32 has shadow register sets, > including stacks for each processor and exception mode. Thus, separate > initialisation on startup, but so do Renasas 80C87 and some arm machines. > How does gcc work for arm, for example ?. I have not gone back to check, but from memory (might not be completely accurate) the AVR uses two 8 bit registers to implement a 16 bit stack pointer. When entering/exiting a function the stack pointer has to potentially be updated as two separate operations, and you don't want the update to be split by an interrupt occuring half way through. -- Regards, Richard. + http://www.FreeRTOS.org Designed for Microcontrollers. More than 7000 downloads per month. + http://www.SafeRTOS.com Certified by T�V as meeting the requirements for safety related systems
From: Niklas Holsti on 25 Sep 2009 12:55
FreeRTOS info wrote: > > "ChrisQ" <meru(a)devnull.com> wrote in message > news:sK4vm.199649$AC5.36013(a)newsfe06.ams2... >> FreeRTOS info wrote: >> >>> >>> GCC and IAR compilers do very different things on the AVR - the >>> biggest difference being that IAR use two stacks whereas GCC uses >>> one. This makes IAR more difficult to setup and tune, and GCC slower >>> and clunkier because it has to disable interrupts for a few >>> instructions on every function call. Normally this is not a problem, >>> but it is not as elegant as the two stack solution for sure. GCC is >>> very popular on the AVR though, and is good enough for most >>> applications, especially used in combination with the other free AVR >>> tools such as AVRStudio. >>> >> >> Can you elaborate a bit as to why 2 stacks are used with IAR ?. >> Haven't user avr, so have no real experience. The AVR 32 has shadow >> register sets, including stacks for each processor and exception mode. >> Thus, separate initialisation on startup, but so do Renasas 80C87 and >> some arm machines. How does gcc work for arm, for example ?. > > > I have not gone back to check, but from memory (might not be completely > accurate) the AVR uses two 8 bit registers to implement a 16 bit stack > pointer. When entering/exiting a function the stack pointer has to > potentially be updated as two separate operations, and you don't want > the update to be split by an interrupt occuring half way through. Adding a bit to Richard's reply: The AVR call and return instructions update the 16-bit "hardware" stack pointer (to push and pop the return address) but they do so atomically, so they don't need interrupt disabling. But gcc uses the "hardware" stack also for data, and must then update the stack pointer as two 8-bit parts, which needs interrupt disabling as Richard describes above. The IAR compiler uses the AVR Y register (a pair of 8-bit registers making up a 16-bit number) as the stack pointer for the second, compiler-defined "software" stack. IAR still uses the hardware stack for return addresses, so it still uses the normal call and return instructions (usually), but it puts all stack-allocated data on the software stack accessed via the Y register. The AVR provides instructions that can increment or decrement the Y register atomically, as a 16-bit entity, and the IAR compiler's function prologues/epilogues often use these instructions. However, sometimes the IAR compiler generates code that adds or subtracts a larger number (> 1) to/from Y, and then it must use two 8-bit operations, and must disable interrupts just as gcc does. Conclusion: the frequency of interrupt disabling is probably less in IAR-generated code than in gcc-generated code, but the impact in terms of an increased worst-case interrupt response latency is the same. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . |