[Blaise Jarrett] has been grinding away to get the WebSocket protocol to play nicely with PIC microcontrollers. Here he’s using the PIC 18F4620 along with a Roving Networks RN-XV WiFi module to get the device on the network. He had started with a smaller processor but ran into some RAM restrictions so keep that in mind when choosing your hardware.
This project was spawned after seeing the mBed feature a few days back which combined that board along with a WebSocket library and HTML5 to pull off some pretty amazing stuff. [Blaise] doesn’t have quite as much polish on the web client yet, but he has recreated the data transfer method and improved on that project by moving to the newer version 13 of WebSockets. The protocol is kind of a moving target as it is still in the process of standardization.
The backend is a server called AutoBahn which is written in python. It comes along with client-side web server examples which gave him a chance to get up and running quickly. From there he got down to work with the WebSocket communications. They’re a set of strings that look very much like HTML headers. He outlines each command and some of the hangups one might run into with implementation. After reading what it takes to get this going it seems less complicated than we thought, but it’s obvious why you’ll need a healthy chunk of RAM to pull it off.
This is interesting to see websockets get ported to multiple microprocessors already. I’ve been dealing with websockets a bit lately and think it’s an interesting, if backward, concept.
I’m not sure though why websockets are preferable to standard sockets or simple HTTP requests in this case though. Perhaps someone can enlighten me?
(Is it a “just because” kind of thing, or is there an advantage here?)
i think the main bonus’s, is that websockets can be used from javascript without anything complex (flash/java/http polling) and that it operates over port 80, so firewalls wont notice it
it would solve the issue of sites like facebook making a request every 60 seconds (each one taking 60 seconds to reply)
hmm. Those benefits I understand.
My understanding was that you need a server for the websockets client to talk to, and since no one is running a web browser on their microcontroller I’m wondering what the advantage is on the microcontroller platform specifically?
the microcontroller would be a websockets client, connecting to the same server that the browsers connect to
while you could just use tcp at that point, and have the server bridge it over to websockets for the client, its one less port to keep open 24/7 waiting for the uC
piggy-back off the http server and let it do all the heavy lifting
Fair enough.
Guess I never thought of it as a problem to have two ports open instead of one :-)