Rust Programming Language RustFest Zürich 2017, 5 Nov 2017

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: RustFest Zürich 2017 - Fearless concurrency in your microcontroller by Jorge Aparicio

Description

Fast, efficient, safe: pick three.

Embedded systems are highly concurrent; they must respond to several different external stimuli within tight time constraints while maintaining a low power consumption. At the core of these systems we usually find microcontrollers, low end Systems on a Chip (SoCs) with just about enough resources to fulfill their tasks: tens of MHz of CPU frequency and a few KBs of RAM are usual.

In this talk we’ll explore how to do efficient multitasking on these systems using zero cost, memory safe abstractions.

About Jorge Aparicio:
Jorge Aparicio has been a Rustacean since Rust 0.9 (early 2014) and since that time he has many several contributions to the compiler, the standard libraries and the crate ecosystem. With his background in Mechatronics Jorge has been tackling, for more than one year now, the task of making Rust easy to use for embedded development with great success. He’s the author and maintainer of several crates and tools core to the ARM Cortex-M ecosystem.

A

Thanks for the introduction.

A

First, you can find these slides at that github link. If you want to look at them in more detail.

A

There are some links here, and there, if you want to check them later,.

A

My name is jorge aparicio., also known as japaric on github.

A

Right now, I'm a master student at luleå, university of technology,.

A

And I'm working with professor per lindgren and we do a research on real-time systems.

A

And we are using rust for our research.

A

Today,, I will talk about concurrency in microcontrollers.

A

So the agenda for this talk is to go through micro-controllers basics and then cover.

A

Cooperative multitasking and then go into preemption as an alternative for doing multitasking and.

A

We'll talk about the problems that arise from using preemption as a multitasking mechanism.

A

And then we'll talk about locks as a way to solve those problems.

A

Then I'll present a fearless concurrency framework that we have been developing.

A

And I conclude on some future work in this space.

A

First microcontrollers.

A

So we have these single core devices with a very small amount of ram and.

A

So why would you want to use a microcontroller in your application?.

A

The main reason is that you want to do I/o with the world.

A

So when you are working with the general purpose, computers, I/o means files,, sockets and data bases and when you're working with microcontrollers.

A

I/O means reading sensors, controlling motors.

A

Some of you may know that you can use single board computers, like the raspberry pi for this kind of I/o.

A

So why would you pick a microcontroller instead of a raspberry pi, which is more powerful and runs an.

A

Operating system like linux, so within those reason we have that microcontrollers are cheaper.

A

Which is good for business, they are simpler systems, so they are simple enough that you can program them from scratch.

A

They also have lower power consumption., which is good for battery life.

A

Most importantly, you can have full control over how tasks get scheduled on this system if you're not using an operating system and.

A

This is important if you have timing requirements in your application.

A

In this talk, I will be talking about bare metal system when there is no underlying os. That's when you get full control over.

A

Scheduling of tasks- and this is a minimal microcontroller program.

A

Using the quickstart framework, it looks no different from any other rust program. We have this no_std attribute at the top,, which means that the standard library is not available in this program.

A

Then we have some crates that will care of booting the device. Then you have a standard main function and.

A

A important thing to note here is that on bare metal systems.

A

You can only run one program at a time, and this program must never end so.

A

In this case, when the main function returns, it will put your microcontroller to sleep.

A

This quickstart framework gives you.

A

A

Level of support across different devices, and currently it supports cortex-m and msp430 microcontrollers.

A

And someone is already working on importing this to risc-v microcontrollers.

A

Next, how we do I/o on a microcontroller.

A

Basically, we have to just write or read memory.

A

Especially the region of memory called peripheral memory.

A

So this program does two.

A

Write operations, and the first one will turn an led on and the second one will turn it off.

A

This approach to I/o is called memory, mapped, I/o.

A

Let's look at three common peripherals that I use in some examples in this talk.

A

The first one is called general purpose: input, output.

A

So this peripheral lets you send digital signals through the microcontroller pins and with proper.

A

Electronics, you can use that to turn things on and off and.

A

The input part of this peripheral lets- you read some external binary state like.

A

"Is this button pressed or not?" this talk I'll use, this high-level led abstraction which give us an api to turn it on or off.

A

Another peripheral I'll be using are timers.

A

Timers are useful to generate periodic tasks and also to measure the duration of external events.

A

And in this program we use the timer as a periodic alarm and.

A

And we'll use this alarm to blink an led.

A

So we use this `bwait` method, which is a blocking method. We will wait until the.

A

Alarm goes off and we just study it to generate the delays in this program.

A

How does this `bwait` method, work?.

A

So this timer, you can read its status by reading the status register,. This status register is a.

A

32 bit of memory,, peripheral, memory, and.

A

When the alarm goes off, one of the bits of this status register will be changed to `1`. So what we do in this method is.

A

Continuously poll in the state of the register until the bit is set to `1`.. That indicates that the alarm has gone off.

A

This approach is called busy waiting because the processor will be.

A

Continuously polling, a register., it's a wasteful approach to I/o, but it gives us the delay. We want.

A

Another peripheral we use is called serial, which stands for serial port communication and serial port communication. Is this interface that allows you.

A

To exchange data between two endpoints at any given time, each end point can send data to the other side.

A

This program, here,, will start by sending a greeting to the other endpoint,, and then we will wait for some input.

A

Every byte it receives it will send it back to the.

A

The other side, so basically it's kind of a.... It will echo back all the received data.

A

Here as well, all the methods are blocking.

A

Now we can move on to concurrency.

A

Let's say that we want to run these two previous programs at the same time, so we want to create a new program that runs.

A

The two previous tasks, concurrently, we can use an approach which is called cooperative, multitasking.

A

Using generators.

A

So here's the method for reading a byte from the interface.

A

From the serial interface using generators,, so it looks similar to the.

A

`Bwait` I showed you before, but instead of.

A

Continuously polling the status register in this case, what this method will do is yield control back to the caller.

A

While the condition is is not met and then it will return the byte when it becomes available.

A

So using this generator "raise" api, we can.

A

Write the task as infinite generators.

A

The first task is this echo program from before.

A

The logic looks exactly the same: we'll read one byte and then send it back.. I will use the generator api.

A

And we use the `await!` macro.

A

To drive this generator to completion.

A

The important thing here is that the `await!` macro doesn't block.

A

Until the operation is complete, but instead it will yield control to the caller when you cannot make any more progress.

A

And the other task is the led blinking task.

A

Here I have changed slightly the logic, so you can see that generators can capture variables allocated on stack.

A

The `on` variable will track the state of the led and we'll use that for turning on or off and.

A

To generate the delay, we'll use.

A

A generator, a version of the `await` method, with the `await!` macro.

A

With those two tasks we can put them together in a program and.

A

To execute them concurrently, we have this infinite loop that will resume the generators.

A

One after the other, what you will do is that each processor will execute each task.

A

Until he cannot make any more progress on that task and it will switch to the other task and resume its operation.

A

So effectively it runs the two programs from before concurrently.

A

Note that this program still has busy waiting when the processor cannot.

A

Make progress on any of the tasks it will still continuously poll the status register.

A

Which burns cpu cycles.

A

Now imagine this scenario: you need to execute two periodic tasks, concurrently, like in the previous example.

A

But this time let's say that task 1 needs to be executed.

A

Every 10 milliseconds and takes 2 milliseconds to complete and.

A

The second task needs to be run every 1 milliseconds and takes 100 microseconds to complete.

A

So can these timing constraint be satisfying using cooperative multitasking.

A

If we analyze this problem and say that.

A

Task 1 is executed first and then 1 millisecond passes, while we're executing that tasks.

A

We'll get a request to execute the second task.

A

But since we are using cooperative multitasking if task 1, never yields control back to the caller, we'll continue its execution for another millisecond. That.

A

Means that in those 2 milliseconds we didn't execute the task. 2.

A

Which had to be run at least twice in that amount of time.

A

So task 2 missed its deadline twice.

A

In this case, and if this were our real-time application.

A

That could mean a system failure, because in real-time systems you cannot miss a single deadline.

A

So in general, using cooperative multitasking, we cannot always meet the timing constraints.

A

Instead, we need task prioritization in this example. If we had.

A

Task prioritization,: we could give tasks 2 a higher priority and.

A

That means that the processor could have a switch from executing task 1 to execute task 1, which have higher priority.

A

Once it is done with that,, then it can resume execution of task. 1.

A

Basically, we are saying here that task 2 can preempt the first task.

A

Micro-Controllers provide a hardware mechanism for preemption which are interrupts.

A

And basically interrupts are a callback mechanism provided by the hardware.

A

So how do they work?.

A

So each in interrupt is triggered by a different event,.

A

External event, and you can register an interrupt handler for each interrupt.

A

And this interrupt handler is basically just a function in this program. We register an interrupt for the `exti0` interrupt.

A

We register this handler function to deal with that interrupt and this interrupt is triggered when the user press a button.

A

So, in this case, the microcontroller will usually be executed in the main function.

A

But at some time at some point the user will press the button and when that happens, the handler will call our interrupt handler.

A

Once the processor is done, executing that interrupt handler.

A

We will resume the execution of the main function, so what we can say here is that.

A

The interrupt handler can preempt the main function.

A

Another way to see this is that the interrupts have a higher priority than the main function.

A

We can port one of the previous examples I gave.

A

The echo program- and in this case we can move all the logic.

A

Into an interrupt handler and we can set the interrupt to trigger every time, new data is available.

A

In this case, there is nothing to do in the main loop, since all the logic will be handled in the interrupt handler.

A

So in the main loop we can set the microcontroller to sleep.

A

Which save energy so.

A

This program has no busy waiting and is more energy efficient.

A

So when you're working on interrupts at some point, you will want to share memory between the main function and the interrupt handler,.

A

Or have some means of communication.

A

And actually, the only way to do that is to have a.

A

Statically allocated variable, and probably the first thing you will try- is to use this static built variable to.

A

Share memory between them and the problem with this variables is that.

A

Access to them is unsynchronized,, and if you do that, you will run into data races and race conditions.

A

So how can we do this memory sharing in a memory safe, way?.

A

One way is to use locks to synchronize the operations.

A

So, looking again, the previous program, we.

A

Have the main function and the interrupt handler, both modify this shared data variable and.

A

The problem with this program is that if the main function is modifying the data variable and it gets preempted by the interrupt handler.

A

Then the interrupt handler might observe that the data variable is is in some.

A

Inconsistent state, or it might even find.

A

Corrupted data.

A

So, to solve this problem and this data race, what we have to do is synchronize these two operations on the shared memory.

A

The synchronization for synchronizing these two operations, its just enough that one happens before or after the other.

A

And the other order is not important as long as both operation doesn't happen, midway of the other [operation].

A

And we can do that by disabling the interrupts in the main functions.

A

And when we do that,, while the main function is modifying the data variable, the interrupt handler cannot preempt. It.

A

That means that our operation on the shared memory will only happen either.

A

Before or after the operation in the main function and.

A

This give us the synchronization to eliminate that data race, and this program is no memory safe.

A

Note that, in contrast with mutexes, which we use in standard rust, programs, in this case, the,.

A

The interrupt handler doesn't need to lock. The data doesn't need to disable interrupts because it cannot be preempted by any other.

A

Interrupt handler now, what would happen if we had another interrupt handler to the previous program and.

A

Let's say that main and the two interrupts are contending for the data.. Is this program memory safe?.

A

And the answer is,, it depends.

A

It depends on the architecture if you are running this on a msp430 microcontroller, then in that architecture, interrupts are disabled. When you are executing an interrupt.

A

That means that if you are executing one of these interrupt handlers,, then it cannot get preempted.

A

Which means there is no data race on the operation that is executed in the interrupt handler. So in that case it's memory safe.

A

But if, instead, you were targeting a cortex-m microcontroller.

A

This architecture lets you assign priorities to the interrupt handlers and.

A

Interrupts handlers with higher priority can preempt lower priority, interrupts.

A

And in that case we cannot answer this question without knowing.. What's the exact priorities of both interrupts.

A

So now lets say that we are working with cortex-m microcontrollers.

A

And we have these three interrupts contending for the data,, but this time we know the priority of each one.

A

And this version of the program is memory safe.

A

Note that only the two lower priority interrupts need to lock the data before accessing it because they can be preempted by the highest priority. Interrupt.

A

And the highest priority interrupt doesn't need any lock to access the data, since it cannot be preempted by anything else.

A

Now, let's tweak that example, a little bit. again three interrupts with different priorities.

A

And this time only the two.

A

Priorities with the lowest...

A

So this program is memory safe, because the lower priority interrupt is blocking.

A

The `exti1` interrupt handler from preemption. (we must know that a race can happen here.). But if we are using this [rough] lock.

A

This operation will also block the highest priority, interrupt from running.

A

But in this case that interrupt doesn't need to be blocked because it doesn't access the data.

A

Can we improve this situation if we lock higher priority tasks from running?.

A

That is not good from a scalability point of view, because higher priority interrupts are supposed to run.

A

Because they have higher priority, in that they are not supposed to be blocked by lower priority interrupts, unless it is required for memory safety.

A

So we can use a different kind of lock, and this is valid only for cortex-m devices.

A

So, instead of disabling all the interrupts, we can raise the interrupt priority.

A

Temporarily, just to block some of the interrupts.

A

And these are the actual.

A

Operations that need to be done, and they only work for cortex-m3+ devices, interrupts.

A

If we use now this different lock in the previous program and.

A

We raise the interrupts, we raise the priority to 2 and the lowest priority. Interrupt. Will get...

A

Require a synchronization troubled data race,, but this time the `exti2`.

A

Interrupt won't be blocked by the lowest priority. Interrupt.

A

But in general, how can we pick this.

A

Temporal erase priority- and this is a problem that has been studied by the real-time research community since the 80s.

A

And an answer to that is the immediate ceiling priority protocol.

A

So in this scheduling policy this raised priority value is called.

A

Ceiling priority and.

A

Each resource, which means a shared variable, is assigned this priority ceiling.

A

Which is a priority equal to the highest priority of any task which might lock the resource?.

A

So we basically have to take the maximum value among all the priorities of the interrupts that access the.

A

Variable and this scheduling policy has an extra nice,.

A

Property, which is nice, which guarantees deadlock free execution if you use it, use it correctly.

A

Now we have seen how to use a lock.

A

To prevent data races, but even if you follow these guidelines.

A

Doing so by hand is error-prone, and also all the programs have a bit of unsafe code in them.

A

Instead, we'd like to write just safe rust code and have the compiler enforce that memory, safety for us.

A

And that's well where we have the real-time for the masses framework,, which is duke as rtfm.

A

This is actually a port of the "real-time for the masses" language to the rust language.. This language was atdeveloped.

A

Luleå, university of technology and.

A

It has some really nice properties.

A

So in this framework, the concurrency model is that you have tasks and resources and.

A

Each task in this model maps to a single, interrupt.

A

Which means that you can assign priorities to tasks and.

A

By using interrupts, you can have the hardware scheduled a task for you,, which means you don't have any.

A

Bookkeeping in your software, so basically there is no code for the scheduler.

A

A

The framework uses this icpp scheduling policy which guarantees deadlock, freedom and.

A

All the ceilings which are required by this policy are automatically computed by the framework and.

A

Since this model uses tasks which are interrupts.

A

Preemptive multitasking, but you can still do a cooperative multitasking as we saw the beginning.

A

The downside of all these nice properties is that the frame will require whole program analysis.

A

But as we'll see, it is not much of a problem.

A

In the current implementation, at least.

A

So, let's see how a rtfm application looks like. all of them have this `app!` macro, which is a specification of the application.

A

So the `app!` macro will have a declaration of all the resources and all the tasks in your application.

A

And the resources basically look like static variables.

A

A

Each one of these tasks will have a priority and a list of the resources he have access to.

A

In this particular example, we have the resources and two tasks that run on different priorities.

A

And the `owned` resource is only accessed by one task and the `shared` resource is accessed by both tasks.

A

This `app!` macro is where we have this whole program. Analysis downside.

A

So thing is that this `app!` macro will.

A

Have to have all your tasks and resources.

A

Declared there- and you can only have one instance of this macro in your application.

A

This basically means that you cannot split the declaration of tasks and resources across different crates.

A

So this `app!` macro will expand into the main function.

A

So the user will have to supply.

A

These two init and idle functions instead of the main function.

A

So this init function will run first,, we will take care of initialization, and it has access to all the peripherals.

A

And you will run with interrupts disabled.

A

And after, initialization have been completed,, interrupts will be re-enabled and you have this idle function.. This idle function is a never-ending.

A

Function and you can do cooperative multitasking here.

A

And then the user write tasks as normal rust functions and the signatures you see here are generated by the.

A

A

This resources, struct here, is generated also by the framework and.

A

It enforces the resource access, as is specified in the `app!` macro.

A

And the other thing that it does is minimizes locking operations. So in this case.

A

We see that in the second task. It cannot access the `owned` resource because in the specification.

A

We said that this task doesn't have access to that resource.

A

And it minimizes locking here.

A

As you can see, the first task can access it's own resource without any kind of lock and.

A

The highest priority task, which is the second one, can access the `shared`.

A

Resource without any locking, while the first task, which has lower priority, has to lock the resource to be able to access it.

A

So the rtfm framework uses locks as.

A

Some means to guarantee synchronization,, but we also want to support other synchronization patterns.

A

For example, you can also use atomics for synchronization and we're working on letting you use those with rtfm.

A

Because, right now, if you use them, you will have to lock the atomic to be able to use, and.

A

And a new case that users have raised is that.

A

There is this common abstraction of a ring buffer,, which has a single producer, single consumer.

A

In this case, you can kind of split your ring buffer into a producing a consumer and.

A

This data structure is interrupt, safe and lock, free and.

A

You can run the producer and the consumer on different tasks without any kind of blocking.

A

And we also working to get that working with rtfm without locking.

A

What's next in this application, space of real-time systems, so rtfm gives you this preemptive multitasking. That is very efficient.

A

But it's basically just a toolbox of concurrency primitives.

A

And the main way to do.

A

Communication between tasks is using shared memory,, but shared memory can get harder to reason about.

A

When you have larger programs, so the next extension to the real time for the masses framework are concurrent reactive objects.

A

Which kind of look like this.

A

So yeah,, I guess you can see that very well,, but.

A

In this case, we have a different model, we'll move to objects instead of resources, and we use message passing as a mean of communication between these objects.

A

So, and in this example, we have three objects and each one can pass information to the next one, using message passing.

A

So we have both synchronous in a synchronous message in this framework and.

A

Asynchronous message will be posted to an a scheduler. It will be executed later.

A

One other thing we have here is that we are adding timing, semantics.

A

So you can specify the timing requirements of your application?.

A

So you can say how often an interrupt is triggered.

A

And with that information, the framework will take care of computing, the priorities for you,, so you don't have to specify them.

A

This version of rtfm is not yet.

A

Released we are still working on it, so expect a blog post about that in the future.

A

Thank you! if you have any question, and if there is time.

A