Getting started w/ Coldfire

So I'm considering moving over from writing assembly on the Freescale 68332 to writing C on the 5275 v2 Coldfire. I've got their M5272 dev kit in hand, and have started poking around at it in a fairly non-specific way, and have run into a few questions that I figured I'd solicit some help on.

A) So they gave me the limited trial version of CodeWarrior. Last time I did any development under CodeWarrior was about a decade ago, and I have pretty distinct memories of both the IDE and the compiler having some serious personality issues, mostly related to throwing tantrums. But 10 years is 10 years.

The other option, I suppose, is to go over to the GNU gcc Coldfire tools and makefiles and give up the IDE (which I'd shed very few tears for). Or possibly some other 3rd party build chain, if any of them are considerable over these other options. But the idea of going out and downloading trials of every compiler/linker/debugger/whathaveyou under the sun and doing head to head comparisons when all I want to do is get up and running simply seems torturous. Does anyone have any experiences on the relative merits?

I recognize that target application is an issue in these sorts of right/wrong questions. Typical applications will be running generally not too complex code under the classic while(1) {...} OS, a TCP/IP stack, a UART serial terminal for control of the widget, a Telnet terminal (single session only) to do the same things as the UART, and possibly a web server to dish out a single 'index.html' with a few pieces of status information plugged into it. Ideally, I'd get this to all happen inside the single 64K of on-chip SRAM (and an external ROM for code, etc). Since without the networky stuff, the sorts of programs we're doing these days tend to fit comfortably in the 2K SRAM on the 68332, I'd like to think the extra 62K should be able to cover both network needs and compiler-induced inefficiencies.

B) I managed to hunt down the free TCP/IP stack that Freescale gives out, a stripped version of the Interniche stack. But the example seems to be written to operate under CodeWarrior 6.4, and breaks under the 7.0 that was on the CD. All I want is to get up a quick proof of concept, demonstrating that I can manage to have the board serve me up helloworld.html. Does anyone have any recommendations for getting this simple demo going? Also, going back to my last question, is this whole "Hey, old projects break and die under new CodeWarrior releases." thing a frequent issue with CodeWarrior?

C) So I'm used to having my memory allocations go where I tell them to; this whole idea of letting the compiler pick things out for me is somewhat novel on platforms that aren't PCs with (effectively) infinite resources that I don't need to worry my little head about. I'd just like to make sure that I've got this all straight:

- When I declare a global variable, that gets its own fixed location in RAM.

- When I declare a local variable in a subroutine (up to and including main() ), that gets pushed onto the stack (which grows upward).

- When I malloc off a variable (in embedded code, shudder), that gets allocated off of the heap (which grows downward).

- Then all of this, the globals, stack, and heap, all gets tucked into the .data and .sdata segments, which are mapped onto system RAM, which will be at a memory address that I inform the linker of.

- Any initialization values for those variables will be in .bss or .sbss, which will be located in ROM, and copied into whatever memory locations they wind up at as needed by the compiler.

- Variables and arrays that I declare as const wind up in .rodata, which will be located in ROM.

- Apply to any and all of the above statements the phrase "unless the compiler optimizes it into a (register|constant)"

Is that about right?

Thanks, Rob

--
Rob Gaddi, Highland Technology
Email address is currently out of order
Reply to
Rob Gaddi
Loading thread data ...

...without linebreaks. Please format usenet messages to less than 80 characters per line.

Did you consider the newer CF derivatives with a lot of on-chip Flash?

[...]

formatting link

A compiler is a compiler, an "IDE" is an IDE. Bundling both is evil IMNSHO. A good text editor and make do the job. Check out eclipse.

If you think you don't get enough feedback in c.a.e, join the wildrice mailing list (also available via gmane).

Oliver

--
Oliver Betz, Muenchen (oliverbetz.de)
Reply to
Oliver Betz

writing C on the 5275 v2 Coldfire. I've got their M5272 dev kit in hand, and have started poking around at it in a fairly non-specific way, and have run into a few questions that I figured I'd solicit some help on.

any development under CodeWarrior was about a decade ago, and I have pretty distinct memories of both the IDE and the compiler having some serious personality issues, mostly related to throwing tantrums. But 10 years is 10 years.

makefiles and give up the IDE (which I'd shed very few tears for). Or possibly some other 3rd party build chain, if any of them are considerable over these other options. But the idea of going out and downloading trials of every compiler/linker/debugger/whathaveyou under the sun and doing head to head comparisons when all I want to do is get up and running simply seems torturous. Does anyone have any experiences on the relative merits?

questions. Typical applications will be running generally not too complex code under the classic while(1) {...} OS, a TCP/IP stack, a UART serial terminal for control of the widget, a Telnet terminal (single session only) to do the same things as the UART, and possibly a web server to dish out a single 'index.html' with a few pieces of status information plugged into it. Ideally, I'd get this to all happen inside the single 64K of on-chip SRAM (and an external ROM for code, etc). Since without the networky stuff, the sorts of programs we're doing these days tend to fit comfortably in the 2K SRAM on the 68332, I'd like to think the extra 62K should be able to cover both network needs and compiler-induced inefficiencies.

stripped version of the Interniche stack. But the example seems to be written to operate under CodeWarrior 6.4, and breaks under the 7.0 that was on the CD. All I want is to get up a quick proof of concept, demonstrating that I can manage to have the board serve me up helloworld.html. Does anyone have any recommendations for getting this simple demo going? Also, going back to my last question, is this whole "Hey, old projects break and die under new CodeWarrior releases." thing a frequent issue with CodeWarrior?

whole idea of letting the compiler pick things out for me is somewhat novel on platforms that aren't PCs with (effectively) infinite resources that I don't need to worry my little head about. I'd just like to make sure that I've got this all straight:

), that gets pushed onto the stack (which grows upward). When I program M68K apps with Codewarrior, the stack grows downward. I presume that is also the case with the Coldfire system.

allocated off of the heap (which grows downward).

.data and .sdata segments, which are mapped onto system RAM, which will be at a memory address that I inform the linker of.

which will be located in ROM, and copied into whatever memory locations they wind up at as needed by the compiler.

be located in ROM.

optimizes it into a (register|constant)"

Mark Borgerson

Reply to
Mark Borgerson

Yeah, but the 5275 (actually the 5274L probably) has a couple of really compelling features. 64K of on-chip SRAM makes it pretty likely that I can get away most of the time without any external RAM, whereas 32K could get dicey given that the estimates on the TCP/IP stack and HTTP server are 15K right there. Generally we burn DIP EPROMS and plug them into sockets; it eliminates all sorts of problems with figuring out the logistics of doing flash updates without risking bricking the module. Also, a "lot" of on-chip flash is never anywhere near enough to hold a midsized Spartan3 bitstream; once we need to have anything in an external NV we might as well have everything out there.

Just pinged them for a trial, still waiting on a response. Thanks for the lead.

--
Rob Gaddi, Highland Technology
Email address is currently out of order
Reply to
Rob Gaddi

stripped version of the Interniche stack. But the example seems to be written to operate under CodeWarrior 6.4, and breaks under the 7.0 that was on the CD. All I want is to get up a quick proof of concept, demonstrating that I can manage to have the board serve me up helloworld.html. Does anyone have any recommendations for getting this simple demo going? Also, going back to my last question, is this whole "Hey, old projects break and die under new CodeWarrior releases." thing a frequent issue with CodeWarrior?

This one at least turns out to have a fairly simple resolution. It turns out the stack distributed with AN3470 on the Freescale forums is not as up-to-date as the one that you have to register to download (COLDFIRE_LITE_TCPIP). The later one gives you code that is mostly ready to go in CodeWarrior 7, with the exception of having multiple linker files active. If you deselect all but one linker file it all works out nicely. As an additional note, the HTTP server demo is larger than the free edition's code limit, but on the time-limited full license it fires up just fine.

--
Rob Gaddi, Highland Technology
Email address is currently out of order
Reply to
Rob Gaddi

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.