How to debug a real-time component?

More
10 Jun 2019 17:15 #136495 by ajsinfotech
Hi comunity!

I want to develop a real-time component. But, for a serious real-time component I think, it needs to be debugged. So that way I could "really see" what happens inside it. That is why I am writing this post (sorry about this is not the right place).

Ok, after some readings I realize that I have to use halcompile command to compile a real-time component. I did one example and it seems to works fine. AFAIK this halcompile command seems to resolve several dependencies that are hard to resolve with the normal gcc compiler. I tried to compile that example with gcc but I have not any success.

Anyway, I still think any serious software development needs to be debugged so here are my questions to the Gurus: :)

- Is there any way to debug a real-time component? I mean, is there any kind of "haldebug"?
- If the "haldebug" commnand does not exist, is there any way to create all the needed dependencies to compile the real-time component with gcc command so then I can debug it with gdb?
- Or in another way, is there any script to resolve all the dependencies needed in an easy way?

I really appreciate very much any suggestion resolving dependencies about HAL, real-time component, software core and the like.

Thanks in advance!
Regards,
Alejandro

Please Log in or Create an account to join the conversation.

More
11 Jun 2019 05:17 #136551 by rodw
Welcome to the world of real time coding an interrupt service routine.

The easiest solution is not to make a mistake in your code and add plenty of debugging pins along the way which you can delete afterwards.

Keep components small and short. break complex stuff up into small discrete pieces.
Read the docs!!!! use halcompile!!!

Please Log in or Create an account to join the conversation.

More
12 Jun 2019 15:03 #136739 by andypugh

ajsinfotech wrote: - Is there any way to debug a real-time component? I mean, is there any kind of "haldebug"?


With the preempt-rt kernel it has been suggested that there might be a way ti use a debugger.

But I have never bothere, partly as I have never figured out how to use dbg even in normal code.
I just use a lot of rtapi_print statements in the code to tell me what is happening.

An extra bit of fun is that floating point variables are printed as FP hexadecimal.

This can be useful:
github.com/LinuxCNC/linuxcnc/blob/0f91c5...e5/docs/rtfaults.txt

Please Log in or Create an account to join the conversation.

More
14 Jun 2019 18:24 #136898 by ajsinfotech
Thanks for your replay rodw!

I will keep close to your suggestions, but I still think such a great piece of software deserve a better debugger. It is the "eclipse era" :)

BTW, I read the docs and I found this:

wiki.linuxcnc.org/cgi-bin/wiki.pl?DebuggingRtapi

A kind of procedure to debug a remote process. I think it could be useful so I drop the URL to the thread :)

Please Log in or Create an account to join the conversation.

More
14 Jun 2019 18:30 - 14 Jun 2019 18:33 #136899 by ajsinfotech
Thanks for your replay andypugh!

I found your link very interesting! :)

With the preempt-rt kernel it has been suggested that there might be a way ti use a debugger.

And I think yes! It could be a way (please see my replay to rodw).
Last edit: 14 Jun 2019 18:33 by ajsinfotech.

Please Log in or Create an account to join the conversation.

More
14 Jun 2019 20:56 #136911 by rodw
Its so long since I have played around with any debugging tools, and never on Linux. Remember that the servo thread is really a Timer Interrupt Service Routine firing every millisecond. Its not possible to step though this kind of code with a software debugger as bad things will happen. Just starting the debugger is likely to exceed the timer period so lockups will certainly occur as the CPU can't service all of the other interrupts flying around doing general housekeeping. I suspect you'd need a hardware debugger to have much luck.

I think there is a print command you can use (rtapi_print or something) that will print to the console but don't put it in the main function where its called every pass through the component as it will likely flood the system as well. Just use Halsshow or halscope to monitor values externally.

Please Log in or Create an account to join the conversation.

More
14 Jun 2019 22:22 #136922 by PCW
You can certainly slow the servo thread down to 1 Hz or slower for
debugging purposes, allowing any amount of printfs in debug breakpoints

Even better, Its probably possible with a little work to make a conditional
thread invocation option in the developed hal component function which
would allow single stepping a hal component all in hal, independent of the
thread rate. (the do-nothing hal pin)

Please Log in or Create an account to join the conversation.

Time to create page: 0.082 seconds
Powered by Kunena Forum