The roadmap states that Gnat Pro 25 will have experimental freertos support.
https://docs.adacore.com/live/wave/roadmap/html/roadmap/roadmap_25_GNAT%20Pro.html
Is it still too early to say how it might compare to @simonjwright project.
2 Likes
It’s likely to use a much more recent code baseline! Some of the code in mine dates as far back as GCC 4.9.1 … some of the libraries have SPARK support, which my copies don’t.
1 Like
FreeRTOS support has already been merged into bb-runtimes… Building with FSF GNAT might take some doing though. I think the hie files listed there are not open source.
1 Like
Thank you. I was expecting a pro support contract would be required. I was just wondering about some more details out of interest without speaking to AdaCore directly. I guess they will be released with Gnat Pro 25 whenever that is released. My main interest is Ada feature vs chip porting effort. I am porting Ada to a fourth chip now and for various projects so that flexibility is a high priority for me. Simons package brings the interrupts package to the table and doesn’t look like too much porting work but I haven’t got to experimenting with it yet beyond finding out that low power support shouldn’t be much of a problem.
I hear you, and I really would like to ease that effort.
I mean, that’s why I always envisioned Byron with a Forth-backend: combine that with a verified forth-interpreter in Ada and then your bootstrapping consists only in that of implementing the Forth words — then I learned of SeedForth and how it’s (a) tokenized, and (b) a very small set of words [about 30], and that reduced the conceptually work even further.
Granted it’s all up-front work, and nobody else is helping on the project, but if I use the idea from BATTS (the truffle bootstrap) of having an IR-/AST-interpreter, that should make porting much easier: just throw the IR into the IR-interpreter. — if that’s too slow, generate the SeedForth and its interpreter and use that, if that is still too slow implement a native-backend.
Honestly, the difficulty in porting to new architectures should be in (a) interfacing the HW, and if you’re doing an OS, (b) presenting a coherent hardware-abstraction and API to clients.
Sure.
That’s why I want to have a SeedForth-backend and -interpreter: maximize the flexibility, providing a way to translate/run Ada on some new architecture easily.
1 Like
Thank you for the concern @OneWingedShark but don’t trouble yourself too much on my behalf. Whilst part of it is not knowing fully what I am missing (I could investigate on Linux and know Interrupt handling is nicer and simpler with the Ada way). I am perfectly happy with Ada on a light runtime which is part of my thought process of hasn’t Ada gone too far with consequences that seem atleast to me to outweigh the benefits. Especially as light runtime code is also Spark compatible.
1 Like
What I can’t grasp is why one would want FreeRTOS support for a light runtime, i.e. one without tasking, when tasking is the whole point of FreeRTOS.
Looking at the changes in the commit, most of them involve including freertos in the set of supported OSs and choosing appropriate source files, which at a first glance are the same as for other OSs.
Perhaps for easy access to extensions like the FreeRtos-Plus-TCP 🤷🏼♂
bb-runtimes builds Ravenscar and Jorvik compatible runtimes too, in addition to light. Those support memory allocation and tasking (with restrictions).
1 Like
The commit you linked to specifically states ‘light’.
I find it hard to understand AdaCore’s Python-based build scripts, so I could well be wrong … I’d expect to see some mention of e.g. FreeRTOSConfig.h.
Ah, I missed that.
I assume that the FreeRTOS port here is being done for a specific AdaCore customer, so maybe they have some odd set of requirements.
I also find AdaCore’s Python build scripts hard to follow. They seem to make things more complicated than they need to be.
Maybe it’s to support a light app running in a larger environment, like when @Fabien.C wrote a light app to run in an ESP32-C3 under Espressif’s build environment.