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:
> >>> 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.
> > 
> 
> 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
> 
Hmm ... sounds logical to me, should work at all. I don't have any time for implementation right now, too. But we should keep this in mind for the future. I could create a draft of TDMA.spec and maybe also of the RTnet implementation, but not now. I am very busy to at the moment, sorry. But we should keep this idea in mind and work on that later.

Karl
-- 
von Karl Reichert

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