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

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

Karl Reichert wrote:
> Hello,
>=20
> 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.
>=20
> 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.
>=20
> 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.

>=20
> 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)=
=2E

Jan