[ell-i-developers] Re: Initial Ideas for Enc28j60 Library and Arduino SPI Library
- From: Pekka Nikander <pekka.nikander@xxxxxx>
- To: ell-i-developers@xxxxxxxxxxxxx
- Date: Sat, 22 Feb 2014 19:20:20 +0200
Ivan,
> First I will discuss my ideas regarding the adaptation of the current
> enc28j60 (Ethernet Controller for the Ellduino Board) to the Arduino SPI
> Library.
I think your analysis and understanding is basically right.
> ... why the current interim implementation of SPI.h from Pekka is actually
> oriented to read + write a buffer.
I actually already pushed an interim implementation. It is not tested at all,
uses too much memory, and most probably won't work, but I temporarily ran out
of energy and wanted to get it out. OTOH, the buffer-oriented implementation
should be relatively efficient even for one-byte transfers, due to the inlining.
> First, the circuit offers an interrupt line that can be connected to the host
> MCU. For that reason, I ask through this channel if that line is actually
> wired to the MCU in the Ellduino, and if it will be also connected at the
> newer board versions.
Yes and yes. In Ellduino it is connected to PC10. IIRC, in Baselli the plan
is PA2. In general, it is always a good idea to check from the schematic.
> The second aspect is the DMA. As in the first version of this stack it won't
> be used, it is important to cite the developing options that I consider
> appropriate.
Agree.
> 1. Without DMA: The efficient option is to use a thread that blocks and gets
> awaken by the interrupt of the SPI transfer.
It may not be that simple, as you need to consider that both packet sending and
receiving may be asynchronous (think of protocol timers.)
> In that sense, the Arduino API already offers the possibility to
> enable/disable the SPI interrupt. Then, there is not needed any modification
> to the Arduino API, as the interrupt activation can as side effect activate
> the blocking of the thread until the SPI is completed. When deactivated,
> basic polling can be used (as in the current SPI implementation of oct9-demo)
I don't understand this comment. If we are running at a relatively high SPI
speed (as IIRC we do), then the other threads won't have a proper chance to run
if we use two-byte SPI transfers with interrupts, due to the relatively high
interrupt latency. I think the current busy-loop with yield() is most probably
better. But I have never tester or analysed properly, I may well be wrong.
> 2. With DMA: For future development, the DMA option will overload the
> processor and in case the interrupt line is connected to the MCU, then it can
> simply synchronize when the transfer is completed.
I guess "overload" is a spelling mistake, or I don't understand what you mean.
When the DMA transfer is complete, the DMA can (and should) interrupt the MCU.
> So, to summarize:
> 1. The Arduino SPI API needs buffer transfers to allow the usage of the
> enc28j60.
Agree.
> 2. Withot DMA, a threaded application can be easily adapted to the current API
Hmm. Maybe.
> 3. DMA is definitively the next step (not only for us, but for Arduino too)
Agree.
--Pekka
Other related posts:
