[ell-i-developers] Initial Ideas for Enc28j60 Library and Arduino SPI Library

  • From: Ivan Raul <supra.material@xxxxxxxxx>
  • To: "ell-i-developers@xxxxxxxxxxxxx" <ell-i-developers@xxxxxxxxxxxxx>
  • Date: Fri, 21 Feb 2014 22:11:09 +0200

Dear All.

Good Evening.

First I will discuss my ideas regarding the adaptation of the current
enc28j60 (Ethernet Controller for the Ellduino Board) to the Arduino SPI

In general, the SPI communication serves for three purposes:
1. Access control registesrs
2. Read / Write the Ethernet Buffer
3. Access PHY Registers

Those activities can be divided in two classes with respect to the SPI
access behaviour:

Accessing registers imply the interchange of two to three bytes:
    2 bytes for the ETH registers
    3 bytes for MAC / MI registers
    (the access of PHY registers involve sequences of write and  reads to
MI registers)

Those sequences can be easily and relatively efficiently realized with the
current Arduino SPI library that is limited to accessing 1 byte at a time.

The real problem comes with the access to the Ethernet Buffer. In
particular, it is optimized for sequential reading / writing after a
command. In that sense, the Arduino current implementation is simply not
adequate. I completely understand why the current interim implementation of
SPI.h from Pekka is actually oriented to read + write a buffer. (In that
implementation,  the 8 bit access is underlying a buffer transfer with
length of 1 byte)

Two more aspects are important regarding the enc28j60 IC.

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.
Two main advantages I foresee of that line: it can offer alerts of DMA
transfer completion, but more important it allows the of Wake-On-LAN/Remote

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.

1. Without DMA: The efficient option is to use a thread that blocks and
gets awaken by the interrupt of the SPI transfer. 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)

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.

So, to summarize:
1. The Arduino SPI API needs buffer transfers to allow the usage of the
2. Withot DMA, a threaded application can be easily adapted to the current
3. DMA is definitively the next step (not only for us, but for Arduino too)

I will discuss more about the DMA topic for Arduino in the next message.

With Warm Regards, Ivan Raul

Other related posts: