Extending SPI by exposing zephyr SPI capabilities. (probably applies to many subsystems) #14
Comments
|
@KurtE |
|
I have examples working for updating the display a few different ways using my updated ILI9441 library, which is up I have the display being updated, a few different ways:
Timings for drawing 5 full screens (different colors): So the Zephyr one is not that much faster than the SPI buffered transfer. i.e. the spi_transceive being called once versus 240 times per screen. However it also saves a lot of memory. That is using: I use up an extra 640 bytes of memory to copy into, and then the above call use 640 bytes of stack space, to receive the pixels //============================================================================= //----------------------------------------------------------------------------- //----------------------------------------------------------------------------- #define BLUE 0x001F //**************************************************************************** extern void UpdateScreen(); void setup(void) { } //**************************************************************************** void loop() { void UpdateScreen() { |
|
Not sure this is going anywhere, I hacked up the tft_picture_view_sd_zephyr sketch to overwrite the SDFat default SPI driver implementation, To use this with this sketch you need to: Without using the zephyr code, timings were like: With the code turned on. That is for the photo: !!File:Sharon Barn.bmp Annie1.bmp from 3.269 seconds down to 0.385 or 8.49 times faster... So I think something along this line is worth it! |
|
Follow on to the timings I mentioned: You can see some comparisons of the times mentioned in the previous message versus: Teensy MicroMod: !!File:Sharon Barn.bmp Time:1817 writeRect calls:0 GIGA: Portenta: (Note I did not write down the full numbers but: |
|
@KurtE I like option
the most, since it won't touch the existing APIs but will allow a much greater degree of freedom for hacking without touching the code. |
…iables resolves arduino#13 And: provides for c) option in arduino#14 In particular, added another config option (config16) that is initialized at beginTransaction with same settings as config except word size set to 16 instead of 8. Also: updated begin() to call beginTransaction with default SPISettings, and the endTransaction, such that sketches that don't call beginTransaction output at the default settings. Changed the header file private: to protected
|
As I mentioned in PR#18 I changed private: to protected: I created a quick and dirty sub-class Had sketch with some code to see if I could use this. The only way I saw was to I then verified I got the same information from this as I was getting by my hack version: and the output was correct: |
|
@facchinm - This could be own issue, or part of this one: Asynchronous SPI transfers: Reading the Zephyr documents, I see they have some functionality to do this, including: However, this API is under the: #if defined(CONFIG_SPI_ASYNC) Which my example sketch now runs. Note I have not gone through the code to see if this is done by DMA or interrupt or polling or ??? Suppose I instead wish to do this outside of this, can I setup my own DMA to do this? I have a version of my Thanks |
Overview:
Suppose in a library (or sketch), I wish to use some of the more powerful capabilities of the Zephyr system. For example in SPI,
I may wish to output a whole display frame of pixel data: for example an ILI9341 with 320x240 pixels, or 153600 bytes.
Currently with the SPI library, I have the choices of calling simple SPI.transfer(), where for each pixel I have to do something like
SPI.transfer(color >> 8); SPI.transfer(color & 0xff);
Which is rather slow. That is there is a lot of wasted time on the SPI buss.
Or assuming SPI.transfer16(color) works. #13
We can cut the time down more or less half.
The only fast alternative is to use: SPI.transfer(buf, cnt)
However, we have to use a secondary buffer, and reverse the bytes into that secondary buffer, but it does speed things up.
And the transfer overwrites the buffer, with the return data, which is unneeded in this case.
What I would like is the ability to do: SPI.transfer16(send_buf, recv_buf, cnt);
where the two buffers are optional. Can do send only or receive only or send and receive...
And in some case I might want to do this asynchronously, maybe using DMA.
It looks like Zephyr has a lot of these capabilities built into their SPI device. That is the spi_transceive function that our SPI library is calling allows most of the above.
Question, how much of the above can/should be included in the main Arduino SPI library? And if it is not implemented as part of the SPI library, how much should we facilitate, making it easier for developers to implement faster and more efficient SPI functionality?
There are several possibilities:
a) Add some additional methods to the SPI library, for this. Several of other SPI libraries have additional methods, including those for the Teensy and likewise ESP32.
b) Add methods to SPI, that exposes some of the internal data, like:
Which allow one to gain access to the underlying zephyr SPI object and the config. Note: one could use their own config object without too much problem
c) change the SPI object, to use protected: instead of private: than one could create a new sub-class
like: class extended_SPI : public SPI { ...
d) Hack it, which I will likely do to experiment:
and then maybe in my display code, I might have something like updateScreen:
might change from something like:
maybe to something like:
Which does not need secondary buffer, nor time to copy it into it and reverse the bytes
Thoughts?
The text was updated successfully, but these errors were encountered: