mixing C and assembly
in [Embedded]
|
Prev: Loop back fails
Next: china wholesale cheap nike air max 87 90 95 ltd tn shoes bapesta hogan sneakers china suppliers www.voguesonline.net
From: Mark Borgerson on 23 Apr 2008 21:43 In article <480F499B.70EA80B4(a)bytecraft.com>, walter(a)bytecraft.com says... > > > Mark Borgerson wrote: > > > In article <480F2B12.69B62031(a)bytecraft.com>, walter(a)bytecraft.com > > says... > > > > > > > > > Chris H wrote: > > > > > > > As has already been mentioned the start up code has to be in assembler > > > > as it sets up the memory for the stack etc however if you use the > > > > standard one that comes with the compiler you will never need to see it. > > > > > > There is no requirement for the start up code to be in asm. A lot of > > > compilers come with asm sample startup but the code could have > > > been written in C in the same compiler. The same extensions that > > > support embedded systems make this possible > > > > Just out of curiosity, how do you set the initial value of the > > stack pointer in C? > > Most embedded systems compilers have extensions that > support processor register access. A lot of the compilers > were implemented from hosted compilers as a base and the > initial startup code was written before they added support > for processor access. The example startup has often been > this early code. My point is that it can be done in C. > > In our case the first C compiler was written for the C6805 > and that was based on a 6805 mistral compiler we had written > a few years earlier. Our initial startup code was written > in C on a compiler that would support it. > > register_sp SP; > > SP = int_value; > I must be using the wrong compilers! ;-) Imagecraft for the MSP430, IAR for the ARM, IAR for the MSP430 and Codewarrior for M68K systems all seem to use an assembly-language routine for initial setup. In the case of the Atmel ARM chips, there's also some memory chip selects and block remapping to do. Thankfully, you generally don't have to touch that code unless, as I have, you need a custom memory map to separate a boot monitor from the user application. Mark Borgerson
From: Mark Borgerson on 23 Apr 2008 21:50 In article <f9b88f12-3621-441c-ad80-1db7328f7621 @b64g2000hsa.googlegroups.com>, compton75(a)hotmail.com says... > On Apr 22, 3:50 am, Lax <Lax.Cla...(a)gmail.com> wrote: > > Are there any situations where programming an embedded processor > > "requires" at least some assembly code? > > > > How about for AVR, MSP430, 68HC11, 8051(Atmel)? > > Can these 4 microcontrollers be programmed fully in C without touching > > assembly (even interrupts and etc.)? > > Can't interface with with external hardware without assembly. > > Why not? With memory-mapped peripherals all you need to do is define the proper pointer values to access the hardware registers. I've done it that way for UARTS and USB devices on ARMS and M68Ks for years. You can even set up the chip selects using their memory-mapped control registers. Mark Borgerson
From: Grant Edwards on 23 Apr 2008 21:56 On 2008-04-24, Paul Keinanen <keinanen(a)sci.fi> wrote: >>Are there any situations where programming an embedded processor >>"requires" at least some assembly code? >> >>How about for AVR, MSP430, 68HC11, 8051(Atmel)? >>Can these 4 microcontrollers be programmed fully in C without touching >>assembly (even interrupts and etc.)? > > Why do you ask this ? > > Do you expect that you could work with embedded systems > without learning anything about the hardware architecture and > the processor instruction set ? > > Most embedded project could be written completely in C except > for the initialization code, possibly some interrupt preamble > code, OS task switching and the use of some processor specific > special instructions. In most cases this would be 1-2 pages of > assembler code. > > However, if you are developing embedded applications in C or > in other high level languages, you really have to understand > what machine instructions are generated and what resources are > needed for a specific construction. <lecture> I don't think it's possible to emphasize that last point enough. Especially if you're developing for a small processor you're never going to be very successful if you don't know how the code generation differs for logically equivalent blocks of code. For example, two ways to sum the bytes in a buffer: unsigned char buf[128]; unsigned sum = 0; unsigned i; for (i=0; i<sizeof buf; ++i) sum += buf[i]; unsigned char *p; p = buf; while (p < buf + (sizeof buf)) sum += *p++; Those two blocks of code do the same thing. On some target/toolchain combinations, they're both about the same number of bytes/clocks. On some platforms I've used the first was significantly smaller/faster. On others, the second was significantly smaller/faster. In the fist case, are you better off with an index that's an "unsigned" or an "unsigned char" or an "int"? They can be significatly different. Always pick something that will work on as many platforms as possible, but if there are multiple "correct" ways to do something, you might as well pick the one that's going to generate the smallest/fastest code for the target. If you want to be more than an amateur doing trivial projects, you've got to know your target's instruction set and know what code the compiler is going to generate each time you write a line of C. I always set up my makefile so that the toolchain produces a mixed C/assembly listing for each module. Anytime I'm not sure what the compiler is going to do with a particular construct, I look at the listing and see. </lecture> -- Grant Edwards grante Yow! I invented skydiving at in 1989! visi.com
From: Neil on 23 Apr 2008 22:26 Walter Banks wrote: > > Neil wrote: > >> Walter Banks wrote: >>> Vladimir Vassilevsky wrote: >>> >>>> You have to resort to assembly in the two special cases: >>>> >>>> 1. The system level work like switching the contexts of the tasks, C >>>> startup code, etc. >>>> >>>> 2. The parts of code where the performance is very critical. >>> In your second point I would qualify it to parts of code >>> requiring exact timing on anything that we have released >>> recently that seems to be the only limitation. >>> >>> >> Do not forget the startup code > > Our startup code is in C. > > w.. > > > I am not sure how that works. I am talking about the code that jumps to main after setting up the C environment.
From: Paul Keinanen on 23 Apr 2008 23:52
On Wed, 23 Apr 2008 20:56:28 -0500, Grant Edwards <grante(a)visi.com> wrote: >On 2008-04-24, Paul Keinanen <keinanen(a)sci.fi> wrote: >> However, if you are developing embedded applications in C or >> in other high level languages, you really have to understand >> what machine instructions are generated and what resources are >> needed for a specific construction. > ><lecture> > >I don't think it's possible to emphasize that last point >enough. > >Especially if you're developing for a small processor you're >never going to be very successful if you don't know how the >code generation differs for logically equivalent blocks of code. The situation is not so problematic with C, but if you insist of using C++ in some embedded project, you _really_ have to understand, what resources a specific construct will require on your platform. Paul |