Different executables on different cogs
Mercury1964
Posts: 15
I'm trying to create a smartwatch using the Propeller. Ideally, I'd like to be able to run custom programs (games, demos, etc.) from an SD card in separate cogs, while keeping certain system utilities (like the RTC manager, display handler, etc.) running in other cogs. The only SD card loaders I've seen so far *seem* to load a new program into cog 0 and stop all other cogs, effectively overwriting whatever they were running before. Is there a way of loading external programs into a specific cog while keeping other cogs running?
Comments
Sort of.
This idea as been discussed several times on the forum. Post #34 of this thread has a program which should allow one to replace one method with another.
Are you running out of hub RAM? You don't need to resort of overlays unless you're running short on memory. You can start and stop cogs all you want with more traditional program techniques.
I'm assuming you're using Spin? I believe using large programs in C is easier than when using Spin.
This seems to be what I was looking for. Thanks!
I'm not worried about RAM usage (at least, not yet). From my limited understanding of multi-core programming on the Propeller, using cog_run would require any applications to be compiled and linked as methods in the system software, which is somewhat limiting for my purposes.
Are you using Spin or C?
The link I provided was to a thread about using overlays in Spin. I don't know enough about C on the Propeller to know how to do something similar in C. I believe creating a large program (larger than 32K) using C is easier than creating a large program in Spin.
Again, if you're not running out of RAM, there isn't a need to use overlays.
I have also written an overlay loader. It's used in ZiCog (Z80 emulator) which runs CPM2.2 (and can be launched by Prop OS).
I'm using Spin. I'm still confused - is there another way to load methods to individual cogs without them being integrated at compile-time?
I'll take a close look at PropOS in the morning - it seems very interesting.
Technically methods aren't loaded into cogs. PASM code gets loaded into cogs but Spin code remains in the hub.
Launching a new cog to run another instance of the Spin interpreter occurs at run time not compile time. You could have a conditional statement indicating which method to launch.
For example say the variable "character" is the input from the terminal.
The value of "character" could be used to select which method will be used by the newly launched cog.
if characterCog cogstop(characterCog - 1) ' optional, stop previously launched cog. case character "a": characterCog := cognew(MethodA, @stack) + 1 "b": characterCog := cognew(MethodB, @stack) + 1 ' etc.I this example the same cog could be used to run different methods depending on which one the user wanted active.
Before the new cog is launched the previously launched cog is stopped.
The "+ 1" allows allows any cog (even cog #0) to satisfy the "if characterCog" check.
Edit: I remember when I was first learning Spin statements like "if characterCog" confused me. "if characterCog" is the same as "if characterCog <> 0".
So the real problem here is that the SD driver takes all the cogs?
My watch will need to have certain cogs running certain things all the time. Things like the SD card handler, the RTC manager, or the Bluetooth controller always need to be running. These tasks will be written as methods in the system software, something like this pseudocode:
PUB bluetooth: //code goes here PUB rtc: //code goes here PUB sdcard: //code goes here PUB main: cog_run(1, bluetooth) cog_run(2, rtc) cog_run(3, sdcard)As I understand it, using this method of starting new cogs would require any applications I develop to be built into the system software, and any updates to those applications would require me to reflash the entire system software to the Propeller. Furthermore, I would only be able to have as many applications as I could fit into the 20K or so left of memory after all the system code. I was wondering if there was any way to load these applications from an SD card instead of from the EEPROM and without having linked them when I compiled the system software.
I think your main limit is the RAM. Rebooting the Prop to install new firmware shouldn't be a big deal. As you've noted, this can be done from a SD card.
If you run out of RAM then you'll need to use the technique linked to in post #2 or Cluso's Prop OS.