Messages in this thread | | | Subject | Re: [PATCH v10 0/7] Add Fieldbus subsystem + support HMS Profinet card | From | "Enrico Weigelt, metux IT consult" <> | Date | Wed, 17 Apr 2019 22:13:59 +0200 |
| |
On 17.04.19 19:04, Andreas Färber wrote:
Hi,
> If you see specific conflicts or differences, please explain them> instead of just throwing around bus names. :) Then we can more easily> discuss whether to make changes to this framework or whether we indeed> need some fieldbus/iec61158/ subdirectory.
For example, MVB semantically is more similar to can/canopen or even SNMP than to iec61158. T-bus is logically more a typically network interface (similar to 802.3 or HDLC), WTB is actually HDCL via RS485. KNX has similarities to canopen or SNMP. DALI is somewhat similar to I2C.
Ergo: there're various fieldbus protocols with entirely different concepts. Distributed process memory like in iec61158 is just one of them.
> For your RS-485 I don't see > conflict as that'll just go via tty/serial/ and optionally serdev, no?
That's just layer 0/1. Ontop of that there're various protocols. Some folks do some ASCII-based protocol ontop of that (eg. elevators, water plants, etc), others put in HDLC (eg. WTB), some do completely weird things ;-)
> However, I'd be curious how I/O Link might relate to this, it seems to> have no public specifications. https://io-link.com/de/Download/Download.php https://io-link.com/share/Downloads/Spec-Interface/IOL-Interface-Spec_10002_V112_Jul13.pdf
> While I do like sockets, they seem more useful for packet-based> communication, which may be an implementation detail of fieldbus_dev> drivers, but AFAIU that's unrelated to Sven's memory-focused subsystem> representing a view of the data received, which may be different from> the last packet received. Also, when a packet is received via socket, it> gets dequeued, whereas you'll want to access the device's memory without> restrictions. okay, if the device always represents the current process memory, w/o showing the actual communication, then Sven's approach makes sense.
--mtx
-- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering info@metux.net -- +49-151-27565287
| |