executing code/bin from external storage

rwgast_logicdesign · 2012-12-05 23:34

So when it comes to programming im a very modular and tidy kind of person. I was wondering if there is any way to get a prop to execute code from external flash/sram. Im kind of looking to maybe bundle up all the "drivers" for my system and have have them all stored externaly then loaded as needed and loaded. Im also looking to do this with spin or precompiled binarys which i know makes things a bit more tricky. How would one go about this maybe a virtual machine or something? I know what im asking isnt directly supported but i figure with things like cmm and xmm the proof of concepts is there.

MagIO2 · 2012-12-06 04:52

In my current project I do most of that and I did all of that in my CogOS already - which has not been published so far. You can have a look at my blog to get an idea of what I did.

So, what do I do in my current project:
1. I store the PASM code of drivers in upper part of EEPROM. Each program that needs for example FullDuplexSerial only needs a buffer to load the driver. It's then loaded/started at the beginning and then the buffer can be used for something else.
2. All drivers running have an entry in upper part of HUB-RAM and use a mailbox in upper part of HUB-RAM. This allows to load other program-parts which can then use exactly these drivers without loading on their own.
3. I store SPIN code as binaries in a SWAP-file. These binaries can be loaded into a buffer and executed there while the main program is waiting. If the loaded program is done it will return to the loading program.
This can be used to implement "commands" like in an OS. What's installed in this SWAP-file can be run.

What worked in CogOS is to load complete EEPROM-files from SD card. Problem with that is, that in this case each program has to take care of it's drivers by itself because the upper HUB-RAM table will be overwritten by loading an EEPROM-file.
With some changes in the SD card driver it should be possible to do this with a BIN-file as well. In that case the driver table would be available for the new program as well and it can reuse the already running drivers.

If you are interested I can go into more details this evening.

rwgast_logicdesign · 2012-12-06 11:08

Well basically im thinking this could allow for alot more code and better cpu cycle managment. Lets say I have some hardware but im not running it at the time id like to then load up a new instance of the driver either binary or code and then be able to unload it when the hardware is no longer needed. I figure this would also save alot of the 32/kb the prop loads on boot since these drivers arent part of the main code there stored somewhere else. It sounds like you have written code capable of this, how much of a performance hit are you taking? Id like to store the code into battery backed sram to minimize performance issues.

MagIO2 · 2012-12-06 12:14

I did not measure performance so far, because I don't have performance critical applications so far. I simply use BasicI2C which is written in SPIN, so I'd expect that it's rather slow at the moment. Because of your question I had a look at the object exchange and found a BasicI2C compatible driver which is written in PASM. I'll give it a try.

I don't see a reason for using a battery-buffered RAM. Upper part of EEPROM is good enough for me. I'd not expect RAM to be much faster if it has a serial interface. RAM with parallel interface would be a to big waste of pins.

If EEPROM is to small, you could have the most important drivers (SD card driver) on EEPROM and additional drivers on SD card. SD card reads at ~1MB/sec.

Here is an example of an OS loading drivers:

PUB HomeCenterOS
  ' if RAM descriptor table should be used, it has to be initialized first by
  ' setting the number of descriptor entries
  desc.initRAMDesc( 15 )
  ' this initializes the parameter-manager which can be asked for upper memory
  desc.initPARmng
  tmp := desc.parReserve( 2 )
  desc.addEntry( string("HomeOS"),$0100,cogid,2,tmp )
  
  ' start the code that knows how to read the driver table
  ' and give it some space ( 512 bytes for directory + 512 longs for driver)
  ' after loading all needed drivers the buffers can be used for other things 
  desc.initDesc( @buffer, desc#DEV_FRAM )

  ' load the FullDuplexSerial in version 1.1
  tmp := desc.loadDriver( @fdserial , $0110 )
  ' when you are sure that the driver exists it can be started right away, otherwise
  ' you should rather check the result
  if tmp<0
    ' not even the serial driver is there, so stop here
    return

  ' get some memory from upper RAM
  tmp := desc.parReserve( desc.getPSize )
  
  ' run the NP full duplex
  ' first get the address of the communication buffer  ' tmp :=
  'tmp := term.start( term#BOOT_RX, term#BOOT_TX, 0, 57600 )
  term.start( term#BOOT_RX, term#BOOT_TX, 0, 57600, tmp )
  ' and then start the code loaded by loadDriver
  i := desc.startDriver(@ld_buffer, tmp)
  ' i := cognew( @ld_buffer, tmp ) 
  'term.setCOG( i )

  ' wait until any key has been pushed
  tmp:=-1
  repeat while tmp==-1
    term.str( string( "HomeCentralNT",$0d,"== please press key to start ==",$0d ) )
    tmp:=term.rxtime( 1000 )

  printHead
  ' write the delayed message of loading terminal driver
  loadMsg( @fdserial, i )

  ' now load the SD driver
  tmp := desc.loadDriver( @sdcard , $0170 )
  if tmp<0
    ' not even the SD driver is there, so stop here
    return
  ' reserve the HUB RAM needed by the driver
  tmp := desc.parReserve( desc.getPSize )
   
  sd.start( tmp, @ld_buffer )
  i:=desc.startDriver( @ld_buffer, tmp )
  ' print the load message for SDcard
  loadMsg( @sdcard, i )

What I also do to save valuable HUB-RAM is, storing text messages in "virtual memory" (a SWAP-file).

Maybe later this evening I can upload a zip containing the current state of my project. The missing part is a good description on how to setup the whole stuff.

executing code/bin from external storage

Comments