Extending ulisp with SPI 16bit -> transfer16


#1

Hi David

Some SPI devices operate in 16bit spi.
I’ve seen in the arduino lib’s that there’s also a ‘transfer16()’
How do you feel about implementing it in ulisp ?
I was thinking something like (write-word ) and (read-word ).
I could use it for a realtime clock which works in 16bit spi.

Kind regards,
Ronny


#2

Hi Ronny,

Thanks for the suggestion. It seems that the SPI library’s transfer() and transfer16() functions are a bit different from uLisp’s read-byte and write-byte, as they do a simultaneous read and write.

Currently write-byte returns nil. Perhaps if called with an SPI stream it could return the result of transfer(), thus avoiding the need for another function? The same could be true of write-word for transfer16(). What do you think?


#3

Hi David,

Hi Ronny,

Thanks for the suggestion. It seems that the SPI library’s transfer() and transfer16() functions are a bit different from uLisp’s read-byte and write-byte , as they do a simultaneous read and write.

When writing a byte to a spi device it always returns something. So I think that this doesn’t make any difference. A write byte always gives reads back the result , although its useless of course.

Currently write-byte returns nil . Perhaps if called with an SPI stream it could return the result of transfer() , thus avoiding the need for another function? The same could be true of write-word for transfer16() . What do you think?

I think this is not so bad at all , since you can decide than what to do with the return (use it or not).

Regards ,
Ronny


#4

Hi David ,

I tried replacing spi.transfer with spi.transfer16 and it gave me a 16 bit stream on the clock and MOSI line !
The problem however , is that the high byte is always zero.
I think because of the char c in write-byte ?
Changing this to int c gives errors which I am not capable of solving .

How do you feel about it , for implementing in let’s say arm version ?
For avr I find it a bit to heavy , but maybe on arm it would be a nice thing to have.

Kind regards ,
Ronny


#5

I didn’t want to delay the release of Version 2.8 to incorporate this, so I’ll investigate how easy it will be to do, and if possible, include it in a future update.


#6

Ok , thanks .

Ronny