> Am 01.07.2016 um 16:27 schrieb matthew venn <[email protected]>:
>
> Thanks Charles.
> I started off with a non realtime python program loaded using loadusr, but it
> seemed too jittery to me.
> I'll have another go and post back.
I read through xbee.comp - you were using Linux file descriptors from a Xenomai
RT thread. This will not work as you cannot use the Linux system call API from
Xenomai. You will have to use the (rather cumbersome) Xenomai 2 API, and I do
not think a serial Xenomai driver is packaged with that kernel.
The moment you do, that RT thread will be 'relaxed' (Xenomai speak for "demoted
from RT priority to Linux cattle class Posix thread"), meaning all RT thread
properties are history.
Also you do a
usleep (35 * 1000); // sleep enough time for the chars to get sent
which will sleep your RT thread (which has a cycle of 1mS) for 35mS. So it is
now more a 36mS cycle, not a 1mS cycle.
All operations in a HAL thread function must be non-blocking, no waits.
That said, the crash cause is likely somewhere else as a relax usually doesnt
bring down the house but should be visible in the log.
Note you can use a userland component with SCHED_FIFO priority, which would be
pretty close in latency.
You could also read through the PRU code and add a tasklet for RC model servo
control. But given this timing behavior, a userland comp is your best bet.
>
> Matt
>
> On Friday, 1 July 2016 15:56:32 UTC+2, Charles Steinkuehler wrote:
> On 7/1/2016 8:01 AM, matthew venn wrote:
> > Hello,
> >
> > I'm working on a bipod (polargraph) style drawing robot. I'm using
> > machinekit on
> > beaglebone.
> >
> > I'm moving the pen up and down with a radio (xbee) controlled servo. I've
> > written a hal component in C that opens (non blocking) a serial port on the
> > beaglebone and then reads and writes to it. The component takes just over
> > 25ms
> > to run.
> > This component is added to a slow thread (50ms). I don't get realtime error
> > messages or joint following errors.
>
> You should add something that takes that long to run to a
> non-real-time thread. Even in a slow RT thread, your code is running
> with real-time priority which keeps other parts of the system from
> getting CPU cycles.
>
> Just write a normal program that does what you need and use "loadusr"
> instead of "loadrt". You can even craft code in python for talking to
> slow things like serial ports. See the python temperature reading
> code (in the various 3D printer configs) for an example:
>
> https://github.com/machinekit/machinekit/blob/master/src/hal/user_comps/hal_temp_bbb.py
>
>
> If you really want to use a real-time HAL component for this, you need
> to code the logic so each pass through the function happens quickly.
> That means keeping track of your current state in variables that
> survive across calls to your function, and when your function does
> run, you check to see if you can do the next step (like write the next
> byte or read a character). If so, you do that, otherwise you just
> exit. Also, you need to talk directly to the hardware (or via an
> existing HAL driver). Performing system calls (like reading or
> writing to a file descriptor) and doing things like usleep() in a RT
> function are very bad. The system calls will break all real-time
> guarantees for HAL, since the Linux kernel can do anything (like page
> a bunch of memory out to swap) once you give it control, and your
> usleep() is just burning CPU cycles at real-time priority.
>
> I strongly suggest you use a user-mode HAL component instead. The
> code you've got would be fine as a user-mode component.
>
> --
> Charles Steinkuehler
> [email protected]
>
> --
> website: http://www.machinekit.io blog: http://blog.machinekit.io github:
> https://github.com/machinekit
> ---
> You received this message because you are subscribed to the Google Groups
> "Machinekit" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> Visit this group at https://groups.google.com/group/machinekit.
> For more options, visit https://groups.google.com/d/optout.
--
website: http://www.machinekit.io blog: http://blog.machinekit.io github:
https://github.com/machinekit
---
You received this message because you are subscribed to the Google Groups
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.
