Need help/review of Serial Ouput ASM code

Timothy D. Swieter

My goal is to get the Propeller communicating with a ScreenKey (http://www.screenkeys.com/prod_rgb_series.shtml) As noted in a different topic, Spin is not fast enough for the device, so I coded up an ASM program to control one key.· For now the program is only a test program, nothing fancy about it.· I mostly used the FullDuplexSerial ASM routine as a template and modified it for my needs.

The main program starts a counter at 50kHz. on a pin.· Then another cog is started with the ASM routine.· The ASM routine has a buffer, a 16 word buffer.· The main program writes data into the buffer and the ASM routine sends it out.· Each packet of data is 12 bits.· The data is sent synchronously with the clock.· Note that the falling edge of the clock is when the data is latched into the ScreenKey.

So....I have a couple problems that is keeping the code from working.· One problem (maybe the only one) stems from changing the code from an array of 16 bytes to an array of 16 words.· The code attached does not have the full changes in it, because when I have tried what I thought to be the·full changes, they did not work.

To complete the conversion from 16 byte array to 16 word array I need to the change the following:

··In the VAR section:
· "byte tx_buffer[noparse][[/noparse]16]"· changes to· "word tx_buffer[noparse][[/noparse]16]"

· The·TX_ScreenKey method starts out as the following:

PUB TX_ScreenKey(txbyte)
''Place a byte in the buffer, this routine may wait for room.
  repeat until (tx_tail <> (tx_head + 1) & $0F)
  tx_buffer[noparse][[/noparse]tx_head] := txbyte
  tx_head := (tx_head + 1) & $0F

·· ·Obviously I know I need to change the "txbyte" to "txword", but that is only a name change.· I believe I also need to change the "+1" to a "+2" and "& $0F" to an "& $1D" - but that doesn't seem to work.· Is the +2 and $1D part correct?

·· In the ASM code, the transmit section starts out as the following:

add     t3,txbuff               'get byte and inc tail, t3 has tx_tail
rdbyte  txdata,t3               'read data out of buffer into txdata
sub     t3,txbuff               'return to t3 having tail
add     t3,#1                   'Get to the next byte
and     t3,#$0F                 'make it roll over
wrlong  t3,t1                   'Save the tail value

I need to change "rdbyte" to "rdword", "#1" to "#2", and "#$0F" to "#$1D".· Again, am I correct with the #2 and #$1D?
With the code partially modified, as attached, I get each packet of data sent twice in a row, not what I want (not that I expected it to work, just noting the interesting behaviour).· I suspect this is do to the rdword aligning itself to an address boundry.· I am watching the data·using a BitScope 310U with the·Active logic module.· If I fully modify the code as discussed above the Propeller goes off into la la land never to be heard from again.
Any advice or insight is appreciated on what I need to modify to make the 16 word array buffer to work.· Thank you.







▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter
tdswieter.com

---

One little spark is all it takes for an idea to explode

Ariba

Hello Timothy

Attached is my SerialTransmit.spin that can add a Parity-bit in the Assembly-Transmit Loop. So you don't have to work with a word-sized buffer. Just adapt it to work with the synchron clock. But make the clock synchronisation at the beginning of the loop, not at the end.

If you want do it with the word-sized-buffer:
In Tx_ScreenKey() change only the txbyte to txword. The tx_head-Index goes still from 0 to 15. Spin knows that this are words, if you declare the buffer with: word tx_buffer[noparse][[/noparse]16] .

In the Assembly code you need: rdword, #2 and #$1E (not $1D).

Good luck

Andy

Timothy D. Swieter

Thank you for the code sample Andy.· For the moment I simply wanted to get the device working.· Eventually I will add the processing inside the assembly-transmit to automatically add the start bit, parity bit and end bit.· I also need to make it recognize which command it is so that it can follow-up with the correct data bytes.· Your code will come in handy!

I reviewed your suggestions and tried them.· I don't see why I would change the way the tail is incremented and not the head.· The Spin code has no clue if the pointer is to a word or a byte.· Using your suggestions above (not changing the Spin routine) I get odd data coming out.· When I change both the Spin routine and the assembly routine to use $1E (thank you for pointing this out!) and incrementing by two the code mostly works.· After 7 cycles through the repeat the Propeller is lost.· There is also some odd thing going on with the data packet.· I see the Propeller send Picture A and then Picture B.· What I would expect to see, when everything is working, is the 12 bits that are mostly zeros first in the data trace, followed by the packet with the·12 bits·containing a blip of·1111s.

For now, more testing·until I can figure out what I coded wrong.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter
tdswieter.com

---

One little spark is all it takes for an idea to explode

Timothy D. Swieter

Upon staring at my code for a while I see now what you mean by tx_head only having to increment by one. It is because of the use in tx_buffer[noparse][[/noparse]tx_head]. I still have a bug or two in the code though, because the checking if head/tail are equal does not work.

More staring at the code.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter
tdswieter.com

---

One little spark is all it takes for an idea to explode

Timothy D. Swieter

So I think it is working now. In the ASM, I will shift the tail value left 1 (multiple by 2) then read the data, then shift right by 1 (divide by 2) before I increment. This will keep both the head and the tail index from 0 to 15. It looks like I am going to get it working soon. Need more testing!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter
tdswieter.com

---

One little spark is all it takes for an idea to explode