Author Topic: how to choose a PIC?  (Read 16507 times)

0 Members and 1 Guest are viewing this topic.

Offline andyturk

  • Frequent Contributor
  • **
  • Posts: 892
  • Country: us
Re: how to choose a PIC?
« Reply #50 on: October 22, 2012, 11:06:11 pm »
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.
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 18949
  • Country: nl
    • NCT Developments
Re: how to choose a PIC?
« Reply #51 on: October 22, 2012, 11:34:26 pm »
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.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline mrflibble

  • Super Contributor
  • ***
  • Posts: 1994
  • Country: nl
Re: how to choose a PIC?
« Reply #52 on: October 23, 2012, 07:03:21 pm »
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.
 

Offline andyturk

  • Frequent Contributor
  • **
  • Posts: 892
  • Country: us
Re: how to choose a PIC?
« Reply #53 on: October 23, 2012, 08:46:27 pm »
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.
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 3144
  • Country: us
Re: how to choose a PIC?
« Reply #54 on: October 24, 2012, 12:33:27 am »
Quote
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...
 

Offline mrflibble

  • Super Contributor
  • ***
  • Posts: 1994
  • Country: nl
Re: how to choose a PIC?
« Reply #55 on: October 24, 2012, 02:33:41 am »
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.

Quote
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?
 

Offline andyturk

  • Frequent Contributor
  • **
  • Posts: 892
  • Country: us
Re: how to choose a PIC?
« Reply #56 on: October 24, 2012, 05:10:01 pm »
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.
 

Offline ptricks

  • Frequent Contributor
  • **
  • Posts: 670
  • Country: us
Re: how to choose a PIC?
« Reply #57 on: October 25, 2012, 03:08:46 am »
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
 

Offline andyturk

  • Frequent Contributor
  • **
  • Posts: 892
  • Country: us
Re: how to choose a PIC?
« Reply #58 on: October 25, 2012, 05:51:16 am »
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????
 

Offline Kremmen

  • Super Contributor
  • ***
  • Posts: 1283
  • Country: fi
Re: how to choose a PIC?
« Reply #59 on: October 25, 2012, 07:48:37 am »
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...
Nothing sings like a kilovolt.
Dr W. Bishop
 

Offline mrflibble

  • Super Contributor
  • ***
  • Posts: 1994
  • Country: nl
Re: how to choose a PIC?
« Reply #60 on: October 28, 2012, 05:39:22 pm »
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.

Quote
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. ;)

 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf