programming question
fixmax
Posts: 91
HI all,
I have a question. I have an application where I have a Prop talking over I2C to the Raspberry Pi. The Pi acts as an I2C slave to the Pi's I2C master. I have 1 cog running in a continuous loop transferring registers into and out of the Pi into and input array and output array.
In the main loop, I am polling an inclinometer sensor, which reads the X and Y and places them into 4 elements of the output array (high and low byte for each axis).
I am also doing the same with a temp / humidity sensor (4 elements), and a digital compass chip (2 elements).
With the various objects I am using, I consume most of the cogs of the Prop (maybe 5 or 6). I know I can optimize the existing objects, to perhaps reduce the cogs, at the expense of speed. However, is it possible to use the objects as-is, with no modifications, in an addressable "paging" scheme for the cog use? What I mean is, I dedicate, say 3 lines coming into the Prop from the GPIO of the Pi, and use that 8 possible combinations (2^3), to switch out the entire cog set for each address? Is this just a goofy use, or is something typical for some applications? For example, cog 0 is monitoring the addressed "state". cogs 1-7 are running on state 1, completely utilized (say theoretically), I switch to the address state 2, the cogs all shut down, and switch over to other set of cogs 1-7 running.
I am even debating on running no objects at all in the main loop, and if a pin goes high, it runs an object that uses as many objects as it needs. This would allow all of the functionality to run only as fast as it needs to, which is the speed of the Pi's task. Does this even make sense? I don't want to run out of cogs, and I would still like to have more functionality in the Prop "node", versus simply adding more Props to the I2C bus (which I have done also).
Any suggestions? I know I can load an entire program as needed of an SD card as a possibility for different "modes", but I'm concerned on the speed hit of accessing the SD card that way, especially with a multiplexing scheme of control from the Pi?
Any best practices or suggestions on this? I still have quite a bit of ram left, so I'm guessing once thats full, my only option at that point is the SD card option..
Thanks in advance..
I have a question. I have an application where I have a Prop talking over I2C to the Raspberry Pi. The Pi acts as an I2C slave to the Pi's I2C master. I have 1 cog running in a continuous loop transferring registers into and out of the Pi into and input array and output array.
In the main loop, I am polling an inclinometer sensor, which reads the X and Y and places them into 4 elements of the output array (high and low byte for each axis).
I am also doing the same with a temp / humidity sensor (4 elements), and a digital compass chip (2 elements).
With the various objects I am using, I consume most of the cogs of the Prop (maybe 5 or 6). I know I can optimize the existing objects, to perhaps reduce the cogs, at the expense of speed. However, is it possible to use the objects as-is, with no modifications, in an addressable "paging" scheme for the cog use? What I mean is, I dedicate, say 3 lines coming into the Prop from the GPIO of the Pi, and use that 8 possible combinations (2^3), to switch out the entire cog set for each address? Is this just a goofy use, or is something typical for some applications? For example, cog 0 is monitoring the addressed "state". cogs 1-7 are running on state 1, completely utilized (say theoretically), I switch to the address state 2, the cogs all shut down, and switch over to other set of cogs 1-7 running.
I am even debating on running no objects at all in the main loop, and if a pin goes high, it runs an object that uses as many objects as it needs. This would allow all of the functionality to run only as fast as it needs to, which is the speed of the Pi's task. Does this even make sense? I don't want to run out of cogs, and I would still like to have more functionality in the Prop "node", versus simply adding more Props to the I2C bus (which I have done also).
Any suggestions? I know I can load an entire program as needed of an SD card as a possibility for different "modes", but I'm concerned on the speed hit of accessing the SD card that way, especially with a multiplexing scheme of control from the Pi?
Any best practices or suggestions on this? I still have quite a bit of ram left, so I'm guessing once thats full, my only option at that point is the SD card option..
Thanks in advance..
Comments
Your question is not easy to answer. It depends. Are you using SPIN / PASM or C/C++?
If using SPIN / PASM you have 32K of ram to work with, loaded out of the lower 32K of your 64K EEPROM. The upper 32K of your EEPROM are unused. So instead of loading something from SD you could load something from the upper half of the EEPROM. But you need to store that something there before you can use it. The Propeller Tool will just write the lower half.
Sadly there is no paging scheme to extent SPIN / PASM. 32K. That's it.
But if them objects you need fit into 32K you are fine.
Say your 4 temp sensors. You might have an object to read one sensor on pin X. Usually all OBEX objects have a start and stop method. Usually the start method takes parameters for pins.
So your main COG can read I2C, start the temp object with pin X, read result from sensor on pin X, return result to I2C and then stop the object. Then it can start the same object again, now using pin Y to read from sensor on pin Y and return and stop it.
You can do the same for other objects. So you can reuse COGS this way. But all objects need to fit in 32K of HUB ram.
If you are using C/C++ things are a little bit different. PropGCC supports (to a degree) external memory. So you can use SPI RAM to extend HUB ram. But this is slower then HUB ram. A tradeoff.
Enjoy!
Mike
You can store the PASM section of objects in external memory.
This wasn't my idea but I just recently tried it myself. Here's a link to a modified version of Tracy Allen's four port serial driver adapted to be loaded from EEPROM. I've done something similar with the servo driver and the floating point object F32.