[TriEmbed] EMT: Fergetaboutit Re: Energia MSP432
pete at soper.us
Thu Apr 14 18:58:21 CDT 2016
Rob's note makes me want to dig a little further. :-)
If preemption of a running task by the scheduler in response to an
interrupt is impossible in this environment, then maybe variables
declared volatile can be safely shared. The user would need to know that
anything that might cause a task to go through the scheduler (i.e. time
delay, I/O operation, etc) can give control to another task and plan
accordingly. For example, traversing and mutating (changing) an array
and doing something that could suspend the task before the traversal is
complete would make for unhappiness if the point was to share it.
But almost anybody that's going to exploit this multitasking feature is
going to want to communicate between interrupt and non-interrupt levels,
and then even mutation of scalars has to be guarded. Except there's no
way to do that on MSP432, using the "official" APIs. So my last post was
with the next step in mind but I was lazy and painted with a broad brush.
I spent a while this morning looking for the MSP432 equivalent of the
AVR cli/ste operations, and I think I found them ("
Interrupt_disableMaster" and "Interrupt_enableMaster"). But the point of
the original exercise was to express more enthusiasm for the MT features
and instead I found myself wondering if trying to use these primitives
was straight forward or the equivalent of juggling chain saws. The funny
thing is that if I'd found a way to use the M4's load exclusive/store
exclusive instructions I'd have gotten a nice lock implementation in
place and wouldn't have tripped over the lack of an
interrupts/noInterrupts implementation until later.
The proper solution is to use the official TI RTOS APIs if the rest of
the Energia runtime is compatible, but that's also way past the original
So, excuse me for applying tar and feathers to the MT feature because of
the lack of an interrupts/noInterrupts. And again, Energia is a great
As for thread safety in the Arduino runtime environment, I have ask:
what threads? :-) I think the thread safety that would have to be in
the Energia MT environment hinges on the scheduling semantics and
whether the rug can ever get yanked out from under a task while it's in
a shared library.
One thing I noticed that might be relevant to this: Doing Serial.begin()
within one task prevents Serial.print() working in other tasks, whether
or not they call Serial.begin() too. The calls in the other tasks simply
do nothing. I wanted to see what level of interleaving or chaos would
ensue if I just let them chatter away without providing critical
sections, but it appears they've got that covered.
There is a big forum hosted by 43oh for topics including Energia and it
would be interesting to know if there is an explanation of the I/O
semantics with multiple tasks.
Finally, I've dealt with TI folks off and on for 38 years. My first
embedded work was with a little TI9900-based system we turned into a
combination stat mux and terminal emulator. I wish TI and its people
nothing but the best!
On 04/14/2016 02:49 PM, Alex Davis wrote:
> This reminds me of the pjrc.com forums discussions where people decide
> to take it 'to the next level' with teensyduino on the ARM core stuff
> and then discover the arduino libraries aren't thread-safe and have
> all sorts of issues sharing the SPI bus and things like that.
> If we can get more than a handful of people working with the STM
> Nucleo boards via mbed and FreeRTOS, we'll probably avoid issues where
> someone gets hopelessly stuck or discouraged.
> On Thu, Apr 14, 2016, at 02:26 PM, Pete Soper wrote:
>> That multiblink Energia example sketch is very cute, but when I
>> started to play with the "Energia MultiTasking" feature I found it to
>> be generally useless. It's a novelty. One only has to go to the
>> energia.nu description page where they say " Interprocess
>> communication can easily be done by using global variables" to see
>> how messed up this is. There are zero task-related primitives
>> available. I thought "OK, I'll make the globals usable for
>> communication" and I made a trivial spin lock implementation to
>> enable this. Except nobody got around to implementing interrupts()
>> and noInterrupts(). I spent a while rummaging through the sources and
>> found a very low level routine that might do the job, but then I
>> realized what a perfect rat hole I was in. There was an issue filed
>> about this in July of last year (#675) and I may add a remark.
>> But this is moaning about a feature I had only been vaguely aware of,
>> and so as far as I'm concerned the MT examples are really hints about
>> the fact that (I think) the entire TI RTOS is sitting inside the
>> Energia runtime, and that may be relatively easy to use at some point.
>> Vanilla sketches with the MSP432 seem to work fine and Energia ought
>> to provide lots of fun for folks exploring their boards. But I'm
>> popping my stack and going back to exploration of FreeRTOS via the
>> mbed/export/gcc path.
> "The theater of noise is proof of our potential."
> |\ | (¯ \/ |¯\ |V| |\ ¯|¯ |¯) | \/ | | | |¯\ (¯ /¯ /\ |V|
> |-||_ (_ /\ |_/ @| | |-| | | \ | /\ |^| | |_/ (_ . \_ \/ | |
> You won't find me on Facebook.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the TriEmbed