Hi Guido, Thank you for taking some time to answer this.
2015-03-03 6:05 GMT+01:00 Guido van Rossum <[email protected]>: > I'll try to give some hints on Nicolas's original question. I agree with > Luciano that posting your source code would be helpful. > I know, I will try to push something soon. > I assume the serial port is a file descriptor. The big question is, does > it support select()? If it doesn't, you'd be in a world of pain (you'd have > to create a helper thread to read from the serial port). Assuming it does, > I think that the device itself should be treated as a stream, not a > datagram. And you should read up on the selectors module before trying > this. Using this and some examples it should be possible to create a > Transport that reads bytes from the serial port whenever the selector calls > its handler, and sends them to a (stream style) Protocol. > It sounds like it support it, I'm using the pyserial package, and, on the posix implementation (at least), the port is read with select. The idea I had was indeed to threat it as a stream of bytes, the datagram thing should come later (that why I was talking of chaining the (transport, protocol) pair, I don't know if this is doable, or/and a good idea, but I thought of a generic transport/protocol to read/write the serial port in a generic and reusable way, and then putting that into a another transport/protocol that is specific, in my case is this pair is for zigbee/xbee, but if another protocol over serial is to be implemented, this part only must be changed ) > I also assume you are speaking of "datagrams" because the semantics of the > device connected to the serial port are that it sends packets of data > consisting of multiple bytes and having a well-defined format. Your > Transport will have to parse these, and beware that a single read may not > get you all the bytes you want, *or* may return more bytes than you need -- > you may end up needing a simple state machine for the parsing. Then once > you have parsed a full packet you can call another callback function with > the complete packet. That may be a different method on the same Protocol > object, so you could have a single Protocol that in a sense processes both > the stream aspect and the packet aspect of the data. (Incidentally this is > how Twisted protocols tend to work.) > You are right with my choice of word for "datagrams", that, and the fact the protocol (network one, not in asyncio terms) is not connection oriented, but your description fit well (in fact, I've already done that for another protocol, with gevent, but I based my code on how twisted works to do that), I wanted to stay close to the asyncio way about datagram to have something that as the same "interface" to the user (sendto et all) > My bet is that your code got too messy when you were trying to parse the > data. The state machine idea may help here. > My code was to messy because I tried to subclass things already in asyncio but I guess I do not master the thing well enough to get somewhere since I ended subclassing lots lots lots of things (when I stopped, I was subclassing selector_events._SelectorDatagramTransport, _UnixSelectorEventLoop, _UnixReadPipeTransport) and then realised I must be completely wrong. That's why I was asking if someone had already managed to implement a new transport that was not based on socket, I did not yet tried to parse the data, the messier code is coming ;-) > Good luck! > Thanks ! > --Guido > > Have a nice day, Nicolas
