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

[Karl R. <Kar...@gm...>]

Jan Kiszka wrote:
> Karl Reichert wrote:
> > Jan Kiszka wrote:
> >> Karl Reichert wrote:
> >>> Hello,
> >>>
> >>> I'm currently working on getting RTnet working on an Infineon TriCore
> >>> 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 into
> >>> a shared memory (available via FPI bus). Then the host writes a
> >>> special register to tell the DMUT (Data Management Unit Transmit) to
> >>> 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, one
> >>> has to provide a transmission time stamp as close as possible to the
> >>> real transmission time. As the TriCore does not support changing the
> >>> frame after writing it into shared memory (by host), there is no way
> >>> 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: just
> >> 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 the
> >> 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 more
> >>> precise, but of course requires changes in TDMA.spec.
> >> Yeah, that's how NTP and PTP work as well (follow-up message carrying
> >> the timestamp of the first one), IIRC. Would be possible to extend the
> >> specs, but there should be real hard needs for it.
> >>
> >> Again, as long as the tx timestamp is taken at a fixed date before real
> >> 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 the
> 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 what
> dimension would the jitter then have (10 of microseconds, more, or less)?
> 
> Jan
> 
Other users can be in general every device also connected to FPI bus. In my case, some memory is also connected to FPI, which has the effect, that host and all devices using this memory accessing the bus. As those devices 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 case, using only host and Ethernet-Controller, this value is always around 11 µs, jitter is less then 2 µs. 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 tests for that, but I'm lacking time ATM, I'm sorry. But they will be high, for sure.

Karl
-- 
von Karl Reichert

Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kanns mit allen: http://www.gmx.net/de/go/multimessenger