About this talk
In this talk, Frederick, who manages embedded and IoT programs at the Eclipse Foundation, presents a detailed comparison among three embedded operating systems: Treadex, FreeRTOS, and Zephyr. He highlights Treadex's strengths, including its modular design and low resource footprint—down to 2 kilobytes. The speaker also emphasizes the unique features of Treadex, such as its pico kernel architecture, which separates managed and unmanaged interrupts, optimizing both latency and determinism. While FreeRTOS excels in simplicity, Frederick argues it lacks enterprise readiness due to its minimal core and fragmented ecosystem. In contrast, Zephyr offers a comprehensive feature set, although with increased complexity. Throughout the session, Frederick promotes Treadex as the balanced choice between simplicity and functionality, appealing to developers requiring both efficiency and maintainability in their embedded applications.
Full transcript
Um, welcome. So, I'm Frederick. Um, I manage embedded in IoT programs at the Eclipse Foundation. Uh, I've been around, so please feel free to look me up on LinkedIn if if you want the long version of the story. The short version is simply that, uh, I've done lot of things, but I've been at the Eclipse Foundation for seven years now. and um I'm blessed with you know
many interesting technologies in my portfolio. One thing that this slide doesn't mention is also the fact that I'm the project lead for Eclipse Treadex. And now you may wonder you know this talk will you know try to make parallels or compare friartas zapier and treadex how objective can I can I be really right will will you get an an actual uh let's say neutral assessment of all
of those technologies and the answer obvious is no so let me start with this slide that explains you in great detail why threadex is the best and the rest is rubbish well of Of course, you know, in the case of Tradeex, it just works. It's still true after adding interrupts to your application. That's not the case with Ferraras or Zapier. Believe me. Then if we take the
logo into account, of course, Tradeex is the only one with a stylish black and yellow logo. So on that front, you know, the others are well behind. Um, Traxx gives you the opportunity that you know you you you spend no time chasing impossible race conditions. You you just chase the possible ones really in the codebase. And of course, when you enable preeemption, you don't need to look
it up in the documentation. In the case of Treadex as well, in the case of the other two, you will need to take tons of documentation. But that's not all. Treadex can even finish execution you know before you are even done flashing the board right and that means of course it is widely superior and we've got so much advanced technology in the kernel that in the case
of Treadex it will behave exactly as you intended it will read your mind even before writing a single line of code and finally of course you know not only the scheduleuler behaves as you intended but the kernel fully understands your design intent. Okay, so this is not this type of presentation. So this is not marketing or anything like that. I'm just trying to be silly there a
bit. So of course I will try to provide you objective information about our three contenders. My task here is to really illustrate how Treadax sets itself apart in a number of ways, right? And uh I wanted to be clear about that. So that's my way to uh try to make a joke about it. Well, uh let's have an overview of our contenders because maybe you are not
familiar with their architecture and how they fit, let's say, uh in terms of features and design. So let's start with Freriartas. Um, Ferraras has been around for quite a while and and and really what if there's one key word you should remember about it is that it's it's about simplicity. Everything is intentionally very very simple. The core of free arts is just refiles. Okay. And this comes
of course with pros and cons. Um, now there's a broader ecosystem about it. So if you look at the diagram you will see yes there's the kernel but there are you know companion libraries that you can use and of course you will find uh Wi-Fi stacks Bluetooth stacks TCP TLS etc etc of course um the one thing about prias is that well this is a kind of
way to get you into a specific cloud solution so there are specific features of course that you will find in the repositories where like device defender or OTA updates they are there they are useful but they are hardwired to one specific cloud which is Amazon's cloud so really the strategy there is of course yes we have a great arts but please consume cloud credits uh which is
uh the the way that they monetize all of this so in terms of designing everything as I said is quite simple of course one of the trade-offs uh if you look at the source code um you will you will rapidly notice that yes the focus is on simplicity but not so much on enterprise readiness. For example, there are five memory allocators that you can pick from but
they would tell you in the documentation none of this is production ready. We provide that just as samples. Please uh do your own if you want to go to production. So you may think oh I will start small with Fartas and all of that and then I will write my own memory allocator. Don't do that please. I mean if you have hardcore coding skills and you're good
enough for that uh maybe you should pick a better base layer and then of course uh focus your genius you know on the upper layers and uh you know deliver a better solution. Anyway, now um if we take you know a look a high level look at the allies in terms of the feature set and codebase as I mentioned it's you know a very minimal kernel you've
got scheduuler you've got trs uh you've got basic primitives um but most of the functionality for networking file system security all of those things is external or vendor specific uh the codebase is very very small and highly portable which is why it it's it found great success in the market as an open source solution for a very long time. Now in terms of code size, it's really
ultra low footprint unless you layer off of course tons of additional libraries on the top. So you need to be careful about that. It's predictable and efficient relatively speaking. uh but in terms of uh having SDKs and companion tools that's the major weakness in the sense that there's a very fragmented ecosystem of course because fritos itself is just the little kernel and then well everything else you
mix and match on your own. So from that perspective um there's more work for you as a developer to be done. Of course, there are AWS extensions as I discussed and many vendor SDKs, but yeah, you're the one putting the glue into this and you're the one that uh will need to fix issues if there are incompatibilities. Of course, terms of governance, that's another area of witness.
This is a single vendor project. Okay. So, in terms of release cadence, for example, there's no fixed release cadence really. It's whenever Richard will decide a new release is out. Well, maybe that works for him. In my case, I prefer more reliable cadences. That said, they have LTS releases every 18 months or two years. Uh, I'm not sure um the exact duration, but at least there is
some pred predictability over there. Um, terms of community, well, there's a large community since it's been around for a while. Of course, it's widely adopted and so there are good chances you will find books and other things like that. But well if we try to synthesize all of this uh you know the bottom line it's it's a nice simple kernel but really every everything else is DIY.
Okay. And so you need to take that into account you know before uh starting on a complex project. Now uh let's move on to Zapier. So the diagram is already bigger as you can see. Zapier uh from a feature set and uh a scope as an open source project is much much larger than what you have in Frartas. Of course, there's the core kernel, you have kernel
services and a variety of scheduulers built in. You have low-level APIs and you have implementations, you know, connectivity for a variety of standards built in. And in fact, um if you contrast it with fritos, fritos is just base kernel and a few libraries. In the case of Zapier, they are really pulling everything in in the sense that your board support packages, hardware abstraction layers, everything is baked
in and as part of the project which once again comes with pro and cons, right? So it's much harder to take something from the outside and put it in because well the expectation is that you work with whatever the project will provide you. Um so in terms of feature set it's quite comprehensive and and certainly in terms of adoption as well you see great momentum in the
project. Uh I think in their last release they had over 900 contributors which is a blessing. I'm a bit jealous of that right and at the same time it's a bit of a curse because if you push a PR you can imagine the kind of traffic there is everywhere. So before someone will look at your little bug report or your little PR, it could take some time
because of the massive scale of this project. Right? So once again if we use the same criteria as I use on Friartas feature set and codebase of course um this is a comprehensive platform the kernel the drivers the networking the subsystems and etc etc and they keep adding really higherend features that uh for example would provide stack protection and things like that. So from from that perspective
it's quite exciting. It's highly configurable but of course then that's the downside. It's also complex you know free art was three files uh maybe uh in the case of if we could say it's 300 repos or whatever. Anyway so um that's not true but you know the scale as I said of the codebase is massively different in this particular case. So that's a large codebase for sure
in terms of code size. Now when you work with it, you build an application. Of course, um this comes with a higher footprint. It depends on which configuration you will pick. But the focus is not on simplicity here. The focus is on functional breath, you know, and having anything and everything but the kitchen sink. So, uh, if you try to squeeze as many things as possible or
if you try to to put everything in the smallest footprint possible, this is probably not the best platform because uh, of course, uh, there are so many things in there. So, it's tricky to remove to get to a minimal footprint in some cases. So, yes, it can it can scale down, but it will hardly be minimal for sure. In terms of SDKs, there's a rich ecosystem there.
Um the one thing I would say however there's west as you know this automat automotion tool on the project there are build systems and subsystems and all of that and it's highly structured that's great however if you're used to embedded RTOS's prior or even like notex you come to uh zapier and there are let's say differences from what a typical embedded developer would be used to and
in particular they have adopted technologies is coming out of Linux uh like something like called device tree and those Linuxisms well if you are a Linux embedded developer that's great because then you can jump into Zapier and feel comfortable but if you're not familiar with embedded Linux then you well the learning curve let's say is a bit steep and uh I'm not saying that device tree is
a bad technology or anything but yeah there's a paradigm shift in there for developers and so the learning curve because of that is steeper. Terms of governance, it's all good. It's an open source project under Linux Foundation uh governance. Well, would be better if it was at Eclipse, but who knows? Um I mean anyway, from this perspective, this is a vendor neutral multi- uh a true community
project. So that's great. And of course the size of the community, it's already large. It's growing, lots of momentum, broad industry backing. So from that perspective, well done guys. Uh certainly um from this perspective, Zephier is quite healthy. So if we try to synthesize once again with my little AI generated image, we could say that uh the power bottom line is that Zephier is really powerful but
rather heavy and more complex to manage compared to what your solution. So you see this this looks very enterpriseish although uh well if you use if you download my slides after the show and you and you and you zoom on the image uh maybe it doesn't make sense okay so I wouldn't pretend uh this is an actual physical now coming on to treadex is a happy middle
ground between uh the simplicity that we had with friarttos and the complexity that we had in zir so of course when you work with treadex we don't have all the boards and the BSPs and the house baked in like Zapier. So you need to pick up whatever your vendor will give you in terms of driver board support packages etc etc. So but from that perspective there's plenty
to choose from and generally speaking if it works with Riatus it would work with uh Treadex uh as well. The Treadex kernel is really optimized for size and speed. So there are baked in primitives that are listed there. threads, timer, cues, semaphors, event flags, preemption thresh preemption threshold baked in. So well featured, but let's say that you can make it really small. In fact, if you disable
some of those features, you know, and just keep whatever you want to use uh very very strictly, it can be as small as 2 kilobytes. So, you know, not too shabby in terms of resource usage. Now um what makes Treadax interesting uh there is that it's developed in you know jointly with a number of uh middleware components. So you've got a full-blown TCP IP stack IPv4 IPv6
with some protocols baked in. You've got a USB stack, a file system and um a guey widget library that you can use to build user interfaces. And uh we've got a little tool that can be used to generate the code and you integrate that uh into your application. So from that perspective it's not as fully featured as what Zapier would offer but certainly you know you have
more functional bread and of course those components are developed with the kernel but they can be used separately as well. So you could use the the USB stack on three arts um etc. Some people are actively working in fact on decoupling them even more from one another because right now when you use the HTTP server in uh our network stack for example then uh it would uh
pull in the file system because you need a place to write the logs or to write something to to to to storage but people are working to decouple or to remove those couplings in the codebase. So you would be able to substitute whatever solution you want in terms of writing to disk um and and and and not have those uh those dependencies but uh you certainly can
mix and match uh there. So using the same uh the same pattern as I did for the other two what are the highlights there for Treadex? Well uh the feature set is rich but it's really focused. So we don't have anything and everything but whatever makes sense in terms of our focus for low latency, very small size and high speed. Okay. So that's a different design philosophy
for sure. Um the optional components are integrated but they are optional. So if you want to use just the kernel and provide everything else on your own or code everything else on your own, you can. Okay, no problem there. And you can use some of those components separately from the kernel as well. So it's really uh up to you. So it's really modular but at the same
time compact. Now in terms of code size uh the footprint is low to moderate. As I said 2 kilobytes for the kernel only minimal configuration that's not too bad. If you use some of the other two optional components then the size uh of course will grow but typically even if you use everything and uh I suppose there that your own application code won't be megabytes and megabytes
of code but you you would be able to comfortably fit everything including your application application code in 128 to 256 kilobytes. Okay. So depending once again on uh if you use TLS for example it's bigger because then you pull in all of the crypto and that kind of stuff but um let's say that from this perspective it's uh highly modular and you can optimize for size certainly
if you have very limited uh resources. We also have what we call our pico kernel design. I will explain a bit later what that means but essentially let's say that it's not a micro kernel but as it's a pico kernel so anyway it's a fancy marketing word but we'll we'll dig into that uh very soon in terms of SDK and companion tools it's really a coherent and
production ready stack but all you need to work with is really cmake ninja and a compiler for your target so there's no mandatory SDK you in the case of zapier you need to work If if you want it to be easy, you need to work with their SDK and use West and use all of those things. It's theoretically possible to do without them, but then you're on
your own and it can be complex. It's already complex using their SDK. So, um, from that department, if if you are a traditional C developer, um, is just CMake Ninja and, uh, your compiler. So, it's much simpler from that perspective. uh the middleware as I said is tightly integrated but can uh we work on making that a bit more modular and so from that perspective there's certainly
less integration over it than what you would experience with fatas terms of governance that's the best Eclipse foundation project neutral vendor independent uh and and and no one of course can can run uh with it in terms of community that's where we need uh still to work on it and that's why in fact myself and staffer is the project lead right now in the sense that there
are certainly lots of partners, lots of people using this, but the Treadex community wasn't used to live as an open source project before. You know, the code was accessible when it was at Microsoft under the name Azure Artus, but it was you can look, but you cannot touch and you need a license and this so there was no community really around it. So when we uh when
this codebase was contributed to Eclipse, we had to rebuild the community from scratch and after realizing after a few months, oh, no one will step up as a project lead then well I suppose I'm better than nothing anyway. Um but we've made great strides and progress in the last uh 18 months on that front and really the community is small but it's growing and it's really focused
on professional and enterprise types of applications. So if you want to be serious with this well other serious people are already using this and so the bottom line is that there are integrated capabilities but without unnecessary complexity. So in if I am to oversimplify, Friartas is simple but can be simplistic. Zapier is powerful but can be overpowering and it's like uh you I just have the French
words coming to mind but you know the story with the little girls and the tree bears. So you know we're just right you know in the middle. Okay. So let's be a bit more technical now. You know those previous slides were comparing let's say um intangible things let's say or things that are not necessarily me measurable through code. So now let's focus on code aspects. So if
we take the angle of deterministic real-time performance and um the scheduling aspects of the kernel. So in the case of Treadax, it really stands out because of the pico kernel architecture. And what this means is essentially two things. The pyro kernel, well of course it's small, okay, but that's not that's not the point. Um pico kernel means essentially two things. The first one is that you have
two types of interrupts with you. You have manage interrupts that will be fully taken into account by the arts kernel. Okay, so there is a bit of overhead there, but you also have the possibility to use unmanaged interrupts, which means you write all of the code and the arts won't even touch this. So if you want zero overhead interrupt processing for something very very very very critical
in your application, you have the option of using that. Now, of course, please make sure that code is safe and high quality because you're bypassing everything else, but you have the option. Okay, so that's the first consideration. The second thing, the semaphors, the mutxes, all of the fundamental building blocks in the kernel, they are built in. They are not in a separate library. So when you are
using them, there's no outbound IPC call to use them. Okay, so in other words, there's no interprocess communication in the Treadex kernel, which means that because of that, the context switches and the latency are much lower. everything is much faster. Okay. And this is a a deliberate design decisions by the people who wrote this. And that's that's what back kernel means, right? So everything in terms of
latency is uh much uh at a at a lower level. Then the kernel supports what we call preeemption threshold. So essentially uh every Treadex thread has a priority and normally higher priority threads will bump you know the lower priority ones as needed. However you can you know when you configure your application you can configure a threshold where even if there's a higher priority thread right now maybe
the currently executing thread will stay on for a while. Okay. And this is this threshold that you can define in order to make you know sometimes you would prefer that even a lower priority task is not necessarily interrupted. So you have this opportunity to really finely configure those things and get exactly the type of behavior that you want to optimize of course the user experience. Then uh
really the design of the kernel means that the latency is really bonded and predictable. Okay. So people will say yes now they they they merged the preempt RT patches in the Linux kernel. So now you know it's a true real time operating system. It's real timeish right but in some cases we have people using Treadex even though it's very small on Cortex a class cores with multiple
cores and lots of memory. Why? because sometimes what you need is not a fully featured uh operating system but an operating system that will strong guarantees about the latency of your interrupts and things like that and that's why in many critical applications you won't use Linux or some other bigger uh operating system but you will use something like Trex even though you have tons of memory and
tons of processing power and this gives more resources of to your own application running on the top. You're not wasting resources on a on a fat kernel or anything like that. Okay. So if we compare now to Freriartas and Zapier, well of course Fartas is deterministic but uses a much simpler scheduleuler. So you have priority optional time sling and that's it. And if you want something else,
well code it yourself anyway. The memory allocator is not production ready. We told you. Um then in the case of Zapier much more configurable much more options even even more than Treadex but of course the increased complexity will reduce the predetectability and so if you need very very tight ironclad latency guarantees this can be done with zapir I'm not saying it cannot be done but it's trickier
to up to achieve okay so in the endax delivers superior determinism and predictability so if you need strict real-time guarantees, that's probably your better choice. Now, in terms of performance, efficiency, and footprint, um, TREX stands out because, well, I keep telling you it's really small. So, yeah, only a few kilobytes for the core kernel. Um, it's really highly optimized. So, the the way the code is written
really is focused on speed and it has been since the very beginning in 1997. Okay, so this is a mature code base. So it's been highly optimized over time from this perspective. Um you can get fast context switches. In fact uh you can achieve sub millisecond uh context switches uh inside the trader kernel. Once again inside. So because of that okay you can have very very fast
context switches and of course minimal CPU overhead and the design means that you can really push it to the limit on very constrained environments. So this means for your project probably you can get a cheaper microcontroller and squeeze everything in and over the the long term uh your bosses will be happy because you're saving money to the company. So well Now in comparison with our two uh
two contenders of course freetos is also lightweight but generally it's optimized for simplicity rather than pure code performance. Of course the core kernel is very small. So in theory you could optimize it yourself and that kind of stuff. But once again uh you know why do that yourself when you can pick up something optimized by someone else and then focus on your application and optimize that on
the top. In the case of Zapier well the broader feature set leads to a larger footprint and of course eer baseline resource usage. It's only normal. It comes with tons of things but then of course the focus of the team is on growing the feature set not so much on optimizing everything that's a that's a choice right as a project you there are many many things that
you can do and too little time to to do them all and I completely respect that but once again uh Treax is certainly a happy middle ground between our two other contenders there okay so Trex ultimately offers a best-in-class in terms of opensource RTOSS in terms of the footprint and of course the runtime efficiency. Now uh let's focus on the scheduling control and the resource management. Uh
so Treadex stand out there because of this preeemption threshold mechanism that really allows selective blocking of higher priority threads. Okay. So this means you will have less context switches even if they are fast. A context switch is always costly in terms of the application performance. So you can structure things in a way where okay I will keep this lower priority thread running until the end and so
I would have one less context switch to manage. So overall application performance and reactivity would be better. Then there's really uh inside the kernel ways to really fine-tune the responsiveness versus the overhead which are harder to get when uh you only have thread priority as your main mechanism. So from this perspective yes there is thread priority in thread x but uh you have finer grain mechanisms in
order to handle things if you need them right you you can keep things simple it's it's not mandatory to use that and of course the tight integration of the synchronization primitives with the scheduleuler improves overall efficiency once again no IPC in order to use them so that's really a big advantage now compared to our two other um options. Well, in the case of Fartas, once again, everything
is simpler. Uh but of course, everything is much less flexible unless you start writing your own code. And once again, that's probably not a good idea. And in the case of Zephier, it supports much more advanced configurations, but once again, more complexity, more runtime overhead. Okay, so in the end, Treadax provides more precise and efficient control over task execution and of course this means you can optimize
much more easily by using Looking at the middleware now, uh middleware so of course Treadax has those components I already told you about that are loosely coupled with the kernel. So that's one great thing and those things are designed, tested and optimized together. So it's not like yes with free arts you can pick up the kernel and then there's a broad array of solutions in the market
that you can pick from but they are not optimized together. They are not designed together. They are not versioned together. So think about it CRA is coming. You will need to manage those vulnerabilities on your device that you're putting in the field and then you need to track the new versions of all of those separate components you downloaded right and left. In the case of Treadex, we
have a quarterly release cadence and they all have the same version numbers. Okay, so we just released 6502 202601 which is the Q1 2026 release. Okay. And even if I don't have code changes in every component, we release them and we version them every time. So when you have a security vulnerability, you know exactly where you stand, you know, according to whatever version you are consuming right
now. Okay. And that's really an important consideration in regard of the CRA and future additional regulation that will come your way because they are just getting started at the at the commission. believe me. Um, in comparison, uh, in the case of free arts, yes, there's a modular ecosystem, but it's up to you, okay, to to to track all of those things and manage them and build your
sbomb and yeah, by the way, I I did I forgot to put this on the slide, but did you know that Trex has no third party dependencies at all? Not even OpenSSL. All our crypto is homemade you know like your mom was doing when you okay maybe not but everything is self-contained okay and at the same time in the past uh that's not true right now that
certification had expired but uh older commercial Treadex releases in the 5x series had FIPS 140 uh certification for the crypto inside so it's been battle tested already we want to get back that kind of certification eventually for it Okay. Uh, right now we don't have it. So, I'm I'm fully open about it because this is very expensive and and complicated to get. Eventually we'll get there. But
all of this to say because um you know uh everything is baked in no third party dependencies. Your sbomb is just threadex and whatever optional components you pick. So once again much simpler to manage uh in terms of uh the sbomb. And finally in the case of Zapier it includes many many things right the functional breath is impressive I'm a bit jealous I should say but at
the same time the integration is more complex do its broad and evolving architecture it's like trying to follow the Linux kernel and all the new drivers and all the new algorithms that they put in there that can be complicated so zapir is really at that scale in terms of ecosystem and uh there are pros and cons to that let's say So, Treax really reduces your integration risk
by offering pre-validated tightly integrated middleware stack. Now, uh the efficiency of the interrupt handling and the low latency design. Uh so really threadex from the ground up has been designed to minimize interrupt response and minimize okay the handoff between your interrupt service routines and the threads. Okay. So that was a design goal from the very beginning from the kernel and this stays true up to today. Okay.
Um which means that uh essentially you minimize the time you spend in your ISR and really you get back to thread execution as soon as possible. Okay, which is what we want uh typically in those kind of applications. And so you have high responsiveness in interruptdriven workloads which are really typical in embedded environments of course. Now in in terms of comparison there is solid interrupt handling inferior
artas but it's not so much optimized for minimizing latency. So yes you will get some level of predictability in there but you know it will be slower generally speaking that's that's uh the truth of it. And in the case of Zapier, well, it comes with many abstraction layers which are great for developers. You don't deal so much into technical details, but then the downside is that those
added layers add extra latency and overhead to your application. So there's a trade-off there. Once again, I'm not saying that it's necessarily bad, but if you need to absolutely minimize latency, then that's not necessarily your best choice. Okay. So in the end, Treadax will excel in interruptive latency critical applications where you need rapid response times. Okay. So the big picture if we take now a step back
and consider not only Treadex itself but the broader Eclipse embedded ecosystem. Well, Trex in itself is impressive. You know, maybe you never heard about it, but it's been deployed in 12 billion devices already. Unfortunately, many of those users won't let me give their name on this stage. let's let's go have a drink and maybe if I'm drunk enough, I will spill out the beans and give you
a few names. No, it's been um broadly deployed and of course this continues uh you know uh that 12 billion was the number Microsoft was giving a few years ago and since then we continued of of course to grow the ecosystem. But really, Treadex is only one part in our autonomous, trustable, and scalable embedded stack. And of course, the the great thing about this is that if
you care very much about sovereignty, if you care very much about the predictability of your supply chain, we even have open-source risk 5 processor cores at the open hardware foundation. And of course, you could use those and and and put Fritos or Zafir on the top. They are supported. But you know, Trex brings this one two punch of better together in the sense that you get a
highly optimized kernel and you get open source cores which means for as long as you want to use those cores in your own custom chips you can which is not something that you can negotiate easily with Renesus or ST Micro or the commercial vendors. So from a sovereignty perspective, if you want to use the same chip and have the guarantee it will be available for the next
30 years, you can do it by combining um open hardware foundation uh cores with uh the auto embedded technology that we've got. And of course we've got Eclipse, Open VSX, all of those incredible developer technologies supporting embedded developers in application building blocks uh like what we have in Eclipse IoT and SDV. So it's really not just you know the artas but there's a full ecosystem there at
play that you can tap on and really not just an ecosystem and a bunch of repositories but people who have the same you know as an embedded community the same concerns as you. So people that you can exchange ideas with, people that you can grow with, you know, in terms of uh being an embedded developer or an IoT developer And all of this the companion part to
this is of course that we've got the trustable software framework. So we are literally starting this week. We had a meeting yesterday deploying TSF on the top of Treex because Treex has the distinction of being the only open-source art which is also safety certified. Okay. And that means IEC61508 ISO 26 262. So in other words, you can put it in cars, in trains, in medical devices and
it's been proven once again since 2015 in that uh in that department. So uh yeah, I mentioned open hardware foundation. So I mentioned the course, but really there's a broad ecosystem. If you care about risk 5 as an ecosystem and and want to design custom chips or benefit from you know common designs that you could build on then I certain certainly encourage you to have a look
uh at this and now uh you know there's a tight connection now between the treadex project and the broader uh risk 5 ecosystem in fact our recent release in March of Treadex 650 we upped the version number from 64 to 65 five because there was so many goodies around risk five that you know we did a little marketing there. Uh my marketing partner in the Eclipse team
was so proud of me. Anyway, um but really the standout uh contributors in that release you see 10x engineers for example which is an open hardware foundation member contributed a new 32-bit port using GCC and provided improvements to our 64-bit support. Alibaba contributed support for full chip over there. Um, Quintous uh which is an important player in the automotive ecosystem uh brought a port of um Trex
for the CVA6 core at open hardware. So once again those connections are going strong and we even have uh random lab maker equipment in Germany satellus instruments. you know they love Renus platforms Trex didn't have the platform support that they wanted so they wrote it and contributed that to the project and we see more and more of those kind of contributions so for example I just merged
uh this week improvements uh no I sorry I didn't merge them yet we need to review the code but any anyway I um started the review process this week uh from uh for improvements to our BSD sockets implementation in the network stack and those have been submitted by Rockwell Automation. So we see right and left people popping up and really providing support to the project with code
contributions which is uh really great. So we had 11 new contributors in the last release. I expect that number to double in our June release and etc. So you know not as big as I feel but certainly healthier in terms of open source contributions. That's what exactly we want uh for it. So my call to action there um predax is permissively licensed MIT licensed you can do
anything and everything with the code. So please have a look at the code and play with it. Of course uh we have a full set of documentation the sources in eskid do we are nearly done putting it uh in a refresh HTML format on the website. So this is coming um stay informed join the mailing list and of course we have something called the Treadex alliance. If
you want to support the project, you can give us a bit of money so that um you know um we would be able to organize and things like that and be more visible in the space. And finally, we need contributors, we need committers. If you want to drop in, this is the right time. Our community is still small. If you want to influence the strategic direction of
this project, well, now is certainly easier to do it than two years from now when we will we'll have thousands of people around the table or maybe not. That's not the goal. The goal is simply to have this incredible arts being healthy and being available forever for as long as people will want to use it. And if you want to get started and experiment a bit with
this, so this is not my book uh but uh this is a book from 2024. Someone wrote a starter guide and certainly uh ST Micro is one of the largest contributors uh to this project. So someone took the time of writing a getting started book for beginners there and uh if you have nucleio boards lying around at home then it's very easy to experiment with treadex uh
on that particular environment. Uh yeah so that's it for now. Uh thank you so much for attending and I suppose and hope we have some time for questions. So, so um yeah, yeah, let's wait for the microphone. So, yes. >> So, I recently read some news that uh Rust support is in progress for thread x. Can you do you do you have any idea on what the
status is or if you can update? >> Yes. So that's informal in the sense that we don't have necessarily in our camp and board a dedicated stack for that but people from if I remember it was Valtec at the time from our Eclipse SDV ecosystem experimented with that and demonstrated it's already doable to use ROSS modules with the Treadex kernel today. So there was a recorded presentation
from an SDV community day uh which is available on YouTube that you can watch and they explain in detail how they achieved this. Of course longer term I would like to have let's say um a very official way let's say to support uh this kind of pattern because you know people want it and at at the same time we are still a very small team so the
priorities for the time being are elsewhere but yes on my let's say two or three year road map this is an important item but I need rust knowledgeable people on the team and right now uh apart from me there's no one else who cares All right. Thank you. That's good to know because I'm from Infinian and we because Rust on embedded uh in productive code is still
quite new. >> Yes. And uh yeah we we get a lot of uh requests from OEMs for instance of for using rust uh on our microcontrollers and uh threadex pops up in some discussions but it's mostly zer or fritos but threadex is out there as well and for our future microcontrollers which are not which are supposed to be based on uh risk it's um uh one of
the u platforms that we are uh uh targeting to support as well. So this it's good to know that Rust is officially being considered. So thanks for the update. >> Yes. Yes. Absolutely. And so to restate my answer, the short version is really it's been proven this is doable and at some point we'll have an official way an officially supported way to achieve I think there was
another question. Yeah, the gentleman. >> Yeah, thank you. So you may have answered it already because we're a little late, but I ask anyway. So in your comparison where like thread X sits between the funny free utters and the aircraft carrier that Zepha is I was wondering that Apache NX also seems to fall directly between those complexity wise it is used in some I think safety critical
use cases in automotive so isn't that a more interesting comparison to threadex and we have a short summary >> uh yes uh and and and and there uh I I must say um my ideal presentation would have included it as well but I needed due to other things going on to to let's say focus the scope a bit more in the case of notex um the the
yes it's it's more comparable in terms of uh let's say the kind of guarantees that will that it will give developer and and code size and all of that to what predex would provide what it what it doesn't provide I think is the size of the ecosystem and of of course um not only that but the the the the broad adoption in the marketplace that you would
find in the sense it's been used and and yes it's got some very specific vertical success uh stories there. uh on the other end certainly if you're looking on the market for not knowledgeable people and you want to hire them tomorrow um let's say they will be harder to find right so um the other the other consideration to have and and there are pros and cons to
that traex has its own API uh which is designed in a specific way in the case of notex they are going with posics straight there which is great if you need to port code but then port code from some other bigger platform on embedded just because POSX is there is maybe a bad idea because you're not optimizing for very for size and speed like you would do
in embedded in other you know on a bigger type of environment and the other consideration there would be that is POSX really the kind of API you want to use on a daily basis because you know what I mean it's it's been designed for some mature applications and yes it's useful for code porting but that's not necessarily the most intuitive or the most productive type of API
you could you could design in the abstract. So is the Treadex API better? I don't know. But one thing is sure is that the Treadex API has been designed from the ground up for embedded applications and POSX comes from the Unix word. So um that's a different type of environment but that's just my personal taste let's say. >> Thank you. Oh, okay. So, I will take it
in the in the corridor then. Uh, thank you so much once again.
