[Xenomai-help] timing within a task and assessing the timing of CAN messages

[Xenomai-help] timing within a task and assessing the timing of CAN messages

[Roland Tollenaar]

Hello,

I have three questions I would like to pose here.

1-Is it possible to subdivide a task to control at what time a certain 
command is executed within the task? Example: I have a 1ms task. I send 
a CAN sync message at the beginning of the task but I would like to wait 
about 300us before performing a read to ensure that all the messages 
emitted as a result of this sync have come in. Now I will have an odd 
700us to use the data that has come in to calculate outputs. However I 
want the output to be put out as close as possible to the end of the 
task time. Is there an elegant manner to delay the read and the write to 
give me this kind of control within a taks. If not any suggestions as to 
how I should tackle this.


2-For development I am still using the PEAK CAN dongle. We have 
establisched that the ISR responding to an incoming message interrupt 
takes 200us to complete. Is anything known about how long it takes 
before a message that has been sent is put on the bus? How does this 
happen? Reason I ask is to know what kind of variance I can expect in 
time between the moment I send the output values and the moment it is on 
the bus. If there are routines between those to points that allow 
themselves to be pre-empted or for some other reason have varying 
execution times my control performance will be badly degraded.


3-How do I interpret the relative time stamps that can be made visible 
with rtcanrev ? IS the time indicated the time between each message and 
the last time the message was posted? Or between the message and its 
direct predecessor?

In short, I want to ensure that my sync message goes out EXACTLY (or as 
close as technically possible :) ) every ms so I get the input 
(position) values exactly every ms. Then I want those values ot be used 
in the task to calculate the output and I want to set the output EXACTLY 
1ms later.

To achieve this so far what I have done is:

Beginning of task

1-Write CAN message with outputs values
2-Send sync to get inputs
3-Read can messages (This might be too soon to get the values from the 
last sync)
4-do calcs for output with data from 3.


Any ideas of howto to control this as well as possible will help.

Thanks kindly.

Regards,

Roland.

Re: [Xenomai-help] timing within a task and assessing the timing of CAN messages

[Sebastian Smolorz]

Roland Tollenaar wrote:
> Hello,
>
> I have three questions I would like to pose here.
>
> 1-Is it possible to subdivide a task to control at what time a certain
> command is executed within the task? Example: I have a 1ms task. I send
> a CAN sync message at the beginning of the task but I would like to wait
> about 300us before performing a read to ensure that all the messages
> emitted as a result of this sync have come in.

If you know the number of answering messages why don't you use blocking reads? 
In this way you would implicitely wait the right time.

> Now I will have an odd 
> 700us to use the data that has come in to calculate outputs. However I
> want the output to be put out as close as possible to the end of the
> task time. Is there an elegant manner to delay the read and the write to
> give me this kind of control within a taks. If not any suggestions as to
> how I should tackle this.

Maybe you are looking for rt_task_sleep_until()?

> 2-For development I am still using the PEAK CAN dongle. We have
> establisched that the ISR responding to an incoming message interrupt
> takes 200us to complete. Is anything known about how long it takes
> before a message that has been sent is put on the bus? How does this
> happen? Reason I ask is to know what kind of variance I can expect in
> time between the moment I send the output values and the moment it is on
> the bus. If there are routines between those to points that allow
> themselves to be pre-empted or for some other reason have varying
> execution times my control performance will be badly degraded.

The sendmsg routine of the SJA1000 driver programs the TX registers and then 
exits (if the TX registers are not occupied by a precedent sendmsg). The 
SJA1000 then is responsible to put the message on the bus. If the TX 
registers are free again the driver receives an interrupt. You could extend 
the interrupt handler with a rtdm_printk(actual_time) for your purpose.

> 3-How do I interpret the relative time stamps that can be made visible
> with rtcanrev ? IS the time indicated the time between each message and
> the last time the message was posted? Or between the message and its
> direct predecessor?

The latter one.


-- 
Sebastian

Re: [Xenomai-help] timing within a task and assessing the timing of CAN messages

[Wolfgang Grandegger]

Roland Tollenaar wrote:
> Hello,
> 
> I have three questions I would like to pose here.
> 
> 1-Is it possible to subdivide a task to control at what time a certain 
> command is executed within the task? Example: I have a 1ms task. I send 
> a CAN sync message at the beginning of the task but I would like to wait 
> about 300us before performing a read to ensure that all the messages 
> emitted as a result of this sync have come in. Now I will have an odd 
> 700us to use the data that has come in to calculate outputs. However I 
> want the output to be put out as close as possible to the end of the 
> task time. Is there an elegant manner to delay the read and the write to 
> give me this kind of control within a taks. If not any suggestions as to 
> how I should tackle this.

The task timing services allow to suspend and then resume the task at a 
defined time, either by specifying a releative delay or an absolute 
time, e.g. rt_task_sleep() and rt_task_sleep_until() for the native skin.

> 
> 2-For development I am still using the PEAK CAN dongle. We have 
> establisched that the ISR responding to an incoming message interrupt 
> takes 200us to complete. Is anything known about how long it takes 
> before a message that has been sent is put on the bus? How does this 
> happen? Reason I ask is to know what kind of variance I can expect in 
> time between the moment I send the output values and the moment it is on 
> the bus. If there are routines between those to points that allow 
> themselves to be pre-empted or for some other reason have varying 
> execution times my control performance will be badly degraded.

Reading, but also writing a byte to the port register task time. I 
think, that setting up a message for transmit takes as much time as 
reading it. Writing is also done with interrupts disabled.

> 3-How do I interpret the relative time stamps that can be made visible 
> with rtcanrev ? IS the time indicated the time between each message and 
> the last time the message was posted? Or between the message and its 
> direct predecessor?

The latter one if the option "-R" was used:

   $ rtcanrecv -h
   ...
	-T, --timestamp       with absolute timestamp
	-R, --timestamp-rel   with relative timestamp

Note that the timestamp is added in the ISR.

Wolfgang

Re: [Xenomai-help] timing within a task and assessing the timing of CAN messages

[Roland Tollenaar]

Hi thanks for below. All clear and all useful.

Regards,

Roland.




Wolfgang Grandegger wrote:
> Roland Tollenaar wrote:
>> Hello,
>>
>> I have three questions I would like to pose here.
>>
>> 1-Is it possible to subdivide a task to control at what time a certain 
>> command is executed within the task? Example: I have a 1ms task. I 
>> send a CAN sync message at the beginning of the task but I would like 
>> to wait about 300us before performing a read to ensure that all the 
>> messages emitted as a result of this sync have come in. Now I will 
>> have an odd 700us to use the data that has come in to calculate 
>> outputs. However I want the output to be put out as close as possible 
>> to the end of the task time. Is there an elegant manner to delay the 
>> read and the write to give me this kind of control within a taks. If 
>> not any suggestions as to how I should tackle this.
> 
> The task timing services allow to suspend and then resume the task at a 
> defined time, either by specifying a releative delay or an absolute 
> time, e.g. rt_task_sleep() and rt_task_sleep_until() for the native skin.
> 
>>
>> 2-For development I am still using the PEAK CAN dongle. We have 
>> establisched that the ISR responding to an incoming message interrupt 
>> takes 200us to complete. Is anything known about how long it takes 
>> before a message that has been sent is put on the bus? How does this 
>> happen? Reason I ask is to know what kind of variance I can expect in 
>> time between the moment I send the output values and the moment it is 
>> on the bus. If there are routines between those to points that allow 
>> themselves to be pre-empted or for some other reason have varying 
>> execution times my control performance will be badly degraded.
> 
> Reading, but also writing a byte to the port register task time. I 
> think, that setting up a message for transmit takes as much time as 
> reading it. Writing is also done with interrupts disabled.
> 
>> 3-How do I interpret the relative time stamps that can be made visible 
>> with rtcanrev ? IS the time indicated the time between each message 
>> and the last time the message was posted? Or between the message and 
>> its direct predecessor?
> 
> The latter one if the option "-R" was used:
> 
>   $ rtcanrecv -h
>   ...
>     -T, --timestamp       with absolute timestamp
>     -R, --timestamp-rel   with relative timestamp
> 
> Note that the timestamp is added in the ISR.
> 
> Wolfgang
>