Messages in this thread | | | Date | Wed, 27 Oct 1999 11:27:17 +0100 (GMT) | From | Riley Williams <> | Subject | Re: serial.c (half duplex support) |
| |
Hi David.
>> 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/
| |