Re: [RTnet-developers] some suggestions for the next TDMA version

[Jan K. <jan...@we...>]

Karl Reichert wrote:
> Jan Kiszka wrote:
>> Karl Reichert wrote:
>>> Jan Kiszka wrote:
>>>> Karl Reichert wrote:
>>>>> Hello,
>>>>>
>>>>> I'm currently working on getting RTnet working on an Infineon TriCo=
re
>>>>> 1130 and found some issues, which could be solved in the next major=

>>>>> TDMA version comming with RTnet. Would like to discuss these issues=

>>>>> to see other's opinion about that.
>>>>>
>>>>> The TriCore1 architecture is a little bit tricky. When you want to
>>>>> send a frame over Ethernet, the host (the "cpu") has to write it in=
to
>>>>> a shared memory (available via FPI bus). Then the host writes a
>>>>> special register to tell the DMUT (Data Management Unit Transmit) t=
o
>>>>> get this Frame from shared memory and write it into Transmit Buffer=

>>>>> TB. The TX block of the MAC takes the frame from TB and sends it to=

>>>>> MII, which will put it on the wire. All this can be found in detail=

>>>>> in [1], chapter 31.
>>>>>
>>>>> Here comes the problem: When sending request calibration frames, on=
e
>>>>> has to provide a transmission time stamp as close as possible to th=
e
>>>>> real transmission time. As the TriCore does not support changing th=
e
>>>>> frame after writing it into shared memory (by host), there is no wa=
y
>>>>> for providing a real transmission time stamp. Only option is to put=

>>>>> the scheduled transmission time there which will have the effect,
>>>>> that transmission time on the wire t_trans is always calculated to
>>>>> long because the real transmission is done later.
>>>> Unless you have to make the steps of writing to the shared mem +
>>>> triggering the transmission preemptible, the solution is simple: jus=
t
>>>> push out the local time taken right _before_ you start writing the
>>>> frame. For your arch, that is the point "as close as possible" to th=
e
>>>> real tx date.
>>>>
>>>>> To fix this issue there will be a few possibilities, one comes here=
:
>>>>> One could change TDMA.spec and allow slaves to send a two-parted
>>>>> request calibration frame. First one has a don't care Transmission
>>>>> Time stamp (marked as don't care by a bit or sth similiar). Slaves
>>>>> will notice their transmission time stamp in their TXISR, and send =
it
>>>>> in the second ReqCalFrm. This would make the whole process much mor=
e
>>>>> precise, but of course requires changes in TDMA.spec.
>>>> Yeah, that's how NTP and PTP work as well (follow-up message carryin=
g
>>>> the timestamp of the first one), IIRC. Would be possible to extend t=
he
>>>> specs, but there should be real hard needs for it.
>>>>
>>>> Again, as long as the tx timestamp is taken at a fixed date before r=
eal
>>>> tx, TDMA can handle this (may one should clarify the spec in this
>> regard).
>>>> Jan
>>>>
>>> Well, the problem is that FPI bus is a shared bus, which will have th=
e
>> effect that in some cases it may take longer until the frame is on the=
 wire
>> and in some cases it may take less time. As a result, the tx timestamp=
 is
>> _not_ taken at a fixed date before real tx.
>>
>> OK, that sounds almost like a "hard need". What are the other users on=

>> this bus, and who is controlling the access (host or devices)? And wha=
t
>> dimension would the jitter then have (10 of microseconds, more, or les=
s)?
>>
>> Jan
>>
> Other users can be in general every device also connected to FPI bus. I=
n my case, some memory is also connected to FPI, which has the effect, th=
at host and all devices using this memory accessing the bus. As those dev=
ices may read/write async from/into the memory, there is no way to ensure=
 stable times accessing this bus.
> The dimension of the jitter is very depending on the situation. In my c=
ase, using only host and Ethernet-Controller, this value is always around=
 11 =B5s, jitter is less then 2 =B5s. But this is really depending on the=
 use case. If there would be other devices using the bus (USB, serial ...=
), the jitter will be much higher for sure. Would be worth to do some tes=
ts for that, but I'm lacking time ATM, I'm sorry. But they will be high, =
for sure.
>=20

Well, then let's draft a straight forward protocol extension: Some new
frame type shall be introduced, let's call it "Prologue Frame". It shall
look like this:

Version: 0x0202
Frame ID: 0x0020
<no further fields>

That frame is intended to serve as the timestamping reference for the
follow-up frames (sync, calibration request/reply). This means that,
instead of the RX timestamp of the succeeding frame, the RX time of the
prologue frame will be considered by the receiver. This, of course, also
means that the frame will _always_ be paired with a standard TDMA frame.

It shall be an optional frame, ie. both the sender and the receiver
don't need to issue/interpret it. If the receiver ignores it, the error
of the succeeding original frame would rise, but TDMA should still work
safely (this claim needs more thoughts, though). If the sender doesn't
issue it, all would work as before anyway.

I can't provide a helping hand on the implementation right now. So if
you are interested in drafting such an extension, only review can be
provided. The best test-case would be on your side anyway :).

Jan