search

PaulStoffregen / SPI

SPI library for Teensy & Arduino IDE
http://www.pjrc.com/teensy/td_libs_SPI.html
137 stars 130 forks source link

SPI Transaction Guard #3

Open crteensy opened 10 years ago

crteensy commented 10 years ago

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 commented 10 years ago

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

crteensy commented 10 years ago

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 commented 10 years ago

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

crteensy commented 10 years ago

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 commented 10 years ago

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 notifications@github.com 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 https://github.com/PaulStoffregen/SPI/issues/3#issuecomment-61733057.

crteensy commented 10 years ago

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 commented 9 years ago

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().