Can I generate a runtime with a less restrictive profile ?

[NicoPy]

Ravenscar is a very restrictive profile. This makes coding some functionalities very complex when not impossible. For example, timeout management is not possible. Is it possible to generate a runtime with less restrictions ? If yes, which configuration files have to be modified ?

[Fabien-Chouteau]

Hello @NicoPy,

Ravenscar is a very restrictive profile. This makes coding some functionalities very complex when not impossible. For example, timeout management is not possible. Is it possible to generate a runtime with less restrictions ? If yes, which configuration files have to be modified ?

Lifting tasking restrictions requires implementing more features in the run-time, it is not only a configuration.

Note that there is a new profile (Jorvik) being standardized with less restrictions than Ravenscar: http://www.ada-auth.org/standards/2xaarm/html/AA-D-13.html

Our ravenscar-full run-times already implement most of the Jorvik profile.

[NicoPy]

My problem is that neither Ravenscar nor Jorvik profiles enable select statement. No select, no timeout management.

[Fabien-Chouteau]

Ravenscar and Jorvik are designed to allow a simple tasking implementation for embedded and safety-critical systems (schedulability analysis, determinism, lower cost for certification, etc.). select and many other Ada tasking features do not fit that bill.

You will have to play within the constraints of the profiles.

[NicoPy]

Ravenscar and Jorvik are designed to allow a simple tasking implementation for embedded and safety-critical systems > (schedulability analysis, determinism, lower cost for certification, etc.).

That's what I have understood. Most embedded systems are not safety-critical systems.

You will have to play within the constraints of the profiles.

No, I will not use Ada. I was investigating Ada on embedded systems to let me know if it suit my needs. The answer is no. With only Ravenscar and Jorvik profiles available, programming an embedded system has no benefit compared to C. Ada is much better than C as a programming language. But the restrictions of the profiles are a real problem.

[Fabien-Chouteau]

Most embedded systems are not safety-critical systems.

Indeed, but Ravenscar is designed for this systems.

I was investigating Ada on embedded systems to let me know if it suit my needs. The answer is no. With only Ravenscar and Jorvik profiles available, programming an embedded system has no benefit compared to C. Ada is much better than C as a programming language. But the restrictions of the profiles are a real problem.

I don't understand the comparison here, C doesn't have any standard multi-tasking. You are going to need an RTOS, or an embedded OS of some sort if you want this kind of features. In which case you can very well use Ada on top of that RTOS like you would do with C, only the secondary stack will require some adaptation.

Ravenscar is not the alpha and the omega of embedded Ada programming, you can do without it.

[damaki]

@NicoPy you might find the following article useful to work within the restrictions of the Ravenscar profile:

Guide for the use of the Ada Ravenscar Profile in high integrity systems - http://www.sigada.org/ada_letters/jun2004/ravenscar_article.pdf

Section 5.11 is titled "Programming timeouts" and shows a technique of using a second task to perform the timeout.

Another technique I've used before (and you may find useful in your case) is to change my task from being event-driven (blocking on a protected object) to being a cyclic task (e.g. runs every 10 ms using delay until in a loop). Each time the cyclic task runs it polls the current operation to check if it has finished, or else checks for a timeout by checking the elapsed time since the operation was started, and whether it has exceeded the timeout period (using Ada.Real_Time.Clock).

[NicoPy]

I was investigating Ada on embedded systems to let me know if it suit my needs. The answer is no. With only Ravenscar and Jorvik profiles available, programming an embedded system has no benefit compared to C. Ada is much better than C as a programming language. But the restrictions of the profiles are a real problem.

I don't understand the comparison here, C doesn't have any standard multi-tasking. You are going to need an RTOS, or an embedded OS of some sort if you want this kind of features. In which case you can very well use Ada on top of that RTOS like you would do with C, only the secondary stack will require some adaptation.

I'll try to better explain my point of view. I program µControllers with C for 25 years now. I started with bare-metal then used various real time kernels. I'm tired of all bugs easily generated with C. So, I decided to learn Ada. Ada is better than C because of strong typing and embedded tasking. Ada tasking model is more than just task sequencing and related stuff. With Ada, you have embedded inter-task communication. With C, to send commands/data to a task, you're on your own : Create a FIFO (Most of the time you have to code it yourself). Create functions to fill the FIFO with correct command/data (a struct of your own). Create a task which pump FIFO and decode command/data. When you change the RTOS, you have to recode everything. The FIFO internals, the task definition, the task instanciation... With Ada, you just use task, entry and select. You can concentrate on the functionality of your program, not the infrastructure. Ravenscar is good at what it is designed for : high-integrity provable systems. But for standard embedded systems, it is too restrictive since coding simple things is not possible. For example, the lack of select prevents the simple inter-task communication Ada provides. You have to carefully code a complex alternative to workaround the restriction. More lines of code mean more risk of bugs. Especially when task are in the game. In the end, you loose part of the advantage of using Ada. I understand that implementing a Ravenscar profile is easier since it has less functionalities. It also generates smaller binaries, which is a good point with most embedded systems. I'm studying Ada on my spare time, at home. I do it for my knowledge and, in the end, use it at work if I think it is worth the effort. Learning Ada is not easy. I don't want to learn another RTOS (which one ?) with Ada. What's the benefit of Ravenscar+RTOS compared to a more feature complete Ada implementation ? Adacore is promoting Ada for adoption by programmers. This is a good thing. But you need to address a more general application market to succeed.

Ravenscar is not the alpha and the omega of embedded Ada programming, you can do without it.

What do you mean ? Is there another Ada implementation for µcontrollers ?

[NicoPy]

@damaki

@NicoPy you might find the following article useful to work within the restrictions of the Ravenscar profile:

Guide for the use of the Ada Ravenscar Profile in high integrity systems - http://www.sigada.org/ada_letters/jun2004/ravenscar_article.pdf

Section 5.11 is titled "Programming timeouts" and shows a technique of using a second task to perform the timeout.

Thanks for the link. I'll read it carefully.

Another technique I've used before (and you may find useful in your case) is to change my task from being event-driven (blocking on a protected object) to being a cyclic task (e.g. runs every 10 ms using delay until in a loop). Each time the cyclic task runs it polls the current operation to check if it has finished, or else checks for a timeout by checking the elapsed time since the operation was started, and whether it has exceeded the timeout period (using Ada.Real_Time.Clock).

This technique is usable for slow events. It is not suitable for high throughput events like in hardware drivers.

[Fabien-Chouteau]

What do you mean ? Is there another Ada implementation for µcontrollers ?

There are the ZFP run-times which are even more restricted because they don't implement tasking, but they can be used with another RTOS.

[NicoPy]

@damaki I studied the Programming Timeouts section of the article you provided. It is stated that the solution provided is equivalent to :

select
   PO.Call;
   Timeout := False;
or
   delay until Some_Time;
   Timeout := True;
end select;

This is not true.
The solution provided works only with one shot cases. This is because the timeout task (Timer in the article) cannot be reset once trigged. So, you have to wait at least the timeout duration before triggering another operation else you'll get false timeouts.