You are reading a single comment by @allObjects and its replies.
Click here to read the full conversation.
-
Regarding @DrAzzy's comment about
...memory usage DOUBLE THE SIZE OF THE THING YOU'RE READING.
and @Gordon's option of
adding a SPI.read()
made me thinking:
How about the SPI.read() still consumes a memory 'block' for keeping the clock ticking like the SPI.send() needs to do so, but the SPI.read() would write into that very same provided memory block. When the data item read is a byte or less, the provided memory block is either a string or an Uint8Array(Buffer) where the byte would get stored, otherwise it has always to be an Array (like thing). The values read could be the same buffer or the number of bytes/itemns read.
allObjects
The only other difference I can think of is that there is something timing-related, and you're using your own BigRam builds (that are compiled without
RELEASE=1and so may be a bit slower?).Well, I made a bug yesterday for SPI send. If it returned Uint8Arrays you could conceivably do
SPI1.send(new Array(50))which would just allocate a sparse array.I think there's room for an
SPI.readfunction - if only to make it compatible with thepipemethod. I'm not sure how you'd stop it, but it could be very cool to be able to pipe data from some SPI device straight into an HTTP connection or file.