Scoped SPI transactions

[crteensy]

Added SPI_TRANSACTION_BLOCK macro

[PaulStoffregen]

I sent a message to Arduino's developer mailing list, asking for feedback and whether they might like to ever incorporate this into Arduino's official SPI library. Before I do anything, I'd like to allow at least a week for conversation there.

If this ends up forgotten without any activity (and without massive controversy from Arduino), please ping me in early November. That still should be plenty of time to get merged, for Teensyduino 1.21 in January.

[crteensy]

Noted, "ping Paul in early november."

In the meantime, we might come up with a clever solution for the nested loop problem I pointed out in the forum...it breaks certain program flows.

[crteensy]

I suck at using git.

[matthijskooijman]

Proposed syntax looks good and useful to me.

I didn't really like that done variable at first, but looking closer it seems like a good way to make sure the loop runs exactly once. I am wondering if it's really necessary to put it inside the struct and even more if you need a done() accessor - just extra clutter.

Did you look at the produced machine code? I'm wondering if the compiler is smart about this, or if it introduces an actual loop and done variable...

[crteensy]

@matthijskooijman To be honest I didn't look at the produced code, and with some minor trickery it might even be possible to let gcc remove all the unnecessary loop-ness although it doesn't unroll loops by default. That would have to enabled with the -funroll-loops option, which is apparently not included in the usual optimization options.

More important might be the fact that the proposed macro breaks the "expected" behavior (the behavior expected by those who just "use" the macro) of break and continue statements if it is used within an additional outer loop; see http://forum.pjrc.com/threads/26808-Scoped-SPI-transactions?p=56113&viewfull=1#post56113

[matthijskooijman]

Agreed on the break problem. I can't really see a way around this, though. You need to introduce a variable into the next block scope, and the only way I can think of right now is using a for loop. The ATOMIC_BLOCK macro suffers from the same problem, which is an indication that no solution exists for this (at least not in C, ATOMIC_BLOCK can't use C++).

[crteensy]

The cleanest solution is the introduction of a guard class that manages an SPI transaction (construct: beginTransaction(), destruct: endTransaction()). However, nothing keeps users from actually storing such a guard object, in which case it might block the SPI forever. That's why I tried the anonymous struct trick.
One way to make this a bit safer, though, would be a mandatory constructor argument of type struct I_PROMISE_NOT_TO_STORE_THIS {}; or similar.

[matthijskooijman]

Nothing wrong with having an anymous struct like this (did I say something to suggest that?).

Also, users are free to call beginTransaction and never endTransaction already, of course :-p