XMM code execution speed vs SPIN

photomankc

I am working on my first autonomous mobile robot and other than some low level very timing critical aspects I have written a lot of the code in SPIN. I am banging up against a few limitations now in the language and structure that I think C++ would help with.

- Passing data structures vs trying to keep straight who is accessing what in some big hunk of RAM that everyone has a finger in.

- Creating a simple interface template for multiple behavior objects so an arbitrator can function easily.

- Object access by reference vs having to pass pointers to private data.

None of this has stopped me from making it work in spin but it has made for some wicked hard to track-down bugs at times.


1.) So long story short I'm trying to get a grasp on how fast I can expect a XMM C++ program to execute vs Spin? Looking at the chart I see it lists XMM as '< 5MIPS' and my best information on SPIN is that it's maybe 80 to 100KIPS. So I could expect that it would certainly run no slower than SPIN already does and may in fact run a good bit faster.

2.) Also, is it still possible to run multiple cogs from XMM code? LMM is listed as being targeted to 8 core SMP while XMM is for "Large Code" but I don't know if that means XMM precludes multiple cogs.



I don't miss the fun of managing the includes in C/C++ but I do miss the data structures and passing objects (references at least) so I plan to start putting my toes back into this water to get ready for Prop2.

jazzed

1) Yes, XMMC is faster than SPIN. XMM-SINGLE and XMM-SPLIT can be slower in some cases.
You can tag functions in XMMC with HUBTEXT to run in HUB RAM if you need full LMM speed.

2) XMMC can start multiple cogs written in PASM or COG C. Multiple XMMC COGs can not be started like with LMM.

Eric's Spin2Cpp translator will help you port your Spin code.

photomankc

Thanks Jazzed. I think it may be possible to run a lot of what I'm doing as COG C and preserve the multiprocessor aspects of what I need but there are a couple of parts that would not fit in a COG, but I could likely work within that if the code is running faster anyway.


So the next question is this (sorry I swear I am trying to search and learn but not having a ton of luck):

- How bad is it using the boot EEPROM over I2C? Can't be great I don't imagine. From what I gathered, SD cards are actually worse though but the trade-off is lots more storage... up to megabytes. I have some older Propeller Platform Boards that I could always drop in a bigger EEPROM into for say 128K. Any reason that would not work? My assumption there is that I can use the entire EEPROM for my code.

- SRAM over SPI? So the only board I can put hands on that I know of that supports this is the QuickPlayer board on Gadget Gangster's site. They sell a 32KB SRAM that they say goes on the board but the PDF schematic shows nothing of it. So that should in theory offer better performance than EEPROM but I don't get how it gives me any extra code space. Also, so where does the program live after the power goes off? Load from EEPROM at start-up, transfer to SRAM and then run from SRAM? What about SPI EEPROM / FLASH instead. Clock rates are much higher than I2C correct? I can't see why I could use SRAM over SPI but not EEPROM or FLASH.

- SD Cards, given that they seem to be very slow I assume they are so widely sought after because they are easy to obtain and they hold a lot... not because they are the top performer?


For now I think the only viable options to significantly expand my code capacity are SD card or EEPROM and what I have read so far suggests that EEPROM edges out SD card for read-only work which is code.

jazzed

SPI Flash and similar solutions are really the perfect low pin-count, low component count designs for using XMMC.

photomankc wrote: »

- How bad is it using the boot EEPROM over I2C?

EEPROM holding code is not so bad, but it's slower than SPI-Flash. As you guessed a 128KB EEPROM would work, but it has to be an at24c1024b or equivalent - the microchip 24lc1025 will not work.

As mentioned SPI-Flash is a better alternative. A 1MB SPI-Flash has the same footprint as a 32KB SPI-SRAM (32KB is useless except as a data buffer).

photomankc wrote: »

Also, so where does the program live after the power goes off? Load from EEPROM at start-up, transfer to SRAM and then run from SRAM? What about SPI EEPROM / FLASH instead. Clock rates are much higher than I2C correct? I can't see why I could use SRAM over SPI but not EEPROM or FLASH.

For XMMC Flash (or EEPROM) the program is burned into Flash and stays there. Code is transferred to HUB ram as needed. If you want to use SRAM for for an XMMC program, a loader writes code to SRAM from SD card at boot up.

photomankc

Excellent. I will look to obtain the AT24C1024B type part to start experimenting a bit. I'll then plan to move in the direction of Flash for the long term solution. I suspect the learning curve in just translating all this to C++ will keep me well occupied long before I start itching for it run faster.

Thanks for answering Jazzed, I know you are plenty busy. I appreciate it.