Trice on embedded Linux SOC questions
Hello, thank you for your last reply. I have three questions to ask you. The first question: I want a test program that can run on my embedded device. First of all, the code in the path of trick \ examples \ f030 _ inst can be compiled, but because my compiler tool chain is not arm-none-eabi-. I need to modify the tool chain I can't compile it after I modify the tool chain. The error message is drivers/cmsis/include/core _ cm0.h: 90: 6 error: "Comptrollers generate fpu instructions for a device without an fpu (check _ _ fpu _ present)". How should I solve this error message? The second question: What should I do if I only want a basic test program to run under ubuntu, and this test program only needs to call trice macro and output debugging information to stdout? The third question: Does trice support replacing printk with trice?
Just to quick answer:
- Question: The F030 examples are for the STM32F030 MCUs. You need to adapt the Makefile for your processor.
- Question: Ubuntu means, your target is a PC, right? I did not expect so far, that Trice makes sense with a PC as target system. Could you please explain your use case a bit more in detail?
- Question: printk ist the log output for Linux kernel drivers, right? What do you expect replacing printk with Trice? Trice was developed to support resource constraint MCUs mainly. But maybe there are other use cases as well.
Thank you for your reply. At present, there are a lot of debugging information of programs running on my SOC, and a lot of printf information will be output during execution, which will affect the performance of programs. My demand is to use trice code in my project to improve the performance of the program. Debugging information is output through trice tool or other serial tools. However, the code in example's folder can't run on my SOC. Unable to compile because toolchain does not support it. So at present, I just add the code in the src folder to my project, and then modify the code in src. In the function TriceNonBlockingDeferredWrite8, comment out all the contents of the function. Then write the parameters enc and len into ttyS0 by calling the write interface. Whether this method is feasible.
Adding just the code from the trice/src folder to your project is the right thing to do. The examples are specific.
There should be no limitation to use any compiler to build the Trice library code.
There should be no need to edit the trice code. For what you want do, look for TriceNonBlockingDeferredWrite8Auxiliary. It is a function pointer you can assign code from your project. Enable TRICE_DEFERRED_AUXILIARY8 for that.
You should be able to replace printk 1:1 with trice in most cases. There may be some specific format specifers causing issues. See https://www.kernel.org/doc/html/latest/core-api/printk-formats.html and https://github.com/rokath/trice/blob/master/docs/TriceUserManual.md#more-comfort-than-printf-like-functions-but-small-differences and as well https://github.com/rokath/trice/blob/master/docs/TriceUserManual.md#346-runtime-generated-0-terminated-strings-transfer-with-trices. You should be aware if you have 64-bit values for printk on some places and there you should use trice64 instead of trice as a printk replacement. Using trice64 generally as printk replacement is possible too, but would double the needed space for the parameters. But if you enable TCOBS, the transmitted payload is not much bigger because of the compression.
Maybe you rename this issue into "Trice on embedded Linux SOC questions" or s.th. similar to make life easier for other developers.
Thank you for your reply. I will try.
Hello, thanks for your reply.
Question 1: The maximum value of trice id is 16383. If 16383 is not enough, how to enlarge the maximum value of trice id?
Question 2: Trice trice tool can only parse trice-related functions and trice-related macros. If there are both printf and trice in the code, will there be any problems? Trice tool can't output the result of printf printing?
Question 3: int i =1111; trice8(ID(2),"trice =%d",i); Is it because trice8 stands for one byte, and the value of I cannot exceed 256? Is this the right understanding? If you want to print the value of I, you need to use trice16. Or change the TRICE_DEFAULT_PARAMETER_BIT_WIDTH to 32, and then use the trick function.
Q1: It is in general possible to enlarge the ID room, but this would need a fair amount of programming effort and reduce the speed and cause enlargement of the overhead. Right now I cannot imagine a use case for more than 16000 IDs. ~Do you?~ How many prints are currently in your SOC?
Q2: The Trice tool ignores any print statements. As long as those use different output channels, they can operate parallel. ~But what would be a use case?~ On your SOC you probably do not want exchange all prints. So simply let the Trices write to any output which is not used.
OR: Replace all printk with trice64 using search and replace in one shot. Then look if there are any floats and if, what we not expect, handle them according the user manual and the same with %s.
OR: Read about the Trices binary encoding. You could frame all print output and the Trice tool will
handle such frames separately. But that needs a small Trice tool extension for buffers having the first 2 bits 00. For example, in your SOC, when a string is to be transmitted, simply prefix it with a 2-byte count containing its length and frame it as configured in triceConfih.h. Extend the Trice tool with a CLI switch to tell about the handling of such buffers. This should be no big deal. Then you can have prints and Trices parallel on the same output. Actually I start to like this idea...
By the way: Your example will not work. You should write trice8( "... and not trice8( ID(2), "... - or if you want to insert the id 2 manually trice8( iD(2), "... - please read about the Trice macro variants in the user manual.
Q3:
The 8 means 8 bit data width. That means a data range from 0 to 255 or -128 to +127 respective. The TRICE_DEFAULT_PARAMETER_BIT_WIDTH is used for the trice macros (without bitwdth in the name). Please check The Trice user manual.
Finally: It is better to have different issues for different questions, so others can quickly find their themes.
Update to your question 2: Maybe the pull request #533 is interesting for you. This is work in progress.
Thank you for your reply Response to Question 1: I haven't counted the number of printfs, but there are many. Also, the printf logs are still changing.
Response to Question 2: I don't know much about Go language, so I can't modify the source code of the trice tool for now.
It would be better if using trice l -p COMn [option] can dynamically support outputting only trice logs, only printf logs, or both trice and printf logs.
The Trice tool on receiving, evaluates the very first 2 bytes in an arriving buffer as little endian and checks the 2 most significant bits of the high byte (the 2nd one). If they both zero, than it is possible to tell the Trice tool, what to do. I could add a CLI switch, to tell that the remaining 16 bit are a printf format string length including the parameter length and extend the Trice tool appropriate. Your part would be to add a small filter in your embedded system, which adds a uint16_t count in front of the print transmit buffer and calls the configured framing function, like TCOBS before transmission. Than the print output is intermixed with the Trice packages and the Trice tool displays everything in the arriving order.
To just show only print output any standard terminal will do.
When I call TriceNonBlockingDeferredWrite8 and directly write data to ttyS0, it enables the concurrent output of Trice and printf logs. When using trice l -p COM5 to output Trice logs, the Trice logs can be displayed as expected. However, there are some abnormal logs during the display process. Could you help identify the cause? Jun 4 12:27:20.227573 COM5: 0 CYCLE_ERROR: 110 != 192 (count= 1 ) Jun 4 12:27:20.255321 COM5: WARNING:unknown ID 10593 - ignoring trice ending with: Jun 4 12:27:20.255321 COM5: Jun 4 12:27:20.255321 COM5: Hints:Baudrate? Encoding? Interrupt? Overflow? Parameter count? Format specifier? Password? til.json? Version? Jun 4 12:27:20.256276 COM5: 0 CYCLE_ERROR: 193 != 111 (count= 2 )
Jun 4 12:28:13.234522 COM5: 0 ERROR:triceType typeX0 not implemented (hint: IDBits value?) Jun 4 12:28:13.234522 COM5: 0 ERROR:triceType typeX0 not implemented (hint: IDBits value?) Jun 4 12:28:13.234522 COM5: 0 ERROR:triceType typeX0 not implemented (hint: IDBits value?) Jun 4 12:28:13.234522 COM5: 0 ERROR:triceType typeX0 not implemented (hint: IDBits value?) Jun 4 12:28:13.234522 COM5: 0 ERROR:triceType typeX0 not implemented (hint: IDBits value?) Jun 4 12:28:13.235016 COM5: 0 ERROR:triceType typeX0 not implemented (hint: IDBits value?) Jun 4 12:28:13.235016 COM5: 0 ERROR:triceType typeX0 not implemented (hint: IDBits value?) Jun 4 12:28:13.235016 COM5: 0 ERROR:triceType typeX0 not implemented (hint: IDBits value?) Jun 4 12:28:13.235016 COM5: 0 ERROR:triceType typeX0 not implemented (hint: IDBits value?) Jun 4 12:28:13.235216 COM5: 0 ERROR:triceType typeX0 not implemented (hint: IDBits value?) Jun 4 12:28:13.235216 COM5: 0 ERROR:triceType typeX0 not implemented (hint: IDBits value?) Jun 4 12:28:13.235515 COM5: 0 ERROR:triceType typeX0 not implemented (hint: IDBits value?) Jun 4 12:28:13.235515 COM5: 0 CYCLE_ERROR: 32 != 148 (count= 3 ) Jun 4 12:28:13.235515 COM5: WARNING:unknown ID 7515 - ignoring trice ending with: Jun 4 12:28:13.235515 COM5: Jun 4 12:28:13.235515 COM5: Hints:Baudrate? Encoding? Interrupt? Overflow? Parameter count? Format specifier? Password? til.json? Version? Jun 4 12:28:13.236014 COM5: 0 CYCLE_ERROR: 149 != 33 (count= 4 ) Jun 4 12:28:13.236014 COM5: Hello ddd =11 Jun 4 12:28:13.236514 COM5: 0 HHello qqqqq =7.200000 Jun 4 12:28:13.237683 COM5: 0 liuxuliuxu Hello! 👋🙂
This looks like the Trice tool receives inconsistent data. Maybe some mixture of normal printf output and trice binary data. Recommendation:
- Use the
v -s -debugswitches as well to see more details. - Do a
#define TriceStamp32 0x11111111in triceConfig.h - a fixed value just for debugging. - Provide your triceConfig.h file here.
- Use for getting started just one singe Trice message:
TRice("Hi %d\n", 0x22222222);and nothing else. - The next is true for
#define TRICE_DEFERRED_OUT_FRAMING TRICE_FRAMING_NONEotherwise you see the TCOBS encoding first. - Then you should receive:
idL idH 11 11 11 11 c0 4 22 22 22 22. idL is the lower part of your iD(n) value and idH the higher part of it consisting of the 6 lsBits ored with 0xc0 (2 bits to tell that there is a 32-bit timestamp. See TriceUserManual for details. TheC0is the very first cycle counter (192), the4is the payload size and the 422are the payload. - If you receive s.th. else you have to check your system. Trice needs to be alone on the serial line.
- Once this works, send the Trice message in a loop, like once in 100 ms.
As told, The Trice tool needs an extension and your system needs to frame the printf approriate to get mixed logging work.
Thank you for your reply, and I will revise it according to your opinion.
Check for alias functionality in the master branch user manual chapter Legacy Project Code Integration. Including unchanged legacy sources is now possible.
https://github.com/rokath/trice/blob/master/docs/TriceUserManual.md#trice-trouble-shooting-hints is now improved.