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 ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ RTnet-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/rtnet-developers
