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
A little background
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.
This is not an Arduino
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 init.lua.
So cool, just write up my script and upload it over the serial (USB)
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
So how does it work?
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!
Hacking the code
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
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.
Final command set
ls - list files on the device
rm [filename] - remove a file
ver - get the device version
put [filename] - send a file to the device
config - show the current app configuration
version - the version of this app
Configuring the serial port
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
The finished product
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
Here is my modified version of “Inbox Zero” with the different folders I have found fit my work-style feel free to improve on this.
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!
One of the most powerful motivators to keep on track with goals and to keep from getting discouraged is the humble progress bar. This is a simple and intuitive indicator of progress used in many day to day situations. Though lack of accuracy can be a downside, the advantage is that it can be intuited at a glace - making it easy to get an overview of a situation by a brief glance.
When I set out to design a dashboard for my personal life I had a few goals from the outset. First of all I don’t want to reinvent the wheel, I already have a perfectly good todo-list/organizer with Emacs org-mode. It suits me well to be able to edit a simple text file anywhere I have Emacs installed and sync up with git. The fact that it isn’t 100% ubiquitous on every platform, to me, is a feature. I normally use scratch paper, emails, etc. as a buffer and then later in the day store and organize these in org-mode. I find that many of my musings end up being not as critical to actually do as I originally felt. I like that lag so I can have a bit of perspective when planning my tasks and projects.
The second objective was “no effort”, clearly I didn’t want to reinvent the wheel but also I didn’t want this to feel like a process or something extra I need to do. If my org-mode notes are the “model”, I want this to just be the “view”.
Getting Started with Org-Mode
Org-Mode is an “add on” to Emacs that is specifically tuned to organizing your life. I’m not going to go into advanced detail on this since there are already some great tutorials out there. I’d encourage you to check out the following links first to get yourself familiar with the software
Once your warmed up to org-mode, it’s time to move on…
Tracking your goals
Now that you are comfortable with some of the possibilities of org-mode we are going to extend things a bit and create our own “system” within org-mode to track our goals. The power of org-mode (and Emacs itself) is the key philosophy that “everything is text”. Building off of this simple idea we can use a few consistent rules of our own to build up a format that we can parse with an external tool further down the road. This will allow us to “scrape” the notes we are keeping in Emacs/org-mode and create a html dashboard. Even though I use Emacs constantly every day, I’ve found it very helpful to have a web accessible quick view of where i’m at with all of my goals - keeping an eye on the bigger picture.
Org-Mode formatting “rules”
”* Long Term” - This is one of the ‘categories’ i am using to track multiple goals/projects you can adjust the code and wording as needed
”* Epic Goals” - This is one of the ‘categories’ i am using to track multiple goals/projects you can adjust the code and wording as needed
”* Study Goals” - This is one of the ‘categories’ i am using to track multiple goals/projects you can adjust the code and wording as needed
** + % = percent complete
** DONE = completed task (note that we are using “**”. In org-mode this is a sub-heading, this allows us to group multiple “todos” in a single category)
[X] = completed task
** TODO = unfinished task (note that we are using “**”. In org-mode this is a sub-heading, this allows us to group multiple “todos” in a single category)
[ ] = unfinished task
To help put all of these rules in context, here is a sample of what your org file might look like
* Epic Goals [0/2]
** TODO build a 3d printer
** TODO Run in a marathon [12%]
- [X] 1 k
- [ ] 3 k
- [ ] 5 k
- [ ] 10 k
- [ ] 15 k
- [ ] 20 k
- [ ] 30 k
- [ ] 42 k
* Long Term Goals [1/2]
** DONE Wedding [100%]
- State "DONE" from "IN PROGRESS" [2014-04-02 Wed 09:42]
- [X] date 26th
- [X] proposal
- [X] rings
- [X] decide where to do ceremony
- [X] invites
** TODO Hobbies - Reading - one book per month 2014 [58%]
- [X] Jan - Tampa
- [X] Feb - map head
- [X] Mar david and goliath
- [X] Apr - fail
- [X] May - fail
- [X] June - american gods
- [X] July - Stuff Matters: Exploring the Marvelous Materials That Shape.. Mark Miodownik
- [ ] Aug
- [ ] Sept
- [ ] Oct
- [ ] Nov
- [ ] Dec
Processing our goals file
Now that we have our file created and have some goals entered we need some way to “scrape” that file. I’ve created a mini parser called “GoalTracker” that is written in Go. The code is free to use and very easy to get started with ( https://github.com/zpeters/GoalTracker ). Simply clone from github. Next install the Go programming language ( http://golang.org/doc/install ). To compile the code just type “go build goals.go”, this will result in a binary for whatever OS you are using. Once the binary is created you can issue the following command “goals -dataPath=/my/path/to/my/org-mode-files/ -templatePath=/path/to/the/template/file/included/with/the/code > /var/www/html/goals.html”. Looking in the code you will see that by default it is looking for a file called “TODO.org” in your dataPath and a file called “Template” in your templatePath.
The resulting html file looks something like this:
Automating Dashboard Updates
Finally, we can automate the update of our dashboard with a simple git-hook. This allows you to run the dashboard update code in the background every time you commit your updated org-mode files. The following code should be placed in your _post-receive _file
rm -rf /tmp/Organizer
git clone /storage/GIT-REPO/Organizer.git
/home/zach/src/go/bin/go run /home/zach/Projects/Goals/goals.go -dataPath=/tmp/Organizer/Organizer/ -templatePath=/home/zach/Projects/Goals/Template > /var/www/html/goals.htm