Multiple Full Duplex Serial and launching new cogs question

T Chap

In searching "multiple full duplex serial" I saw no code examples, but could someone please tell me if this makes sense for multiple instances of serial i/o:

OBJ  
      ser[noparse][[/noparse] 4]     :  Full Duplex Serial


PUB INIT
      ser[noparse][[/noparse] 1].start(15, 16, 0, 28000)
      ser[noparse][[/noparse] 2].start(17, 18, 0, 28000)
      ser[noparse][[/noparse] 3].start(19, 20, 0, 28000)
      ser[noparse][[/noparse] 4].start(21, 22, 0, 28000)
      getrx1
      getrx2
      getrx3
      getrx4
      repeat
     
PRI  getrx1
     recbyte :=   ser[noparse][[/noparse] 0].rx
PRI  getrx2
     recbyte :=   ser[noparse][[/noparse] 1].rx
PRI  getrx3
     recbyte :=   ser[noparse][[/noparse] 2].rx
PRI  getrx4
     recbyte :=   ser[noparse][[/noparse] 3].rx

Basically the idea is setting all 4 receives in waiting for input mode.

My understanding is this requires 4 cogs, and since I am running out of cogs for other needs, I will need to constantly be stopping and starting cogs for I2C and Full Duplex.

Could someone please take a guess at approximately how long it takes to launch a stop a cog and start a new cog and have it respond to some input? An example: an I2C 8575 expander, which has an interrupt output that fires if there are any changes on any input. If there is a change, the interrupt fires to the Prop on a pin is being looked at, whether a loop scanning several interrupt inputs or waitpne etc, the Prop can then load a cog with an I2C code that reads the appropriate address of the 8575. This way, multiple expanders can be connected, but instead of looping a code that is reading the inputs looking for changes (taking longer due to sending multiple I2C read strings to several 8575's), the interrupt outputs on any change, which frees up some cogs to be doing other things. In this example, I am trying to learn how fast this can happen:

Interrupt comes in from one of several 8575 expanders
Stop a cog to free one up for I2C read
Start a new cog for I2C minimal driver
Read the I2C address where the interrupt came from
Respond with another code

If the input at the expander is not long enough, then by the time all this takes place, the read will show nothing, which is why I am trying to get some idea about how long the process might take, to gauge what pulse length would be needed on the inputs to not be missed.

Thanks for any ideas.

Post Edited (Originator) : 9/16/2008 5:47:54 PM GMT

BradC

You will need to declare that object as

OBJ
ser : Full Duplex Serial

or you will run into trouble.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!

Timmoore

.rx waits for input before proceeding, so getrx must receive a char on 1 then 2 then 3 then 4 before receiving anything on the other ports again. Is this what you planned.

In terms of no of cogs for serial ports. There is an object in object exchange that supports 4 serial ports with 1 cog. You may want to take a look at that.

To start a cog the cogs memory is loaded from hub memory so look at 512 rdlongs or 512 * 16 clocks (hub access time)

T Chap

Thanks guys. This is not real code, I was just showing the concept of using the array to see if that would work, there are obvious problems with that code.

I will check out the object you mentioned for 4 serial ports, that seems like the solution.

512*16=8192

8192/80_000_000 = .0001024 sec

Mike Green

Back to your original question

1) The syntax is: OBJ ser[noparse][[/noparse] 4 ] : "FullDuplexSerial"

2) It takes about 100us to start up a new cog. Most of that time is spent copying the 512 longs from hub ram to the cog's ram.

T Chap

Mike Green said...
Back to your original question

1) The syntax is: OBJ ser[noparse][[/noparse] 4 ] : "FullDuplexSerial"

2) It takes about 100us to start up a new cog. Most of that time is spent copying the 512 longs from hub ram to the cog's ram.

Thanks Mike

I forget to put the space in there sometimes when using brackets. I suppose using an array for 4 instances requires you start at 1, not 0.

100us is pretty fast, especially for a button being pressed by a finger for input.