Non-destructive SPI transfer() call about embedded-hal HOT 8 CLOSED

I think one of the main advantages from a non-destructive variant would be to allow directly passing constant data for the write. On some architectures (ARM Cortex-M, at least), the this would allow write data to be read directly out of program memory. This won't actually save memory -- since a mutable buffer of the same length would still have to be allocated -- but it might have an ergonomic benefit, and possible a correctness one (allowing more use of non-mutable data is always a win, in my book).

It would avoid the necessity of two buffer-length copies per transaction (for repeated transfers, i.e. polling). I'm hesitant to assert that this would be a large gain in performance, though, since accessing memory is nearly always much faster than the serial transaction itself.

I think it would be a reasonable addition, and simple enough to add a default implementation for as with the current blocking transfer. I may take some time to throw a proof-of-concept together and open a pull request, so we can see how we like it in practice.

from embedded-hal.

@RandomInsano You can avoid the byte_copy() function by sub-slicing your data to an equal length slice before calling copy_from_slice().

from embedded-hal.

There’s thinking... thanks!

from embedded-hal.

Heh. Now, how about avoiding the copy altogether?

from embedded-hal.

I'm not really a SPI aficionado so I don't have any real world based opinion about whether that would generally be useful or more addressing of a corner case.

from embedded-hal.

Oh, yeah. No problem there @therealprof. I just re-asked to address the larger audience. If I hadn’t, people who skim usually assume this issue is addressed and move on.

A bit of detail here is that the Linux-embedded-hal is using Spidev from the kernel which itself can does save the buffer, the embedded-hal API doesn’t usually support that.

I think some data diving is required here. I’ll go skim the other crates to see who’s fought with this.

from embedded-hal.

I ended up abstracting away the ugliness, and really you’re right that memory isn’t going to be the bottleneck.

I’ll close it out if I ages out past 30 days with no real interest here.

from embedded-hal.

Closing in favour of #94

from embedded-hal.