>> Following my tests with PWM generation using GPIO in user space [1],
>> I've made the RTDM module [2] to further reduce the jitter. As a
>> result, jitter was improved, but still under heavy system load the
>> servo motor I am trying to control starts shaking. Now, I fill stuck
>> and hope to ge
> Another trick, which this time really is a workaround is to program the
> timers to wake up a little bit early, and spin to wait for the exact
> time wanted.
Sounds like the black magic exercise! :-) I would try to stay on the
bright side as long as I can :-)
Thanks Gilles! It is really great t
retval = rtdm_task_init(&pwm_task[i], // there is currently only one
element in this array
"pwm-task",
pwm_task_proc,
0,
RTDM_TASK_HIGHEST_PRIORITY,
2
>> retval = rtdm_task_init(&pwm_task[i], // there is currently only one
>> element in this array
>> "pwm-task",
>> pwm_task_proc,
>> 0,
>> RTDM_TASK_HIGHEST_PRIORITY,
>> 2000); // 20ms
Hi Folks,
Following my tests with PWM generation using GPIO in user space [1],
I've made the RTDM module [2] to further reduce the jitter. As a
result, jitter was improved, but still under heavy system load the
servo motor I am trying to control starts shaking. Now, I fill stuck
and hope to get so
> - they will both be gone in xenomai 3.0, only the RTDM API will be
> available in kernel-space.
I think you convinced me to start with RTDM API with the statement above :-)
Thanks,
Andrey.
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://m
Thank you very much Gilles for the explanations!
I think I understand the overall picture better now.
Thank you,
Andrey.
On 16 April 2012 01:52, Gilles Chanteperdrix
wrote:
> On 04/16/2012 01:47 AM, Gilles Chanteperdrix wrote:
>> On 04/16/2012 12:53 AM, Andrey Nechypurenko wrote:
>
Hi Gilles,
Thank you very much for such low-latency reply! :-)
> RTDM is the API of choice for developing drivers for real-time
> applications using xenomai.
Please correct me if I just misunderstand something here, but as I
understand, RTDM is an abstraction layer with concrete implementation
u
Hi Folks,
In our hobby robotics project [1] we start using Xenomai for RT tasks.
The first application was PWM generation with GPIO to control servo
motors [2] (the next would be dealing with interrupts from wheel
encoders). We have made it from the user space and result was not as
good as we woul
On 8 September 2011 04:03, Bob Feretich wrote:
> Is there a reason that your not using the BeagleBoard PWM Timer hardware?
I do use two of them. Attempt to generate PWM using GPIO is just for
me to learn about real-time performance I can achieve with Xenomai. My
hope that later, in addition to PW
> The best way to know if what you observe is due to the natural jitter or
> to some other issue is to measure the jitter at the point where you
> think it is.
Since the generation loop is so simple I was assuming (maybe too
naive) that this is exactly where it starts to deviate from the ideal
tim
Hi Folks,
Recently I was trying to control standard servo motor with PWMs. The
system is 600MHz BeagleBoard xM (ARM) running Linux kernel version
2.6.35.9 with Xenomai version 2.5.6.
Pulses needs to be generated with 20milliseconds interval (50Hz).
Pulse width defines servo position and is typica
Thank you very much guys for suggestions!
The idea with simple ring buffer looks promising and I will try to
implement it this way.
Once again thank you!
Andrey.
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-he
Thanks Gilles for the quick response!
> You can use mutexes with priority inheritance to avoid this issue. But
> Xenomai has ready made queues for rt/non-rt communication, the rtipcs:
>
> http://www.xenomai.org/documentation/xenomai-head/html/api/group__rtipc.html
What makes me worry here is the
Hi Folks,
In my application I have Xenomai thread which collects and process
sensor data. In addition, I have non-RT thread which sends sensor data
over the network for visualization (with much lower time resolution,
picking let's say every 100th sample). Xenomai thread is the only one
which acces
to the i2c controller.
Once again thank you Gilles for prompt response and suggestions!
Regards,
Andrey.
On Sun, Jun 19, 2011 at 6:57 PM, Gilles Chanteperdrix
wrote:
> On 06/19/2011 04:21 PM, Andrey Nechypurenko wrote:
>>>> The module works. I think kernel configured it properly be
>> The module works. I think kernel configured it properly because I can
>> use user space utility for example i2cdetect and see my sensors
>> detected on the bus. At the moment where I was trying to read the
>> status I did not made any reconfiguration before. So my assumption was
>> that the modu
> Ok. I would pass the size of an entire page anyway, I do not think
> mapping anything not aligned on a page boundary makes sense.
>
> If it still fails, enable CONFIG_DEBUG_USER in kernel configuration,
> pass user_debug=29 on kernel command line, and post the user debug log
> upon failure, then
Hi,
I am working on real-time control application using BeagleBoard
and Xenomai. Some sensors are connected to the second i2c bus. It
is necessary to collect sensor data strictly periodically and
that is why I would prefer to query the sensors from xenomai
thread.
I can read sensor data from user
19 matches
Mail list logo
