Ability to pass a buffer of data to the SPI hardware interface

[nkolban]

Today, the architecture of Espruino when it comes to SPI hardware support is to take the array of data passed in by the JavaScript programmer through a call such as:

SPI1.send(myArrayOfData)

And invoke the board specific function called jshSPISend() for each byte contained within the data. Concerns have been raised that because jshSPISend() is only seeing one byte at a time, there is a latency (maybe small, maybe not so small) between sending one byte and the next.

One possible solution to this might be the presentation of the array of data directly to jshSPISend() with the contract that it send all the data as efficiently as possible.

For example, if an array of 300 bytes were supplied where each triple of bytes was a Red/Green/Blue for an LED then 100 LEDs could be lit from one call to jshSPISend(). Perhaps the board has hardware support to take an arbitrary sized buffer of data as input and send that through SPI without any further assistance?

[gfwilliams]

Concerns have been raised

By who? you?

It seems to me that you're trying to work around the fact that you don't want to go 'inside' the library that you found and just copy/pasted into Espruino against my advice. What happens if you have 2000 bytes? Now you can't allocate all that on the stack, so you have to do in in chunks, and then you have a MASSIVE gap in transmission when you ready the next buffer to transmit.

[nkolban]

My knowledge of JsVar is far from complete ... in fact it is pretty weak. I had assumed that one could create a "Uint8Array" which would then be a contiguous block of memory allocated from JsVars (perhaps as a Flat String). If that were then passed in as a parameter to jshSPISend() then there would be no stack buffer needed as the data would already exist in the JsVars pool?

Again, my notions could easily be all washed up and plain wrong ... my goals in creating these Issues is not to push an agenda (I have none) ... but to create discussion places by topic area where contributors and community members can group together.

As for not following your advice ... I'm lost. This was our conversation on including 3rd party software:

http://forum.espruino.com/conversations/277010/

I asked if we could include the library. You said yes ... but first ask the author ... I asked the author and he said yes.

Now at this point, we have not merged the SPI hardware library into the master at Github. If you don't think the utilization of the MetalPhreak library is appropriate, then, of course, you are free to reject the pull request.

There are so many other work items that need attention in the Issues list beyond SPI that if this one is going to cause contention, I suggest we simply skip it and move on to other items.

[gfwilliams]

The problem is that often you can't guarantee being able to get a big chunk of memory - especially on ESP8266 where people seem to be using up most of the RAM.

Or take for example SPI.write({data:0,count:128000}) (used when clearing a ILI9365 LCD) - where there will be more data to store than you'll ever be able to get in RAM.

Sorry about the confusion about the posts, I think I'd said 'yes you can do this but I wouldn't recommend it', but didn't really elaborate on the reasons.

The best solution right now would be to use spi_tx16 for jshSPISend16, remove any print statements, and to rewrite spi_transaction such that:

• first call: just sends, returns -1
• second call, sends second word, returns result from first send
• third call, sends third word, returns result from second send
• ...
• last call, sends nothing (given -1), returns final result

I think once that is done, it'll probably drive the WS2811 just fine.

[gfwilliams]

Fixed with jshSendMany