Isn't that 15 interrupt handlers? something had to be running first --- Right,...
No. Not if I hang upside down from the ceiling and squint at it hard.
What about if all the code I load into all the COGs (including the code that originally runs in COG 0 at power up) ends up waiting on a WAITxxx for some event? We could imagine firing up the same code in all COGs, all waiting on different pins. Where is the background task at that point? All the COGs have become event handlers (We really can't say "interrupts" now as nothing ever gets interrupted!)
It's an interesting point though. Reminds me that I have worked on a bunch of real time systems where everything was run of off interrupts, say 10 and or 100ms timer ticks and whatever peripheral interrupts. The background being nothing but a HALT or perhaps some EPROM checksum or such.
No. Not if I hang upside down from the ceiling and squint at it hard.
What about if all the code I load into all the COGs (including the code that originally runs in COG 0 at power up) ends up waiting on a WAITxxx for some event? We could imagine firing up the same code in all COGs, all waiting on different pins. Where is the background task at that point? All the COGs have become event handlers (We really can't say "interrupts" now as nothing ever gets interrupted!)
It's an interesting point though. Reminds me that I have worked on a bunch of real time systems where everything was run of off interrupts, say 10 and or 100ms timer ticks and whatever peripheral interrupts. The background being nothing but a HALT or perhaps some EPROM checksum or such.
That type of event handler reminds me of the early serial and parallel interfaces I built for instruments that used Victor Listers with a solenoid deck for printing. Each data line from the instrument went to a priority encoder which provided the high order address bits to an eprom, and a counter on the four least significant address bits stepped through the eprom to provide the serial and parallel data along with a strobe and couple of control signals.
Nothing too bad I promise - mind you even the bunny rabbit's flatulence ...with the prevailing wind ... Anyway when it comes from the East then you get your own back on us ...
Comments
What about if all the code I load into all the COGs (including the code that originally runs in COG 0 at power up) ends up waiting on a WAITxxx for some event? We could imagine firing up the same code in all COGs, all waiting on different pins. Where is the background task at that point? All the COGs have become event handlers (We really can't say "interrupts" now as nothing ever gets interrupted!)
It's an interesting point though. Reminds me that I have worked on a bunch of real time systems where everything was run of off interrupts, say 10 and or 100ms timer ticks and whatever peripheral interrupts. The background being nothing but a HALT or perhaps some EPROM checksum or such.
All of the stuff our Genny stuffed out this morning is on its way over to you, should be there in a few days ...
That type of event handler reminds me of the early serial and parallel interfaces I built for instruments that used Victor Listers with a solenoid deck for printing. Each data line from the instrument went to a priority encoder which provided the high order address bits to an eprom, and a counter on the four least significant address bits stepped through the eprom to provide the serial and parallel data along with a strobe and couple of control signals.
I hope you have my most recent address. P.M. me if you are serious.