VGA - Chip's sample code
Cluso99
Posts: 18,069
in Propeller 2
I was modifying the code to run on my new P2 board which uses the VGA on a 4 pin boundary instead of the usual 8 pin boundary.
Since VGA uses 5 pins being 4 pins (Hsync, B, G, R) plus Vsync and I wanted to use VHGBR in the top 5 of the 8 pin group, I decided to modify the grouping to support 4 pin grouping where the 5th pin (Vsync) was 1 pin lower than the 4pin group when the 4 pin group was odd.
While doing this (and it's working) I saw something unusual in the driver spin code section. When the cogstop call is issued, the VGA pasm cog is stopped and then a pinclear(av_base_pin_ addpins 4) is issued to clear the pins. However, the only cog setting these pins is the pasm cog and when it stops the pins are cleared down. The pins are not set/configured by the spin cog, so this pinclear will not do anything and indeed should not be there.
Am I missing something???
Since VGA uses 5 pins being 4 pins (Hsync, B, G, R) plus Vsync and I wanted to use VHGBR in the top 5 of the 8 pin group, I decided to modify the grouping to support 4 pin grouping where the 5th pin (Vsync) was 1 pin lower than the 4pin group when the 4 pin group was odd.
While doing this (and it's working) I saw something unusual in the driver spin code section. When the cogstop call is issued, the VGA pasm cog is stopped and then a pinclear(av_base_pin_ addpins 4) is issued to clear the pins. However, the only cog setting these pins is the pasm cog and when it stops the pins are cleared down. The pins are not set/configured by the spin cog, so this pinclear will not do anything and indeed should not be there.
Am I missing something???
PUB stop()
'' Stop VGA driver cog
if cog
cogstop(cog-1)
pinclear(av_base_pin_ addpins 4)
Comments
Pinclear clears all the pin mode and control bits.
The pin control/select bits can be change at any time by any cog.
Is it just that one of them wins? Or does the smartpin get some garbage combination of both settings?
I suspect based on what I recall Chip saying about how the mechanism works for talking to the smartpin stuff, that it's "one of them wins".
But it could get mangled between one cog setting up wxpin and another jumping back in to set the wypin. But no real difference with two cogs outputting on the same pin and the results being ORed. You just gotta do it right.
Looking for my old test code now....
{ Smartpin collision test - ozpropdev } dat org loc ptra,#@code1 coginit #1,ptra loc ptra,#@code2 coginit #2,ptra waitx ##600 'wait for cogs to load cogatn #$ff 'syncronized start wrpin loop getct pa 'fast,med and slow pulses testb pa,#22 wc drvc #16 testb pa,#24 wc drvc #17 testb pa,#26 wc drvc #18 testp #19 wc 'read selected pin drvc #24 'shows slow rate (pin 18) ? jmp #loop orgh $400 org code1 waitatn wrpin ##%0110 << 28,#19 'medium rate -2 = pin 17 jmp #$ org code2 waitatn wrpin ##%1101<< 28,#19 'inverted fast rate -3 = pin 16 jmp #$The result is Pin #19 reads an inverted Pin #18 which is a combination (OR) of the two WRPIN instructions.
I believe I have also experienced erratic behaviour trying to read a smartpin from two cogs at the same too.
Of course this is a unusual case.
The RxPIN instruction wins over WXPIN, WXPIN is lost.
This is what happens when you break the rules.