>> 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
> No, as far as I can tell, it's not. You know the length of the
> packet, and the stop character is there just as a check.
I'd have to describe the protocol as broken in that case, and only
completely implementable in hardware rather than in software.
>> HDLC does not use a length field, but does have the procedure
>> above to ensure unambiguous detection of both start and end of
>> field.
> Instead of this, Profibus uses an idle time of 33 bits to ensure
> unambiguous detection of frame boundaries. Therefore, I'd like
> to be able to find out from the hardware driver when such an
> idle period happens.
Just a thought, but "33 bit time periods" sounds like 8E1 or 8O1 and
"3 character periods". If such is the case, it shouldn't be hard to
handle. Let me go back to my original specification, and I'll reply to
that with additional comments including what I see for this...
> Isn't this where we started off?
Not quite, no.
>>> 2. Each action frame shall be preceded by at least 33 line
>>> idle bits (Syn Time).
>>> 4. The receiver checks..the Syn Time in the case of an action
>>> frame.
>> 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?
>>> If the check fails, the whole frame SHALL BE discarded.
> Note "shall be", not "may be" or "should be". My interpretation
> of that is that the receiver is required to detect it, yes.
My interpretation of that is that it is written in LEGALESE, and in
the said language, "may" and "should" do not exist since they are
considered to be too vague.
You may wish to submit a copy of the said specification to the Plain
English Campaign for comment: you will probably find their remarks
very instructive...
>> Is the specification available on the web anywhere?
> There are some docs on http://www.profibus.com/ but not the
> complete ones. You have to be a member, or pay for them. I took
> the latter route, and only have a hard copy.
I'll have a look and see what is available there, and let you know...
>> To be honest, it's probably not going to be available on ANY
>> multitasking system - especially not on Macrohard's LoseSleep
>> 9x offerings...
> That doesn't mean that it can't be done on Linux.
You appear to have missed the point I was trying to make, so can I
rephrase it...
Q> Since MacroHard's OS's have such a large share of the market,
Q> I would be VERY surprised to see a new bus specification turn
Q> up that is incompatible with their product range.
In other words, if Lose9x can't handle it, the bus is not likely to
succeed in its current form, so I would watch out for sudden changes
to the specification to enable said OS to support it.
> If it's physically possible to do it with the hardware in
> question, then I expect Linux to be able to support it.
I would be VERY surprised if there is ANYTHING that can't be supported
in Linux. Profibus is no exception to that.
> My expectations of Windows, while they appear to match yours,
> are irrelevant.
Expectations of Windows may be irrelevant, but not expectations of the
forces that M$ can bring to bear to enable their OS's to support
something.
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/