[ell-i-developers] On Arduino and concurrently

From: Pekka Nikander <pekka.nikander@xxxxxx>
To: Ivan Raul <supra.material@xxxxxxxxx>
Date: Sun, 6 Jul 2014 09:35:02 +0300
FYI.  Ivan, I think the message below gives you some nice background for the 
motivation of your thesis work.

All (on the ell-i developers core group), the arduino developers list is again 
getting more active and there is more discussion of this kind, clearly 
indicating their internal controversies and giving context to their overall 
approach.  I think more of us should follow what's going on there, allowing us 
to understand better the overall situation in the embedded runtime market.

--Pekka

Begin forwarded message:

> From: Paul Stoffregen <paul@xxxxxxxx>
> Subject: [Developers] Event callbacks (was: Serial.room(), or "ready" or....)
> Date: 6 Jul 2014 0:37:53 GMT+3
> To: developers@xxxxxxxxxx
> Reply-To: developers@xxxxxxxxxx
> 
> On 07/05/2014 01:15 PM, Tyler wrote:
>> Hell, we might as well add a callback function that gets called with the 
>> data when there is some... that could be useful instead of everyone trying 
>> to implement their own polling solutions. Would asynchronous callbacks even 
>> make sense on a platform like Arduino?
> 
> Well, I wasn't going to bring this up, at least not for quite some time.
> 
> Today we have serialEvent() in the official Arduino API.  The serialEvent 
> callbacks are only made each time loop() completes, which minimizes 
> compatibility issues, but doesn't always give responsive results.
> 
> The other extreme involves making callbacks from interrupt context.  There 
> are 2 huge problems with interrupt context.  First, properly managing shared 
> data is a topic even experienced programmers find difficult.  Second, many of 
> Arduino's functions and libraries aren't reentrant or otherwise fail if used 
> from both main program and interrupt context.
> 
> I recently implemented serialEvent on Teensy, and in doing so, I'm starting 
> an experiment to try to achieve something roughly in the middle of these 2 
> extremes.  The idea isn't new, and I believe it was discussed on this mail 
> list a couple years ago, of course with much controversy, like almost 
> everything discussed here.  The basic idea is to do the callbacks from 
> yield().  Teensyduino calls yield in all blocking operations, like delay() 
> and Serial.write().  I implemented a static flag inside yield() to prevent 
> recursive calling, for example, if anything you do in serialEvent calls 
> something which calls yield again.
> 
> I'm probably going to expand this experiment with a timerEvent API, offering 
> 1 ms resolution.  The millis interrupt will merely set flags.  The callbacks 
> will never be made from interrupt context.  All callbacks will be made from 
> yield(), which is a trade-off that avoids the worst issues with concurrency & 
> data sharing, because the compiler assumes called functions can read or write 
> any memory locations.  It's also a trade-off for latency, where CPU-hogging 
> code can still delay the callback, but at least callbacks will be timely for 
> the common case where sketches do lots of I/O.  I might add more yield() 
> calls in other cases, like when Serial.available() returns zero, to improve 
> responsiveness.
> 
> Why am I bothering to write this?  Long term, Arduino needs to facilitate 
> more concurrency.  I've spent a lot of time looking at various approaches, 
> which I'm not going to enumerate in this already-too-long message.  My belief 
> is event callbacks, called from main program context, are by far the most 
> novice-friendly way to provide concurrency.
> 
> This isn't a proposal for Arduino.  Right now, it's merely an experiment I'm 
> trying on Teensy to implement a lower latency serialEvent callback.  When/if 
> I expand to timerEvent, I'll probably ask here if there's any interest to 
> tentatively agree on the API, in the interest of future compatibility if 
> Arduino ever decides to implement it.  I'm really not looking forward to 
> making any such proposal.  Just imagine how hard that will be, compared to 
> this fairly simple write status!
> 
> But for now, I'm going to put together a simple pull request for 
> writeBufferFree, and over the next few weeks I'm going to focus on SPI 
> transactions, because we all desperately need the many SPI-based libraries to 
> be able to work together.
> 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to developers+unsubscribe@xxxxxxxxxx.
[ell-i-developers] On Arduino and concurrently

Other related posts:
