Shop OBEX P1 Docs P2 Docs Learn Events
HUB overflow problem. Help with first big build. — Parallax Forums

HUB overflow problem. Help with first big build.

pgbpsupgbpsu Posts: 460
edited 2012-06-30 18:27 in Propeller 1
Although I've worked with the Prop for several years I'm only now getting into the Prop/C game. And frankly the reason I'm doing so now is because I've got a piece of hardware I'd like to test out with the Prop and the vendor provides example source code in C. My first thought was to attempt to translate it all to spin but its more than 60 files and since they provide it as C I thought this would be a good time to start learning C.

Well, maybe not. This beast is complicated. However, I thought it worth a try, maybe it won't be as difficult as I expect and I'll no doubt learn something along the way. After downloading the example code I attempted to make it on my Mac. One or two make commands and the whole thing compiled. Useless but not a bad start.

So I modified the make files to use PropGCC rather than GCC and started again. Using their make files (only altered by changing gcc to propgcc) things go smoothly until I get an out of HUB memory error:
/Applications/SimpleIDE/parallax/bin/../lib/gcc/propeller-elf/4.6.1/../../../../propeller-elf/bin/ld: driver section `.hub' will not fit in region `hub'
/Applications/SimpleIDE/parallax/bin/../lib/gcc/propeller-elf/4.6.1/../../../../propeller-elf/bin/ld: region `hub' overflowed by 29516 bytes
collect2: ld returned 1 exit status
make: *** [driver] Error 1

Question number one:
Is there a way to compile something with propgcc without any restrictions on code size? I realize this may produce an output file that's too large to be useful but at this stage I just want to see the thing compile.

Question number two:
I'm doing this at the command line and with make. What options should I included to give this the best chance of compiling AND fitting into memory. The only boards I have access to are the Quickstart and the Gadget Gangster Propeller Platform USB with microSD.

If I can get this to compile, I'm going to invite a colleague who actually knows C to work with me to pare it down if necessary and to help understand what's going on.

I've attached the two make files in case they are helpful.

Thanks,
Peter
txt
txt
Makefile.txt
2K
txt
txt
Makefile.txt
2K

Comments

  • Mike GreenMike Green Posts: 23,101
    edited 2012-06-28 10:24
    You can compile for an XMM memory model which stores the program on external SRAM, EEPROM, Flash, or an SD card and pages it in as needed. The QuickStart board has extra EEPROM that can be used to store code and the Gadget Gangster board has the microSD card.
  • ersmithersmith Posts: 6,097
    edited 2012-06-28 10:29
    If it's a big program, you might want to start by compiling in XMM mode (this puts the code and data into external memory). To do this just add -mxmm to the CFLAGS in the Makefile. If that works you can try -mxmmc, which puts the code in external memory and data into hub memory. I think you should be able to run XMM code from the microSD card, although it will be very slow.
  • jazzedjazzed Posts: 11,803
    edited 2012-06-28 10:44
    Please look at this page for an overview of PropellerGCC memory models.
    https://sites.google.com/site/propellergcc/documentation
  • pgbpsupgbpsu Posts: 460
    edited 2012-06-28 11:09
    ersmith wrote: »
    If it's a big program, you might want to start by compiling in XMM mode (this puts the code and data into external memory). To do this just add -mxmm to the CFLAGS in the Makefile. If that works you can try -mxmmc, which puts the code in external memory and data into hub memory. I think you should be able to run XMM code from the microSD card, although it will be very slow.

    This did the trick. Now on to loading this to the prop and making it useful...

    Thanks,
    p
  • pgbpsupgbpsu Posts: 460
    edited 2012-06-28 11:10
    jazzed wrote: »
    Please look at this page for an overview of PropellerGCC memory models.
    https://sites.google.com/site/propellergcc/documentation

    This spells it out very nicely. Thanks for the link.
  • pedwardpedward Posts: 1,642
    edited 2012-06-28 11:53
    Another point to note is the optimization flag -Os which will optimize for size.
  • Heater.Heater. Posts: 21,230
    edited 2012-06-28 13:24
    No idea what you have there but with 60 source files trying to fit them into Prop I hub RAM that's only 500 or so bytes each.
    Sounds like a tall order.
  • pgbpsupgbpsu Posts: 460
    edited 2012-06-28 13:27
    Well I got it to compile but as many suspected it's big. 192KB. I'm working with a wifi module with SPI comms. From what I can tell so far it has provisions for the firmware of the device to be updated at boot. I don't need that feature so I'm trying to remove that option which will remove a few very large data files. I think it might be possible to get this under 20KB with limited functionality. At that point it would be run-able on multi-platforms.
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2012-06-30 01:32
    @heater
    Sounds like a tall order.

    It is a new way of thinking. Like Mike and others said, you can put the program on the SD card. Just for fun I added a few #includes for some *big* libraries. The program happily compiled and sent nearly a megabyte to the SD card.

    It would appear that no longer do you have to worry so much about how big a program is. And given it doesn't matter, why not compile for speed rather than size (list box option bottom right of the screen).
  • pgbpsupgbpsu Posts: 460
    edited 2012-06-30 03:50
    I was able to get the program to compile using the make files and gcc. Included in the original make files was the -g option which turns out is used for debugging (GDB I believe). Once I removed that the whole thing squeezed down to 29k. I finally was able to load this version compiled for xmm using propeller-load WITH THE -S option to the board but it didn't do anything/what I expected.

    I started again by loading all the necessary files from the existing directories into SimpleIDE. It took a bit to get all the #includes sorted out but in the end, the exact same code compiled and loaded. This time it did what it was supposed to! I also compiled it for lmm and loaded that which also worked great. I did notice a more stability and speed with the toggle rate of an SPI line in the system when using LMM vs XMM.

    So it compiles and loads, now I just have to get it to do what I want.

    Thanks for all the help here and for the great new option for the Prop.
  • jazzedjazzed Posts: 11,803
    edited 2012-06-30 09:49
    pgbpsu wrote: »
    So it compiles and loads, now I just have to get it to do what I want.

    Thanks for all the help here and for the great new option for the Prop.

    Excellent. Thanks for the update.

    BTW, current XMM variations are designed for the fastest possible execution with burst mode hardware. It is not necessarily designed for determinism. However, it is possible to recover determinism by forcing routines that need to be deterministic to live in HUB memory. Functions can be forced into HUB memory even in an XMM mode by prefixing the functions with HUBTEXT. I.e., void HUBTEXT foo();
  • msrobotsmsrobots Posts: 3,709
    edited 2012-06-30 15:28
    I am still not using PropGCC but playing with GCC on windows and some FriendlyArm Board to interface my Prop-SD-Server Projekt.

    Programming for a living most of my live I was able to avoid C pretty much. So I am sort of biased about C on the Prop. But now I am getting confused. Everybody complains about the disadvantage of the proptool compared to homespun and bstc because unused functions not get removed and the resulting binarys are to big to load.


    and now this from Drac:

    . Just for fun I added a few #includes for some *big* libraries. The program happily compiled and sent nearly a megabyte to the SD card.

    so just including a library will add MBs of bytes in size? or is this still a question of 'needs to be done' somehow?

    Dont get me wrong - I do support Parallax decision to go for GCC and really think the work the PropGCC-Team around Jazzed is amazing - but looking at the examples there is not much C-code nessessary to extend the ressources of a standard prop.

    My question now is - does PropGCC supports removing unused code? Or would it make sense to write some 'precompiler' sort of software to take care of that? For some completly unrelated (work-) Stuff of mine I am thinking of/need to write something like that anyways, so I am brainstorming here...

    Enjoy!

    Mike
  • jazzedjazzed Posts: 11,803
    edited 2012-06-30 16:27
    msrobots wrote: »
    so just including a library will add MBs of bytes in size? or is this still a question of 'needs to be done' somehow?

    This happens most easily if one tries to use the full implementation of the C++ libraries. That is, std::cout and other std name spaces. Everything is there if one really want to use them, but it is not at all necessary to use those libraries. Libraries get pruned, but there are some things that are so big that they can't be pruned like the std namespace.
  • msrobotsmsrobots Posts: 3,709
    edited 2012-06-30 18:27
    aah Drac is using C++ libs, I see. Thank you jazzed - just installed PropGCC Nice IDE you made there.

    Enjoy!

    Mike
Sign In or Register to comment.