Ic. ...but not really, or may be I need a bit shoe-horning: it is in regard to SPI... if I do SPI.send() of a String vs. and Uint8Array, I will get back a String? ...that would be the call for 'in the first place' (after also resolving the efficient creation of an 0x00 initialized String of a defined length).
While touching on the SPI.send() subject: it is now the second time that I would like to have something different from having to create a chunk of 'meaningless' memory for the SPI.send() to keep the receive clock ticking... (ILI9341 needs the same for reading from display memory). May be the very same chunk is simultaneously used as the reception buffer for what the send returns... but I don't think so: it would destroy the input. The SPI.write has this nice feature of providing an object with data and count. Adding this parameter option to the SPI.send() would save me the double amount of memory. Right?
To adjust my high-level thinking to what is 'below the line water line', I guess it is the time for me to look into the vm... (almost) ...to get a better understanding of the limitations (having implemented a few myself - limitations AND vms, quite a while ago).
Regarding String garbage collection, I expected an answer like this, because the way Espruino manages its memory (followed a bit the evolution regarding decreasing size of int, vars, etc. and read through the available performance information).
Thanks for being so responsive!
@allObjects I'm new to all this and have been reading up on SPI & sending dummy data in order to read - I found it very confusing but this is what I now understand:
SPI is always dual-direction (even if the data in one direction is sometimes ignored) so if the master expects to receive 24 bits of data from the slave, then it must send out 24 bits to generate all the clocking for the 24 bits sent in the other direction.
Some implementations may provide a "read" SPI function which provides the clocks without you having to specifically supply some "dummy" data to write.
I read that it may be more appropriate to use 0xFF rather than 0x00 for the dummy bytes
since the idle state is usually high - so sending FF is effectively doing nothing (not sure if this is correct?)
It may help clear things up a bit (I'm still not 100% clear)
I made use of your getPixel function in my buffered ILI9341 code - I was totally stuck without it - thanks.
© Espruino, powered by microcosm.
Report a problem