Tonbandgerät: An open-source tracer for FreeRTOS

Libraries
1

Hi All!

I have a first half-way useable version of my tracer up on github and thought I would post here since I have mentioned it a few times now.

I gave it the slightly annoying name of ‘Tonbandgerät’, which is german for tape recorder :slight_smile:

They two main components are the embedded tracer that hooks into FreeRTOS, and a CLI tool written in rust that takes the binary traces and converts them into the native protobuffer format used by google’s/android’s online trace viewer “perfetto”.

Because this is intended for a course I help run at my university, I also built a small website that incorporates the converter compiled down to WASM and a simple web frontend to allow students to convert traces simply by copy-pasting (if they are in hex/base 64), or uploading them. The conversion then all happens client side and the website can automatically redirect to perfetto, displaying the trace with a single click of a button :slight_smile:

You can find this website here:

https://schilk.co/Tonbandgeraet/

(Be gentle - I am not a web developer:) )

If you want to try it out, here is a dummy hex trace that you can copy-paste into the trace field before hitting “1-CLICK OPEN”:

Hopefully everything works, perfetto should opens, and you should see something like this:

2024-07-03-184641_hyprshot
2024-07-03-184641_hyprshot944×843 127 KB

I especially like how you can see priority-inheritance in action when task 2 first runs and gets its priority boosted. These are exactly the kind of details I hope my students will better grasp with this kind of visualization.

Unfortunately the perfetto UI is not amazing for organizing this kind of information, so the easiest way of looking at traces is by manually “pinning” the tracks you are interested in at the top.

I have also started documenting everything, which you can find here:

https://schilk.co/Tonbandgeraet/docs/index.html

This includes some basic usage information, but also some details on the inner workings like the trace format (Uses on a simple scheme based on COBS framing & varlen encoding, powered by a python code generator). It is by no means completed.

Current State of Tonbandgerät

I would consider it a minimum viable prototype. The basics work. There are some cool features
like a metadata buffer that tracks metadata events (stuff like task names) should they occur before tracing is started. It also has different backends, including a “streaming” and “snapshot” mode. A “post-mortem” mode is still WIP. To be fair I have not yet actually tried doing a “streaming” acquistion via something like RTT. At the moment I have just been filling a RAM buffer and then slowly dumping it via UART once it is full :slight_smile:

I have also built most (all?) things with multi-core tracing in mind. In theory that should be working but I have not yet tested it yet.

Many things are not yet implemented (streambuffer/to-task notifs/event groups tracing), but all that should be fairly quick now that the “foundation” is finished.

It is based on FreeRTOS v10.3.1 for the stupid reason that that is what ships with STM32Cube and I did not want to only support the super latest version of FreeRTOS. Once my PRs are merged I plan to add support for that version with the required ifdef toggles. But for now I don’t want to keep updating my trace every time I change my mind about a tracing hook PR…

Next steps (including PRs)

I got it far enough that we can feasibly use it in “controlled” course exercises :slight_smile:

Unfortunately I now have to stop working on this for a bit and deal with this pesky thing called studying for exams. I don’t exactly know when I will have the next big chunk of time to do significant work on this and the PRs but I am sure I will procrastinate find time to do little chunks of work here and there.

There is a section in the introduction of the documentation that I will (hopefully) keep update about the status of things.

Similarly, I will not have time at the moment to keep thinking about the big refactoring PR. Please feel free to have a good look and provide feedback there or on the forum, I will be sure to have a look when I have time again.

Please feel free to jump in and let me know if you think there is something that obviously makes no sense: I am always glad for feedback.

Thanks again for all your support and patience!

4 Likes
2

Looks cool, thanks for sharing!

1 Like
3

Hi,

The GPL v3 license will most likely make it impossible to be used for commercial products since you will need to give out all your sources, build instructions and provide a way for a 3rd party to replace the GPL 3 licensed component.

Regards,

Robert

1 Like
4

Hi Robert!

Thanks for your feedback. I am aware the GPL3 license is very restrictive. To be quite honest, I hadn’t put much thought to how I wanted to publish this project. Going “very restrictive” first always gives me the option of “opening up” to something much more permissive (MIT/Apache/…) in the future.

I absolutely see your point. I think it makes sense for me to, at the very least, publish all the target sources that will be included with a firmware project under something that is as permissive as possible to ensure there are no concerns to be had about leaving the tracing sources in a commercial firmware project. I will make that adjustment when I have a moment.

I am a little more unsure on how to handle what I will call the “analysis” stuff, like the decoder and converter. I am not an FOSS/GNU purist and could imagine going to another license there as well in the future, but I am still thinking about how I would feel if all this was rolled into some larger commercial tracer. It is not that I have a problem with people using my work for profit, but I would like to encourage open collaboration since there really is not good open source tracing solution.

Do you have any thoughts? Do you think that having the target sources MIT/Apache but the desktop trace analysis stuff GPL3 would be sufficient? Or would most commercial users still be “scared” of the mention of GPL3?

Liebe Grüße,
Philipp

5

I am not a lawyer, but I think that commercial users would be scared off by code on the target, licensed with GPLv3. It is not a big concern on the host unless someone creates an SDK including your tools, but even then I would think it’s OK.
You might use LGPLv3+ and add a linking exception to it.
[1] GNU Lesser General Public License v3.0 or later | Software Package Data Exchange (SPDX)
[2] LGPL-3.0 Linking Exception | Software Package Data Exchange (SPDX)
or maybe an MPLv2[3]
[3] Mozilla Public License 2.0 | Software Package Data Exchange (SPDX)

With MIT or Apache2, someone else could grab your code and use it commercially. At least this is my understanding of those licenses.

… but of course, now it’s going to be philosophical.

When you go for Open Source you explicitly allow people to use your code. You might want to add some restrictions (like feeding modifications back to you,…) - it depends on how restrictive you want to be.

At least for the target part, you should be less restrictive.

BTW if you feel like we could have a little web conf, since I would be interested to add your tracer to my FreeRTOS training (for a Cortex-M3) - see my details below. I checked your sources and it does not look very tricky, but you know better.

Maybe the week from 15th of July.

Regards,

Robert

–
Robert Berger
Embedded Software Evangelist

Reliable Embedded Systems
Consulting Training Engineering
Tel.: +43 (0) 3858 40 404
Mob.: +43 (0) 699 17 69 07 19
email: robert.berger@reliableembeddedsystems.com
URL: https://www.reliableembeddedsystems.com

Schedule a web meeting:

--
2 Likes
6

Hi Robert!

I apologize for the delayed response - I have been traveling for the past few days.

Thank you for taking the time to give such detailed feedback. I have, as a first step, updated the licensing of all the target sources to MIT. I will have to have a think about what to do with the rest of the code.

Re Meeting: Sure! I have setup a call via your tool.

All the best,
Philipp

1 Like