Using WebSocket with PIC microcontrollers

[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.

Comments

  1. Matt says:

    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?)

    • mike says:

      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)

      • Matt says:

        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?

      • mike says:

        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

      • Matt says:

        Fair enough.

        Guess I never thought of it as a problem to have two ports open instead of one :-)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 92,028 other followers