[TriEmbed] EMT: Fergetaboutit Re: Energia MSP432

[Pete Soper]

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 
swamp-draining goal.

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 
looking IDE.

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!

-Pete


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:
>> Alex,
>> 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.
>>
>> -Pete
>>
>
> --
> "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...
URL: <http://mail.triembed.org/pipermail/triembed_triembed.org/attachments/20160414/8353cca7/attachment.htm>