Forgot to mention, you need to either change the component name to
xbee2 or more likely
change the file name to xbee.comp
You cannot have a different file and component name.
If you have an outdated version of comp which allows this, you will
have problems trying to load and use it,
because the component will be one name, but its exported name will
be another
regards
On 01/07/16 17:40, matthew venn wrote:
thankyou!
On Friday, 1 July 2016 17:03:54 UTC+2, Schooner wrote:
Hi
I won't bother repeating what Charles and Michael already
said,
usleep, read, write etc, all userspace.
Attached is a conversion of your comp to a userspace format.
comp quite happily builds userspace components from C.
It builds, but obviously I cannot test it.
The initial usleep in the loop may not be required, it can
be dispensed with or adjusted as required
regards
On 01/07/16 15:27, matthew venn wrote:
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.
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 machinekit+...@googlegroups.com.
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.
--
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.
|