[ell-i-developers] Re: Cmd + Buffer transfer with SPI Class Design Decision

  • From: Pekka Nikander <pekka.nikander@xxxxxx>
  • To: ell-i-developers@xxxxxxxxxxxxx
  • Date: Wed, 5 Mar 2014 21:49:10 +0200

> The problem concretely is that the previous implementation of the enc28j60 
> interface completely depends on the "command + data" spi interface. That is 
> incompatible with the new SPI API, that is designed for "only data" interface.
...
> (2) Reimplement the Enc28j60 interface to generate "only buffer" calls to the 
> SPI API by inserting the command as the first element of the buffer and the 
> real buffer from the second place and ahead, increasing the length of the 
> current buffers by one.

This sounds good to me, but I don't know (or remember) what is the structure of 
"the current buffers".

If I understand correctly, the idea is that when sending commands, you would 
have a 2 or 3 bytes long buffer.  When calling transfer, the first byte 
contains the command and the second the argument, if any.  When returning, 
either the second or third byte contains the reply, depending on the type of 
the read command.  In the real implementation, the SPI controller always reads 
and writes the same number of bytes, i.e. either two or three, but some of them 
are dummy bytes.

> After some thinking, I am leaning toward the second, as the new CoAP 
> implementation already allows the feature to pass the buffer pointer as 
> function parameter at different positions of the buffer. Passing the buffer 
> through the stack already relies on this characteristic. Then, the 
> modification needed is to increase the size of the buffer by one, to allow 
> inserting the command at the very beginning of the buffer.

Right.  When reading and writing data buffers, I would simply reserve the few 
additional bytes at the beginning of the buffer holding the Ethernet packet.  

I would also make sure that the first byte of the Ethernet address is aligned 
at a 4 (or 8) byte boundary, so that the rest of the code can rely on correct 
alignment. 

--Pekka


Other related posts: