SPI Transaction Guard

[crteensy]

Hi Paul,

you asked me to ping you in early november (i.e. now) regarding a class or block structure that can be used to manage SPI transaction blocks.

Our discussion thread is here:

http://forum.pjrc.com/threads/26808-Scoped-SPI-transactions

[PaulStoffregen]

I think the possibility of a global or static instance makes this risky to give to novices.

[crteensy]

TL;DR: You cannot be serious about this point.

The SPI is a global object and poses this risk already; having to match pairs of beginTransaction() and endTransaction() is a symptom of that. I stick to my point that giving novices - and experienced users alike - a tool to automatically match them can't hurt.

Rephrasing your above point for a different class: "I think the possibility of a global or static SPI instance makes this risky to give to novices".

[PaulStoffregen]

I mean a global or static instance of the gaurd object. Wouldn't that keep a transaction open forever?

[crteensy]

It would.

That's why I first tried to come up with a structure that can not be stored, similar to ATOMIC_BLOCK (maybe you remember). It has some serious flaws, though, so I suggested a guard class.

Guards are a common concept in OO languages, and even novices can be taught how to use them. I would even say it's easier to use them than to match pairs of beginTransaction() and endTransaction() in non-trivial functions with multiple exit routes.

[vicatcu]

Scope an fundamental with guard object... i.e. the transaction
automatically begins when the object is created?

On Tue, Nov 4, 2014 at 6:16 PM, crteensy [email protected] wrote:

It would.

That's why I first tried to come up with a structure that can not be
stored locally, similar to ATOMIC_BLOCK (maybe you remember). It has some
serious flaws, though, so I suggested a guard class.

Guards are a common concept in OO languages, and even novices can be
taught how to use them. I would even say it's easier to use them than to
match pairs of beginTransaction() and endTransaction() in non-trivial
functions with multiple exit routes.

—
Reply to this email directly or view it on GitHub
#3 (comment).

[crteensy]

Yes, and the other important point is that a transaction automatically ends when the guard goes out of scope, because endTransaction() is called in the destructor. The destructor is called when the guard goes out of scope, and that is (at the latest) when any return statement is encountered.

[crteensy]

Now that there are two functional SPIs in the Teensy LC, I'll bump this because it's even harder to have matching pairs of SPI.beginTransaction(), SPI.endTransaction(), SPI1.beginTransaction() and SPI1.endTransaction().