WAITHUB / WAITLOCK with WAITVID?
VonSzarvas
Posts: 3,451
Hello all.
A few times recently I have found situations where some kind of WAITHUB or WAITLOCK might be jolly useful - usually to do with dropping a "service cog" to lowest power whilst it waits to be called into action.
Managing coginit/cogstop states, especially across multiple cogs (I mean any cog might wish to start/stop any other cog), can get "elaborate".
To simply WAITHUB <hubaddr> when not busy, and then any other cog could WRBYTE <hubaddr>, 1 to start it off again, would seem a rather neat solution.
Similarly with WAITLOCK.. The idea that a cog could sleep to lowest power instead of endlessly loop-checking a hub status byte.
Either of these instructions could be most useful in simplifying code and a real benefit to battery powered solutions.
So I got looking into WAITVID.... I notice in the PASM section of the Propeller Manual it is mentioned:
So without assigning any pins (we assume none are free) is it possible to trigger the WAITVID in any specific cog out of sleep by writing some clever combination of bytes to the appropriate register (VSCL | CTRA?) directly (from any other cog)? eg. WRBYTE $1FF, <special-long-value-to-trigger-release-of-waitvid-in-cog-number-X>
Have tried this a few ways, but cannot get the WAITVID to even sleep indefinitely, so I am wondering if assigning pins with VCFG is a requirement for WAITVID to function?
Or could portB pins be used, if they exist -even internally? - Although in that case, I suspect WAITPEQ on an internal virtual pin would be simpler. (Hmm, got me thinking now about something in the P28-P31 range once the prop has started - could be another option, although "feels" troublesome; perhaps if PropPlug still attached etc..)
So that's it.... is this crazy?... is this even possible to achieve?
Hopefully the forum video guru's will already know the dark side of the cog!
A few times recently I have found situations where some kind of WAITHUB or WAITLOCK might be jolly useful - usually to do with dropping a "service cog" to lowest power whilst it waits to be called into action.
Managing coginit/cogstop states, especially across multiple cogs (I mean any cog might wish to start/stop any other cog), can get "elaborate".
To simply WAITHUB <hubaddr> when not busy, and then any other cog could WRBYTE <hubaddr>, 1 to start it off again, would seem a rather neat solution.
Similarly with WAITLOCK.. The idea that a cog could sleep to lowest power instead of endlessly loop-checking a hub status byte.
Either of these instructions could be most useful in simplifying code and a real benefit to battery powered solutions.
So I got looking into WAITVID.... I notice in the PASM section of the Propeller Manual it is mentioned:
Make sure to start the cogs Video Generator module and Counter A before executing the WAITVID command or it will wait forever.
So without assigning any pins (we assume none are free) is it possible to trigger the WAITVID in any specific cog out of sleep by writing some clever combination of bytes to the appropriate register (VSCL | CTRA?) directly (from any other cog)? eg. WRBYTE $1FF, <special-long-value-to-trigger-release-of-waitvid-in-cog-number-X>
Have tried this a few ways, but cannot get the WAITVID to even sleep indefinitely, so I am wondering if assigning pins with VCFG is a requirement for WAITVID to function?
Or could portB pins be used, if they exist -even internally? - Although in that case, I suspect WAITPEQ on an internal virtual pin would be simpler. (Hmm, got me thinking now about something in the P28-P31 range once the prop has started - could be another option, although "feels" troublesome; perhaps if PropPlug still attached etc..)
So that's it.... is this crazy?... is this even possible to achieve?
Hopefully the forum video guru's will already know the dark side of the cog!
Comments
There is no such thing, only port A exists (for the purpose of using waitpxx). For wake-up this would be acceptable (at the cost of one or more pins) for syncing cogs it isn't.
So the WAITVID settings are per-cog, and not globally (HUB) accessible... OK, I should have understood that from the user-guide- thank you for putting me straight.
On the solution... I found that I could WAITPNE on P28 within the service cogs, and then pull that low from another cog to trigger the WAITs into action.
(P28 and P29 are both inputs pulled high to 10K and not otherwise used for any eeprom or I2C activity once the Prop has booted).
WAITLOCK might still be a useful new command for a future prop version... but for now this is solved so Thank you again!