>> There's no end of packet character? How.... awful.
> OK. It seems that I lied. There is an end of frame character,
> although I believe that it can also appear in the payload, and I
> was hoping to be able to use the timing specs instead.
If it can, it should be escaped, perhaps similarly to how it's handled
in the HDLC protocol (itself an ISO standard) in byte mode: The flag
delimiter (SYNC) character is hex 7E and (if my memory's correct - I
don't have the standard to hand) any time the system wants to send
either 7E or 7D, it sends 7D followed by the relevant code XOR'd with
hex 40. As a result, 7E only actually occurs as a delimiter, and 7D
only occurs as an escape character for 7D or 7E, which appear as 3D or
3E respectively.
I could easily be wrong about the escape character used, but the
method is correct.
> It's also possible to work out the frame length after seeing the
> first couple of octets, too - if it's a fixed length frame then
> you know its length after the first octet, and if it's a
> variable length frame then its length is reported in the second
> octet. So by combining the two, you can tell packets apart
> without seeing false end markers in the payload.
HDLC does not use a length field, but does have the procedure above to
ensure unambiguous detection of both start and end of field.
> And it's 33 bit times, not 27, just in case someone is feeling
> bored enough to read the spec, and pedantic enough to correct
> me.
> I suppose could get it to work if I just forget about the timing
> on the receive side, and use the start-stop chars to see where
> packets start and end.
Alternatively, see if the protocol says anything about an escape
method similar to the above.
> Strictly speaking, though, that approach violates the spec:
> PROFIBUS-Specification-Normative-Parts-4:1997, p122, §4.6.1:
>
> Transmission Rules
>
> 1. Line idle state corresponds to signalling level binary "1".
>
> 2. Each action frame shall be preceded by at least 33 line
> idle bits (Syn Time).
>
> 3. No idle states are allowed between a frame's UART
> characters.
>
> 4. The receiver checks: per UART character: start bit, stop
> bit and parity bit (even), per frame: start delimiter, DA,
> SA, FCS and end delimiter and the SYN Time in the case of
> an action frame. If the check fails, the whole frame shall
> be discarded.
Do the reception rules actually require the detection of the Syn Time
period, or is that just there to give the receiver time to settle
down?
> I would like to have the option available of obtaining
> certification for this, which means complying fairly strictly
> with the specification.
Is the specification available on the web anywhere?
> On the outgoing side, I can manage OK, but for receive, I really
> ought to have access to that kind of timing information.
To be honest, it's probably not going to be available on ANY
multitasking system - especially not on Macrohard's LoseSleep 9x
offerings...
Best wishes from Riley.
PS: The kernel versions page is now back online at the URL below, and
includes separate sublists both for each kernel series, and for
each year of development.
+----------------------------------------------------------------------+
| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |
+----------------------------------------------------------------------+
* http://www.memalpha.cx/Linux/Kernel/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/