how to choose a PIC?

[andyturk]

That depends on how you define dynamic memory. I always use a scheduler so there is only one 'process' doing something. This means that every process has the entire stack size at its disposal. It is a very efficient use of memory.

That's a true. But there's always a tradeoff somewhere, because the stack itself is basically just a pre-allocated array. If you make the stack bigger, something else gets smaller.

Efficiency is important, but robustness is right up there too. Any time you have a call that might fail (i.e., that could have thrown an exception under a bigger OS), you have to think about how to handle it. The same is true if you're allocating memory from the stack. Be careful with C's variable length arrays because the compiler can't check to see that space is available.

[nctnico]

Fortunately the ARM Cortex Mx devices have a stack pointer check in the hardware. If you have a seperate stack space for exception/interrupt handling then you should be able to detect a stack overflow and somehow recover.

[mrflibble]

Here are the compiler switches I use (currently):

-fno-rtti -fno-exceptions -fms-extensions -Wno-pmf-conversions -Wno-unused-parameter -Wno-psabi -std=gnu++0x

...

Thank you very much for the detailed post!

I now got things working with a simple test class and some cout << stuff.Print() action. One thing that struck me as odd was that flashing suddenly took quite a bit longer than I was used to. I haven't investigated fully, but I did notice that for example linker.map is quite a bit bigger. New New! with over 50% libstdc++.a related entries! So probably more action required, but at least things are working now.

Incidentally, this is with a summon-arm-toolchain based setup.

[andyturk]

I now got things working with a simple test class and some cout << stuff.Print() action. One thing that struck me as odd was that flashing suddenly took quite a bit longer than I was used to. I haven't investigated fully, but I did notice that for example linker.map is quite a bit bigger. New New! with over 50% libstdc++.a related entries! So probably more action required, but at least things are working now.

Incidentally, this is with a summon-arm-toolchain based setup.

Yup, the standard library is pretty big. The good news is that you probably don't need it. Just try a trivial main() that avoids stream IO and your executable should crunch right down. I used S-A-T for a while too and switched to yagarto for reasons that I've now forgotten. It probably had something to do with getting the right versions of openocd and gdb.

[westfw]

Here are the compiler switches

Assuming you're using one of the gcc-based compilers, add "-ffunction-sections -fdata-sections" to your compile, and "-Wl,--gc-sections" to the link.  This will cause functions and data that are not referenced from anywhere to be "garbage collected" and omitted from your final binary.  It's pretty magical and discipline-destroying...

[mrflibble]

Assuming you're using one of the gcc-based compilers, add "-ffunction-sections -fdata-sections" to your compile, and "-Wl,--gc-sections" to the link.

The --gc-section bit I had already, but I missed the other two. Added now.

Just try a trivial main() that avoids stream IO and your executable should crunch right down.

You were right. I removed the iostream stuff and that made a big difference.

I used S-A-T for a while too and switched to yagarto for reasons that I've now forgotten. It probably had something to do with getting the right versions of openocd and gdb.

Or maybe the lack of hardware floating point? As for openocd, I did compile in support for that but I'm currently using stlink. Mainly because that seemed easier at the time... I must admit I didn't really do any research on openocd vs stlink vs whatever else there may be out there. At first I was concerned with just getting stuff to work. Does openocd (in SAT or in yagarto) have any advantages over stlink?

[andyturk]

Or maybe the lack of hardware floating point? As for openocd, I did compile in support for that but I'm currently using stlink. Mainly because that seemed easier at the time... I must admit I didn't really do any research on openocd vs stlink vs whatever else there may be out there. At first I was concerned with just getting stuff to work. Does openocd (in SAT or in yagarto) have any advantages over stlink?

I haven't used hardware FP in an mcu project yet, but I'm pretty sure both yagarto and SAT will support it, since they're both using GCC. I've used both stlink and openocd. Stlink is obviously only going to work with ST chips, if that's an issue (I started out using Stellaris parts from TI). Both seem to work fairly well, but my impression is that the openocd project is more active. I've been able to post questions to the mailing list and get answers pretty quickly. I haven't tried that with stlink.

For me, it came down to getting emacs (my IDE), gdb and the debugging layer to place nicely together. It was a trial-and-error process, but I've got things working fairly well now with emacs 24.1.1, gdb 6.3.50, and a patched version of openocd 0.6. The patch is to handle the "'g' packet reply is too long" error with gdb.  If you're curious, read athquad's reply here.

[ptricks]

Earlier I mentioned really good ASM programmers. Here is one that is a good example of what can be accomplished if you really are good at ASM.
 A complete OS, supports up to 8 cpus, 24 bit color gui with acceleration, networking email and web browser, sound, TV card , dvd, mp3, webcams, and printer support, built in IDE,  all of it fits on a 3.5" floppy.

http://www.menuetos.net/index.htm

[andyturk]

A complete OS, supports up to 8 cpus, 24 bit color gui with acceleration, networking email and web browser, sound, TV card , dvd, mp3, webcams, and printer support, built in IDE,  all of it fits on a 3.5" floppy.

All in ASM. OK. But why?

[Kremmen]

My question as well. A tour de force? Demonstration that it can be done? Certainly not because it was the only/best way to do it. Were i the product owner, i would now be shitless contemplating who will maintain the codebase in the medium/long term...

[mrflibble]

I haven't used hardware FP in an mcu project yet, but I'm pretty sure both yagarto and SAT will support it, since they're both using GCC. I've used both stlink and openocd. Stlink is obviously only going to work with ST chips, if that's an issue (I started out using Stellaris parts from TI). Both seem to work fairly well, but my impression is that the openocd project is more active. I've been able to post questions to the mailing list and get answers pretty quickly. I haven't tried that with stlink.

I recall that at the very least older versions of SAT did not support hardware fpu. No real problem since all my current projects are fairly lame in the number crunching department. I mean, some moderate processing at 125 ksps/24-bit is pretty much a snoozefest.

For me, it came down to getting emacs (my IDE), gdb and the debugging layer to place nicely together. It was a trial-and-error process, but I've got things working fairly well now with emacs 24.1.1, gdb 6.3.50, and a patched version of openocd 0.6. The patch is to handle the "'g' packet reply is too long" error with gdb.  If you're curious, read athquad's reply here.

Heh, this time I decided to not go the emacs route... Although it's always fun when you do the emacs keystrokes to save file + run make... only to realizy that those keys don't quite do the same things in eclipse.