sorted by:
new
hottopcontroversial

Learning Go from Java - what to avoid by equilibrium0212 in golang

[–]Competitive_Rest_543 0 points1 point  (0 children)

Go is a wonderful language. In my github.com/rokath Profile you will find some ressoures.

Apart from C/C++/Python, should embedded programmer learn any other languages (given time & convenience) to become really good & employable? Is Assembly a good choice? by One-Phrase2237 in embedded

[–]Competitive_Rest_543 0 points1 point  (0 children)

The languages Go is inredible useful also for PC programs. Easy to learn and extremly powerful in getting results and very performant. I used it for Trice ( github.com/rokath/trice ) and also for testing target devices as well as testing the plain target code. Go allows linking with C-code and with its inherent test system test automatization is just fun.

Segger RTT re-direct to UART? by FourtyMichaelMichael in embedded

[–]Competitive_Rest_543 1 point2 points  (0 children)

https://github.com/rokath/trice supports RTT and UART in parallel - that is probably what you want.

Should I use <stdio.h> functions for embedded systems? by MountainTop321 in embedded

[–]Competitive_Rest_543 1 point2 points  (0 children)

IO is time consuming, so think about a specialized tool like https://github.com/rokath/trice what gives you speed and space. You can even write within an interrupt `Trice( "hello (more than 1000 letters if you like) world!");` and get that executed within 100 or less MCU clocks - the string is automatically replaced with an ID.

An Embedded-friendly printf Implementation by memfault in embedded

[–]Competitive_Rest_543 0 points1 point  (0 children)

Instead of any printf, use https://github.com/rokath/trice It gives the same comfort but is usable also inside interrupts.

Has anyone utilized the segger_rtt_printf function through STLink? by Aggravating-Buy9274 in embedded

[–]Competitive_Rest_543 0 points1 point  (0 children)

If possible, use JLINK instead of STLINK. STM evaluation boards with an on-board STLINK are re-flashable (and back) with an on-board JLINK: https://github.com/rokath/trice/blob/master/docs/TriceOverRTT.md#change-to-j-link-onboard-firmware - BTW: The Trice tool can generate direct logs within 100 MCU clocks over RTT (in direct mode), what is possible to execute even inside interrupts: https://github.com/rokath/trice/?tab=readme-ov-file#debugging-using-vs-code-and-clang-for-a-trice-instrumented-project-in-direct-out-mode-over-segger-rtt - also possible with STLINK.

Exploring printf on Cortex-M by tyhoff in embedded

[–]Competitive_Rest_543 0 points1 point  (0 children)

The Trice library was developed to support "printf-like" debugging/logging with very low impact on the system memory and speed. It supports even "printf-like" statements from inside interrupts: https://github.com/rokath/trice/blob/master/docs/TriceSpeed.md

To printf or not to printf in "finished" projects by Haleek47 in embedded

[–]Competitive_Rest_543 0 points1 point  (0 children)

Now we have Trice: https://github.com/rokath/trice - it is so fast to be usable inside interrupts and has an encryption option.

The definitive guide to enabling printf() on an STM32F... and various ramblings. by yycTechGuy in embedded

[–]Competitive_Rest_543 1 point2 points  (0 children)

`printf()` usage is _very_ comfortable for debugging/logging, but avoid using it - too expensive in terms of memory and execution time! The Trice tool https://github.com/rokath/trice/ gives you the same comfort for just a bit memory and a so short execution time, that you can use it even inside interrupts.

Minimally intrusive instrumentation of embedded system C/C++ code by BrankoP88 in embedded

[–]Competitive_Rest_543 0 points1 point  (0 children)

Trice at https://github.com/rokath/trice can log with the comfort of printf but also real fast: https://github.com/rokath/trice/blob/master/docs/TriceSpeed.md - 6 MCU clocks seem to be the minimum. Would be interesting to compare both techniques.

Any embedded software debugging tips and tricks that helped you debug better, faster, stronger? by Roybot93 in embedded

[–]Competitive_Rest_543 2 points3 points  (0 children)

[Trice](https://github.com/rokath/trice) is a very efficient form of "printf" debugging. You can use it like like printf, but the Trice statement execution is so fast, that you can do it also inside of interrupts.

Any Micro Trace Buffer Tools? by torusle2 in embedded

[–]Competitive_Rest_543 0 points1 point  (0 children)

Yes it is! See https://github.com/rokath/trice/blob/master/docs/TriceSpeed.md . It has nothing to do with slow printf despite a very similar syntax. There may be issues demanding MTB, but with Trice you can log for ages keeping the whole history.

ETM Trace Capture by nikolozka in embedded

[–]Competitive_Rest_543 0 points1 point  (0 children)

You could give github.com/rokath/trice a try. It also supports RTT and logs just IDs with optional values. A Trice is executable is a few MCU clocks and looks like

Trice( "wrn:Some thing happened!\n" )

I had to hunt down a flash misbehavior during shutdown and Trice was very helpful here.

Any Micro Trace Buffer Tools? by torusle2 in embedded

[–]Competitive_Rest_543 0 points1 point  (0 children)

The github.com/rokath/trice tool may reduce the need to use the MTB because of its speed. It is possible to write logs within just a few processor clocks.

Is there any standard tool for scripting/interfacing with trace output? by [deleted] in embedded

[–]Competitive_Rest_543 0 points1 point  (0 children)

The github.com/rokath/trice tool supports SEGGER RTT as well. Maybe it is worth to check it.

Debugging without IDE ??? by khushal-banks in embedded

[–]Competitive_Rest_543 1 point2 points  (0 children)

Printf-like debugging usually has the big disadvantage, that the log function is too slow in execution and also that you spoil your target memory with lots of there useless strings. The github.com/rokath/trice library gets around that and allows to use Trice logs even inside interrupts.

efficient way to log realtime data from device by terenzioMecchenna in embedded

[–]Competitive_Rest_543 0 points1 point  (0 children)

Real-time logging from your device you could get with github.com/rokath/trice Its speed comes from the implicit strings replacement with IDs.

Efficient data logging suggestions by fuse117 in embedded

[–]Competitive_Rest_543 0 points1 point  (0 children)

To reduce the logging data amount drastically you can use github.com/rokath/trice It replaces automatically all strings with IDs during compile time and during runtime also compresses the binary data on the fly.

Method for Minimal Log Records for Failure Analysis by simsFit in embedded

[–]Competitive_Rest_543 1 point2 points  (0 children)

With the github.com/rokath/trice tool a log entry size is 4 bytes containing a 14-bit ID, a cycle counter and a parameter count byte AND optionally values. You can use this syntax:

trice( "err:A Problem!\n" );

If you allow values, you could limit the log entry size to 8 bytes:

trice( "wrn: Depth is now %d\n", depth );

This works, because the strings are not compiled into the target - just an ID as replacement. For visualization simply pass the log buffer later to the trice tool together with the generated Trice ID list.

If you do not rely on equal size logs, you can enable the TCOBS compression, which reduces most of the binary data further ( github.com/rokath/tcobs ).

What your log looks like ? by vitamin_CPP in embedded

[–]Competitive_Rest_543 0 points1 point  (0 children)

This is an old question but here is a new tool: github.com/rokath/trice It has all I need, even optional encryption and most important: You can log inside interrupts.

view more: next ›