Spin syntax for numbers > 255 w/8 bit SPI engine?

lardom

I've seen how ascii characters are clocked in "byte[pointer++] := x". I tried to clock in a value such as 180,000 but anything above 255 was an error. I've been stumped for two days. Do I need a byte array and/or a method to add the values together?

Erlend

Yes, with such large numbers you neet to first break it down into MSB (most significant byte) and LSB, together making a WORD (16bit) or use all four bytes of a LONG if you have really high numbers. Convert 180 000 into binary, take the 8 lowest bits and put them into LSB, the 8 next bits and put them into MSB, then transfer this as two byte transfers. (Or with a LONG do this 4 x 8 bits, and trasnfer as four bytes).

Erlend

kwinn

A value of 180_000 would be $02BF20 hex or %101011111100100000 binary so would have to be split into a minimum of 3 8 bit bytes for transfer.

Erlend

kwinn wrote: »

... so would have to be split into a minimum of 3 8 bit bytes for transfer.

Yes, sorry, mine was a late night answer. Late at night I believed 180k could squeeze into 2 bytes...

Erlend

lardom

Erland and Kwinn, You both said I had to break a Long into Bytes so I 'read the manual' to find out how to do it. The key was using byte offsets and variable addresses.
Thank you.

CON
  _clkmode = xtal1 + pll16x                           
  _xinfreq = 5_000_000

  
OBJ   
  Debug  : "FullDuplexSerialPlus"   

PUB largeByteValue  | offset_var, value_holder

  Debug.start(31, 30, 0, 57600)
  waitcnt(clkfreq * 2 + cnt)     

  value_holder := 180000
  offset_var := 0

  byte[@offset_var][0]  += byte[@value_holder][0] 
  debug.dec(offset_var)
'  Debug.bin(offset_var, 32) 
  Debug.tx(13)
  waitcnt(clkfreq+cnt)
  byte[@offset_var][1]  += byte[@value_holder][1] 
  debug.dec(offset_var)
'  Debug.bin(offset_var, 32) 
  Debug.tx(13)
  waitcnt(clkfreq+cnt)
  byte[@offset_var][2]  += byte[@value_holder][2] 
  debug.dec(offset_var)
'  Debug.bin(offset_var, 32) 
  Debug.tx(13)
  waitcnt(clkfreq+cnt)
  byte[@offset_var][3]  += byte[@value_holder][3] 
  debug.dec(offset_var)
'  Debug.bin(offset_var, 32) 
  Debug.tx(13)          

Ariba

All that you do here is:

  offset_var := value_holder

but in a very complicated way

It's not clear to me what you want to do. "clock in a value" from where, in what format?

lardom

Ariba wrote: »

All that you do here is:

  offset_var := value_holder

but in a very complicated way

It's not clear to me what you want to do. "clock in a value" from where, in what format?

There's a simpler way?
The nrf24L01 is a SPI transceiver. It's configured to clock in 8 bits at a time. I was incrementing a variable from 0 to 255 so I didn't see a problem at first.
I'm working with two demo's. One by Erland and the other by Duane Degn both of which clock strings. I want to control motors so I'm interested in transmitting values.

Erlend

The nRF24L01 can transmit up to 32 bytes in each telegram. My demo uses keyboard input to provide those (up to) 32 bytes, but the object really does not care what you put into the bytes. You can instead send your first 4 bytes of the LONG as the 4 first of these 32 bytes in the telegram. At the receiving end you pick up the same 4 first bytes of the telegram and put them together into a LONG.
If you do not change the radio payload length parameter, the radio will expect to transmit and receive 32 bytes, so there will be a lot of waste - instead set the payload length to 4. But a good advice is to only change as little at the time as possible of the demo code, and debug and check you get the results piece by piece, instead of doing a lot of changes and then despair when something does not work.

Erlend

Ariba

If the demos send 32 bytes from a byte array (=string) then just define the array as 8 longs and send or receive it as single bytes:

DAT
  long  values[8]    '8 longs = 32 bytes

'send as bytes
  repeat i from 0 to 31
    spi.sendByte( byte[@values][i] )


'receive as bytes
  repeat i from 0 to 31
    byte[@values][i] := spi.receiveByte

Instead of a long array you can do the same with named longs:

DAT
  long Command,Data1,Data2,Checksum ...

and then use the address of the first long as begin of the bytes: byte[@Command]

Andy

lardom

Erlend wrote: »

...But a good advice is to only change as little at the time as possible of the demo code, and debug and check you get the results piece by piece, instead of doing a lot of changes and then despair when something does not work.

Erlend

I know the 'despair' of overwriting code that works. I try to rename my test code as "V1, V2..." I'm making good progress because for the first two weeks I couldn't transmit anything. I was depressed. I think I'll be ready to test a joystick within a week.
Ariba, I'll copy and paste that. Thanks.