This leads me to a question that is OT for this thread, but maybe with some guidance on an appropriate title I could start a new thread...
The question is, is there an "accepted" format for creating objects and drivers that are NOT dependent on running from SPIN? It seems that with the push for C and other non-Spin languages on the prop that objects and drivers will be needed that do not have a dependency on SPIN.
Good question.
I've written 10 "cogjects" now that are pasm code compiled into binary, and which you can either paste as data into your program, or to save memory, put them on an SD card and load them in as needed. These can be called from Spin, C, Basic or whatever program you like.
The "accepted" format is for each cogject to be passed one long in "par". It goes back to some of the first Obex code written by Chip, eg the Keyboard and Mouse drivers are good examples. This long is then used by the pasm code to work out what to do. The simplest thing is for that long to contain some data, but usually the par long is a pointer to an array in hub memory. For things like a mouse, keyboard, the standard Obex code ends up being 10-20 longs. Sometimes it is a huge amount of data, eg a graphics buffer with 19200 bytes - more than half the hub ram.
It is up to the calling program (Spin, C, Basic) to sort out declaring these arrays and working out where they are. You can pass data in all sorts of ways, eg in the graphics driver has 19200 bytes, but when the cog is loaded up, the first 10 of these are loaded with config data which gets overwritten later with the graphics data.
This is the bit where it might be relevant to cogs, because along with all the setup data, config data etc, it is also possible to pass a lock. In practice, this might be a long and it might point to another location in hub ram. The higher level program will know where that lock is by looking up the location. And the cog can also find it out by reading in hub data with rdlongs, then reading in the location of the lock.
Hence it ends up that you don't really need a standard for the *location* of the locks. But Bill might be onto something with the *value* of the locks. I suspect more cogject code is going to get written and the more of these, the more likelihood they will end up fighting with each other over control of the pins. But it could become quite complex - eg lock value 'n' means release pins for XMM, but which pins exactly, or which group of pins?
Comments
Good question.
I've written 10 "cogjects" now that are pasm code compiled into binary, and which you can either paste as data into your program, or to save memory, put them on an SD card and load them in as needed. These can be called from Spin, C, Basic or whatever program you like.
The "accepted" format is for each cogject to be passed one long in "par". It goes back to some of the first Obex code written by Chip, eg the Keyboard and Mouse drivers are good examples. This long is then used by the pasm code to work out what to do. The simplest thing is for that long to contain some data, but usually the par long is a pointer to an array in hub memory. For things like a mouse, keyboard, the standard Obex code ends up being 10-20 longs. Sometimes it is a huge amount of data, eg a graphics buffer with 19200 bytes - more than half the hub ram.
It is up to the calling program (Spin, C, Basic) to sort out declaring these arrays and working out where they are. You can pass data in all sorts of ways, eg in the graphics driver has 19200 bytes, but when the cog is loaded up, the first 10 of these are loaded with config data which gets overwritten later with the graphics data.
This is the bit where it might be relevant to cogs, because along with all the setup data, config data etc, it is also possible to pass a lock. In practice, this might be a long and it might point to another location in hub ram. The higher level program will know where that lock is by looking up the location. And the cog can also find it out by reading in hub data with rdlongs, then reading in the location of the lock.
Hence it ends up that you don't really need a standard for the *location* of the locks. But Bill might be onto something with the *value* of the locks. I suspect more cogject code is going to get written and the more of these, the more likelihood they will end up fighting with each other over control of the pins. But it could become quite complex - eg lock value 'n' means release pins for XMM, but which pins exactly, or which group of pins?