load and run individual cog programs from an sd card

lyons5959

I have searched pretty hard to find a way to have one cog continuously load code from an SD card for execution by another cog. However, I have failed to find an example. Basically what I've been looking for is the "SD card boot menu" except loading programs for individual cogs and not being limited by the main memory size. I'm not a great programmer and developing something like this would take up too much time if it was not worth it.
So... Is it possible to develop an object or routine with these capabilities:
*main cog controls SD card interface
*main cog loads code from SD card and hands it to another cog for execution

The main reasons behind a project like this are to eliminate the main memory problem of being only 32k and sacrificing execution speed for larger programs. I know there are some knowlegable people in this forum who can help.
Thanks,
Michael

Mike Green

From your question, it's not clear that you understand how the Propeller operates, particularly the interplay between cogs and the Spin interpreter.

It's easy to create an object that controls an SD card interface (FAT file system). There already exist objects to load data from an SD card into main memory. The main program can certainly take a block of 2K bytes (512 longs) and start up a cog with this as the program. Whether this is useful is another question.

The Propeller OS was one attempt to accomplish this by loading several different I/O drivers (keyboard / display / I2C) into their cogs and leaving them
running while other programs are loaded from EEPROM that use the routines already running in these cogs essentially doing overlays. The same thing
couldn't be done with SD cards because the FAT file system code is complex and large and, even if rewritten in assembly, would occupy another cog where already 3 or 4 cogs were in use (plus one needed for the main program) leaving only 2 or 3 for things like serial drivers or servo controllers, etc.

Your basic question (as I understand it) is: How does one get around the 32K memory limit (for Spin programs) and, indirectly, the 2K (496 long) memory limit for individual cogs?

The answer depends on the application involved. If the application doesn't use a lot of memory for data, it may be possible to use conventional overlays.
If the application needs a lot of data, you may need to attach some kind of external memory, like an SRAM that doesn't have write delays or limits on the number of writes and store the data there. That will slow the program down substantially, but, in some cases, may work. If you're loading overlays from an SD card, the initialization routine could look up all the overlay files and necessary data files and save their starting absolute block numbers in main memory. That way, the FAT file system routines would not be needed further (as long as the files were all preallocated, each in a single extent. The SD
card loader (read / write routines) can sit in a cog and load overlays as needed.

lyons5959

Mike,

From your post it sounds like my original idea my not be feasible. To clarify my original question, I was looking for a way to have data and maybe code in an SD card so that the data could be manipulated by a PC. This data would then be accessed by a cog for calculations. You are right, I'm not very familiar with the propeller but I have written a few programs that deal with cog to cog and cog to external memory relationships. I am a student and am looking at the propeller for a design project of a low cost ECU.

My project: having fuel and timing maps for an ECU that a certain cog, controlling the injectors and ignition coils, could do calculations to determine injection and ignition events. I may be able to write these programs in assembly so that they will fit into the cog ram, however I need a way to access the large data maps in order to do these calculations. So you see, I was looking to have a cog load points from these maps into the local memory so that cogs could access the data for calculations.


My idea was this:
1)main cog start
2)start cog with injector code
3)start cog with ignition code
4)start cog with sensor code
5)start cog with traction code
5)main cog receives data pointers from sensor cog, loads data from maps at the pointers into local memory
6)injector and ignition cogs use data for calculations determining injector and ignition events

This is just an idea and I'm really attracted to the fact that I could have simultaneous processing of injection and ignition events on one ECU. But is this too much for the propeller?

hippy

If you're only after data then I cannot see any reason why the Propeller cannot load data from I2C eeprom or SD card as it needs it, and it should be easy enough to write a Propeller program which allows a PC to also read or change that data.

The real issue is whether you can read in the data you need quickly enough for when you need it. If I2C or SPI is too slow then you could always add banks of SRAM.

Mike Green

lyons5959,
I see no fundamental reason why you could not do this. "The devil is in the details". Keep in mind (as I mentioned) that the SD card routines for the DOS/Windows file system are fairly large. As I mentioned, you could look up the file locations (absolute sector numbers) for all your data files and any overlays during the initialization process and keep them in RAM, then initialize the various cogs which will begin in some idle state (including the I2C/SPI routines). At that point, you don't need to keep the code for the cogs around and you can overlay the whole initialization program with another phase that can read and write SD card files given their starting addresses on the SD card and load overlays given their starting addresses on the SD card, etc. You wouldn't need the FAT file system routines nor any of the ECM cog routines nor the I2C/SPI cog routines.

lyons5959

I recently read the Machine Language Tutorial and while i'm still absorbing the material a new idea formed on how this might work.

initialize
1)main program starts. this consists of i2c and spi routines for loading data from SD card. also injector, ignition, timing, traction control, and sensor cog codes are included at set points in memory.
2)new cogs are started with these routines
3)i2c and spi routines use space in main memory for global variables

loop following
4)injection, ignition, timing, sensor, and TC cogs send out requests for data in global variables for inter-cog comunication
5)i2c and spi routines use requests and pull data out of maps in SD cards
6)injection, ignition, timing, sensor, and TC cogs poll global variables for the data pulled by the i2c and spi routines

How does this sound so far...

Mike Green

As is usually true, general overviews of something complex always look good and the details of how things are really done are what make the difference between something that works well and something that doesn't.

What you've stated is a perfectly good overview.

J.A.B.

This sound like a very simplified version of timeslice multitasking.

To bad the propeller engine does not include logic for pushing and polling entire cog states.
Timeslicing a Cog would be perfect for performing complex tasks with bigger datasets etc. that are not latency critical.

Post Edited (J.A.B.) : 11/13/2007 8:52:39 AM GMT

Paul Baker

There may not be context switching hardware, but it a relatively straightforward process to impliment it. Use JMPRET as the mechanism, and simply store and retrieve any needed state variables. FullDuplexSerial uses this technique to handle the bi-directional communications

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.