[ell-i-developers] ENC28J60 <-> SPI optimised -- not sure about the approach

  • From: Pekka Nikander <pekka.nikander@xxxxxx>
  • To: ell-i-developers@xxxxxxxxxxxxx
  • Date: Sun, 16 Mar 2014 22:20:26 +0200

Another push to feature-coap-temp.  Optimises the ENC28J60 -> SPI interface, 
saving some 500 bytes.

I'm note sure whether such an optimisation is the right approach, even though 
it saves memory.

The underlying problem is how dynamic the current Arduino SPI library is, 
preferring to use a dynamic SPI.begin() method that allows the chip select pin 
to be declared at runtime.  That least to the necessity of compiling in the 
Arduino PIN table, i.e. a data structure that defines each physical MCU pin 
each Arduino PIN is.  That takes about 0.5 kb.  Before SPI all of our code was 
carefully written so that the table could be optimised away at compile time.  
With the SPI.begin() interface that is no longer possible, at least not without 
link-time constant propagation.  And I think that wouldn't help either, I doubt 
even LLVM is able to do large enough constant inferences to be able to do that.

The latest commit in feature-coap-temp now connects the ENC28J60 code directly 
to our own low-level SPI API, written in C, allowing the dynamic Arduino SPI 
interface to be bypassed.  While that saves memory, it also makes our ENC28J60 
incompatible with other Arduino-compatible stacks.

In general, the current situation presents a dilemma between the Arduino  
XXX.begin(parameters)  API and our desire to perform all initialisations 
compile-time, thereby saving memory.  

Perhaps we should discuss at some point more generally what we really want with 
our low-end software.  And high-end, but that is a different story.  At the low 
end, so far I have presumed that preserving memory is a primary goal, but we 
should also weight that with Arduino API compatibility...


Other related posts: