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 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. 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.) My bet is that your code got too messy when you were trying to parse the data. The state machine idea may help here. Good luck! --Guido On Mon, Mar 2, 2015 at 12:18 AM, Luciano Ramalho <luci...@ramalho.org> wrote: > I am very interested in using asyncio for IoT projects. Node.js is > spreading like wildfire in the embedded world, and with asyncio Python > becomes a much stronger competitor. > > I think it would be helpful for those interested in helping you if you > published your code somewhere, no matter how messy you think it is. > That's how Linus managed to get people to help him build Linux ;-). > > Best, > > Luciano > > On Sun, Mar 1, 2015 at 7:29 PM, Nicolas Di Pietro <pote...@gmail.com> > wrote: > > Hello, > > > > I'm trying to implement a new protocol (zigbee first, but I have another > one on my desk also) but I'm banging into some walls about how to do it. > > > > If I have understood all things well, I should implement the data part > of the framing into a datagram_received method, my problem is I don't see > where to put the complete datagram unpacking (data, address), my guess is > it should be in the transport part, but I'm not sure of it, I did not find > any example of that (and in those I've seen, this is done by the os socket > part) > > > > I should be reading/writing from a serial port, this is done as it is a > stream, so, somewhere I have to to take this stream and "transform" it into > datagram. What should I do here ? I mean, should I chain two > transport/protocol couple ? (one stream based protocol, that, on > data_received, manage to transform it in datagram frames and put it into > some fake transport used by the datagram transport), if this is the case, > does someone here has an example how to implement a new transport, the > _clean_ way ? (have started to do it twice, but I never wrote a code so > messy, I stopped when I realised I was subclassing almost all things in > asyncio...), even if this is not the case, if someone has some code about > new transport that does not rely on socket or pipe, it could be great to > share. > > > > Right now, I've managed to read the serial port using StreamReader and > StreamReaderProtocol, now, I have yet to find how to feed that into a > transport (that's why I think about new transport) > > > > I know this case is a bit specific, but, I think, there should be, at > least one good example on how to do those kind of things. We are in a > momentum when a lot of "Internet of things" things are coming, and, a lot > of those things are using transports that are not either UDP neither TCP > and the protocol on it is not IP, some of those things communicate through > serial (in fact usb-serial adapter, bluetooth over serial, ...), but it > could be anything. I know I'm a bit late in the battle, but I found it not > easy at all to add something that do not use sockets. Python is a good > language to be used for those kind of things since, even the noobiest guy > on earth is able to learn it fast and to get something working, lots of > hobbyists are playing right now with those new devices and, if they could > find something that can help them fast to implement servers, I think (but > I'm no specialist) they could enjoy discovering and using python. > > > > Thank you for your advices and example (and for those that contribute to > python, your hard work) > > > > Nicolas > > > > -- > Luciano Ramalho > Twitter: @ramalhoorg > > Professor em: http://python.pro.br > Twitter: @pythonprobr > -- --Guido van Rossum (python.org/~guido)
