[ell-i-developers] Cmd + Buffer transfer with SPI Class Design Decision
- From: Ivan Raul <supra.material@xxxxxxxxx>
- To: "ell-i-developers@xxxxxxxxxxxxx" <ell-i-developers@xxxxxxxxxxxxx>
- Date: Wed, 5 Mar 2014 18:57:16 +0100
Dear All.
I encountered a compatibility problem when reimplementing the enc28j60
controller that depends on the modified SPI API (that is planned to be a
future feature to be added to the Arduino project).
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.
Then, I foresee two design possibilities.
(1) Modify the SPI API to include one more "transfer" overloading that
handles sending one byte and immediately after a buffer. There are multiple
possibilities for implementing this. The first one that pops to my mind is
to implement the only buffer case as a sub-case of the command one, and
give the buffer first value as command.
(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.
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.
But I am not sure if it is the optimal decision, or there exist maybe
another option that I could not see right now.
Please, discuss and comment as required.
With Warm Regards, Ivan Raul
Other related posts:
