I wrote this article as an introduction to the WifiMCU chip and to explain some of the troubleshooting thought process. If you want to get right to the code, jump to the finished product
I came across the WifiMCU in my latest binge on inexpensive eBay electronics. Following my recent obsession with Arduino’s I wanted to find something wifi enabled but all of the Arduino “sheilds” I found were just too expensive for just playing around. For example the CC3000. Nothing against Adafruit, I love their store, I’m just really cheap.
Soon enough my searching turned up the “new” EM3165 module. These are cheap. The bare module along retails around $8.00. Granted this is a system on a chip (SoC) with a “self hosted wifi library” - you get a lot built in - but it is still pretty far out of my abilities.
…Then i found the WifiMCU…
The WifiMCU is a $13.00 development board based on the EM3165 chip. What you get with this is essentially a platform with all of the power of the EM3165 chip that you can command program over a usb connector. The other fun bonus is that you get a lot of gpio pins on this so instead of using this as a peripheral to your arduino, it can actually do a lot of th hardware controlling. The guys at WifiMCU have done a lot of hard work to make this happen.
So with little hesitation I ordered the WifiMCU module.
So just to be clear this is “arduino-like” in the fact that it is a chip on a board with pins that you can control. You can read inputs and send outputs but this is not programmed like an Arduino.
The WifiMCU is loaded with Lua, a wholly different and much simpler language. This project is still in the beginning stages but you can see they’ve built up a really impressive list of commands already.
Here is the other difference. With an arduino you upload your
compiled executable through the Arduino studio (or other software) to
be run exclusively when the arduino reboots. The WifiMCU isn’t like
that. You don’t “reprogram” it, you run scripts on it. As a result
it’s “main program” is always the Lua script interpreter. The way you
get it to “run something on boot” is by naming your file
So cool, just write up my script and upload it over the serial (USB) interface…
Currently, the only way to “upload’ a file is with the WifiMCU Studio which is a Windows only app. I’ve only got a Mac.
This chip is too cool to just chuck in the bin, so I’m going to work around this.
After a back and forth with the developers, I found that the way they “upload” files in the WifiMCU Studio is simply to use the native lua commands on the chip to open the file and write it to memory. What this means is that whenever you want to upload or download a file from the chip you are essentially “typing in” the code when you save it and echoing out the text when you want to save it.
You can use a serial tool conneting to wifimcu at 115200,n,8,1 then type the above 3 commands indivaully. The 3 lines comands will create a file named “test.lua”, and the file will be stored in the embeded flash inside wifimcu. This is the uploading procedure. WiFiMCU STUDIO does the same thing. I hope this may help you!
I got the initial email from the vendor. I decided I really want to keep this as basic as possible so my initial set of commands will be “get”, “put”, “delete” and “list” - the very basics needed to manipulate files. I’m going to focus on making a very solid and minimal client and then potentially build on that if needed.
While I don’t want to get too elaborate I do want to “engineer” this a little. I’m deciding to use Go for the programming language, the main factor here is that i can make cross platform executables without a very complicated build environment.
I found the tarm/serial library which sounds like it should be pretty portable to Windows, Mac, Linux, etc. so this is where I’ll start.
I will probably use spf13/cobra for the cli since I’ve had really good luck with this in the past
Spent a few minutes gathering my thoughts and writing up the previous material. I think I have a good enough mental model built up to start coding soon.
Having some difficulties with serial connectivity on my Mac so i setup a dev environment in Linux under Virtual Box
Started working on the code. Got the project folder setup and I’m testing the example code from tamr/serial. I had to make a few changes but the initial serial communications back and forth is working. It’s all downhill from here
Here is the testing code
Now that the basic concept has been proven, i spent a little time building up some low level functions. First i built read and write functions to avoid future code duplication
Next, using these primitives I built up a “command” routine to send a command and retrieve it’s result. Currently, we aren’t trapping for errors but this will be done in the future.
From here, things build up quick. I was able to put together a higher level command to upload a file. This isn’t quite working yet so i need to do some debugging
So the code is getting to the point where we need a little structure so we’ll pull in spf13/cobra and rough in our UI. This will help to keep our code clean
Here is a quick example of the relevant parts. I built out skeleton’s for the commands that we’ll fill in as we go
Spent a lot of time working on the serial read/writing code. The way the serial prompt was designed it was really made for interactive use. I’m trying a few different ways to “flush” the serial line so that when I issue a command i get only the results. Right now I’m sometimes getting the command results and sometimes getting an echo of the command itself. I’ll need a little more work on this…
I think i finally got it working so now I’m wrapping up the command “interface”. The last piece of the puzzle is adding some configuration around the serial port, update the readme, cross compile and release an alpha version.
For configuration I’m using spf13/viper. It’s a little overkill for just the one configuration option (WMC_SERIAL) but it will allow for easy expansion in the future
For the newest versions of Go cross-compiling is a snap. Simply set the GOOS and GOARCH environment variables and Go takes care of the rest. Unfortunately, the underlying tamr/serial code doesn’t appear to support all platforms, so we are a bit limited. It’s opensource, however so we can always contribute changes in the future
Okay big disclaimer here, at this point the code has had maybe fifteen minutes of testing. This is not a robust code library at this point, just a quick hack. Use at your own risk. If you do discover a bug please report them to the “issues” page on github. Pull requests are welcome!
Lately my posts have slowed down tremendously with moving halfway across the country, starting a new job (twice) and getting married. Rather than continually put off larger posts because I don’t have enough material built up, I’m going to try to post shorter tips and tricks in between to keep up the momentum.
Today I wanted to share a quick email organization tip that I’ve refined over the years. Ideally, I try to pull every piece of relevant information out of email as often as possible and stick it into Evernote or an org-mode notes file. Getting information out of email and into an information system of some sort gets you 90% of the way, but there will always be that bit of info you missed in the flood of new emails. To deal with this I follow the process below to increase my ability to find the information I need.
The first order of business is to get information out of email. Email is a great tool for communication but it was never intended to be an information repository. Search will almost always be cumbersome and even if you find the email you were looking for it can take a great deal of cognitive effort to reconstruct what the train of thought was or way that email was important. Email generally doesn’t allow for meta-data so by capturing and “editorializing” the information in your own note-taking system you can add in the relevant context
Practice Inbox Zero. There are really only three “states” that email should live in. By practicing the art of quickly classifying emails in these categories you can quickly “deal with” large volumes of email rather than letting it build up:
1. "New" - email that you haven't seen yet 2. "Actions" - something you need to do 3. "Archive" - something you need to hang on to
1. 0-Action - Emails that are requests or reminders of things i need to do. If there is a specific task/deadline I will generally remove this to my "official" todo list in a different application and archive the email. Generally what is in here are reminders or items I need to do _sometime._ 2. 1-Hold - Informational emails that i need close at hand but do not represent a "todo" item. This should be a temporary holding place for "favorites". An example was a code that I needed for access to a system. I knew I'd only need it for a short amount of time so I moved the email there and then moved it to 2-Archive after a week. 3. 2-Archive - This is where you put _everything_ that isn't in another folder. Storage is cheap. Save Everything. Rely on good search abilities in your mail client to retrieve anything that you haven't deemed important enough to add to your notes. If you spend more than three minutes searching for something _add it to your note-taking system_ for the future. 4. 3-Feedback - This is where I keep positive (and negative) feedback to refer back to periodically. 5. 4-Awesome - Funny emails, pick-me-ups, etc. It's good to make time during the day to stop being so serious and enjoying work 6. 5-Templates - If i write the same email or answer the same question more than once I create a blank email and use it as a template
What organization systems do you use to keep the flood of email/information manageable? Please let me know!