Loading spin from SD without stopping cogs - possible?

simonl

I'd like to be able to load Spin code (or PASM) from an SD card into a cog whilst allowing all running cogs to continue - is that possible?

I thought this might be possible, so I went looking at FemtoBASIC; PropCMD, and PropDOS, but they all seem to use fsrw's "bootSDCard" method. Unless I'm missing something (entirely possible!), that appears to require all other cogs to be stopped.

The reason for wanting this is that I'd like to keep at least one cog running some communications code.

Thanks in advance.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon

---

www.norfolkhelicopterclub.com

Announcement: To cut costs in the current economic climate, we have switched-off the light at the end of the tunnel.

mctrivia

You can load assembly from sd card into a cog. But spin does not go in the cog it goes in hub ram.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
propmod_us and propmod_1x1 are in stock. Only $30. PCB available for $5

Want to make projects and have Gadget Gangster sell them for you? propmod-us_ps_sd and propmod-1x1 are now available for use in your Gadget Gangster Projects.

Need to upload large images or movies for use in the forum. you can do so at uploader.propmodule.com for free.

Mike Green

It's possible to load a new Spin program while several cogs are still running PASM code. Any buffers or hub variables used by these cogs have to be located somewhere in hub memory where they won't be overwritten by the new program as it's loaded in. Michael Park's Sphinx system does something like this and my "Propeller OS" that is referenced in the Getting Started thread / Pretty Good Thread List does the same thing. There's a serial driver in the Object Exchange that allocates its buffer in cog memory. That might be a good starting point for your project. There's no ready-to-go package that would do what you want. You'd have to modify one of the SD card loaders to leave a specific cog (or cogs) running while it loads something new. It's straightforward, but you'll have to do some work.

mpark

Dang, I really should look at Propeller OS sometime. I wonder if I could have built Sphinx on top of it and saved myself a lot of grief...

simonl

Hey, thanks for the answers - I'm gonna take a look at PropellerOS & Sphinx now

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon

---

www.norfolkhelicopterclub.com

Announcement: To cut costs in the current economic climate, we have switched-off the light at the end of the tunnel.

Mike Green

mpark,
The Propeller OS used a slightly modified VGA or TV driver with the display buffer in hub memory. Sphinx uses a modified TV driver with the display buffer in cog memory. That's a nice saving of hub memory.

By the way, I'm rewriting the TV driver along the lines of what you did, but I'm adding enough functionality so you can use it with an editor. You can also redefine the screen colors (for the whole screen only). I'll post something when I have it running.

simonl

@Mike: Is the code in Propeller OS for Demo Board and Hydra the newest?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon

---

www.norfolkhelicopterclub.com

Announcement: To cut costs in the current economic climate, we have switched-off the light at the end of the tunnel.

Mike Green

simonl,
I don't really remember what's the newest that I posted publicly. I produced a couple of versions that I never posted trying to add SD card support and some other stuff and found that I was running out of hub memory. I finally decided to do FemtoBasic instead. The BoeBotBasic / DongleBasic versions are based on the structure of the Propeller OS while FemtoBasic is not. You'll see that BoeBotBasic's routines use a BB_definitions file and BB_ prefixes on some of its objects. The Propeller OS has a similar organization.

The Propeller OS keeps a list (bitmap) of the cogs used by the OS and programs running under the OS can add to this list. When a new program is loaded, the marked cogs are not stopped.