An Overview of MicroPython

There are a lot of options available when one starts exploring the exciting field of the Internet of Things, or IoT. Not only are there many choices of micro-controllers, there are also a variety of languages in which to program these devices. Many times the micro-controllers are sold as being dependent on C or C++ as a language. That’s great, but I don’t know either of those. There is some great and amazing working being led by Andrew Chalkley around using the JavaScript language for micro-controllers over at thingsSDK. If JavaScript is your language, I’d highly recommend checking out their work. There are also lots of resources for using Java for IoT, Nathan Tippy, for example, is an excellent resource.

All those are great languages. What if you are a beginning developer just interested in playing around in IoT? Or what if you are a Pythonista and don’t want to pick up another programming language? Well, for many micro-controllers there is a Python option which is, arguably easier to learn in many ways than Java, JavaScript, C or C++. That option being MicroPython. You can see that project’s website here.

Overview of MicroPython

MicroPython is a tiny, open source Python programming language interpreter that runs on embedded boards. It was originally developed in 2013 and released in 2014 by Dr. Damian P. George of Cambridge University. It implements Python 3 and is designed specifically to run on devices with limited resources.

As with many things in the IoT world, the use of a particular language is greatly influenced by the tools, libraries, and packages one has available. MicroPython comes with an interactive read-evaluate-print-loop (REPL) for quick prototyping. It also fully supports loading MicroPython scripts onto a device to run as well. It supports an extensive Python based library and for lower level operations can be extended with C/C++ functions as needed.

Many of the tasks that beginning IoT folks start off with, such as blinking lights, reading switches, driving servos, etc. are all easy to do in MicroPython. Further, it is often incredibly easy to read as well, as it is all Python based. For example, if one has MicroPython installed on a NodeMCU ESP8266 board, a popular and inexpensive board to start working in IoT, with a basic LED light connected to GPIO Pin 5 it is pretty simple to get the light to turn on (high state) and off (low state).

import machine

led = machine.Pin(5, machine.Pin.OUT)
# Turn on LED
led.high()
# Turn off LED
led.low()

The machine module is included with MicroPython and handles many of the hardware connections from software.  It allows access to things like GPIO pins, CPU frequency, I2C busses, etc. If it is low-level on the hardware, the machine module is the way to go!

Platform Support

There are many devices that support MicroPython. The NodeMCU is one of them. But several other options are available such as the LoPy or similar PyCom devices, the PyBoard, and many others.

Differences from Python 3

As one can imagine, cramming everything from Python 3 into a micro-controller isn’t possible. But, core data types and modules which make sense for embedded systems are included. Another limitation is that since Python is a high-level programming language it isn’t as fast or lean as C or C++. Many operations aren’t impacted by this. However, if your application requires tight timing or performance is of utmost importance, using MicroPython can be an issue. However, as stated earlier, one can extend MicroPython to use C/C++ in these circumstances.

Since MicroPython is open source, check it out on GitHub, one can further extend or adapt it specific use case scenarios. For example, if you need something specific to run at boot time you can include it in the package that is flashed to the device. Pretty handy and convenient.

Conclusion

Hopefully I have at least sparked your interest enough in using MicroPython for IoT to take a further look at it. The development site actually has a live, interactive device where you can try out some code and see it run on a real world device. Give it a try and leave a comment below to share with others what you’ve done and built!

Follow me on Twitter @kenwalger to get the latest updates on my postings.

Facebooktwitterredditlinkedinmail

Modeling your data with Documents

I’m writing this post today while waiting for my oldest daughter to start her high school track and field event. I’m watching these talented athletes push their bodies well beyond anything I can personally relate to and in between rain showers and wind gusts there are meet records and hearts, broken. Since these are High School student athletes, my mind wanders to what their future holds. Will their athletic abilities allow them to compete at a collegiate level, or will high school be the glory days of their running, jumping, and throwing experience? Is a college athletic scholarship in their future? Hmmm…. a recruiting website for my daughter’s Javelin skills would be interesting.

Data Modeling Options

While building a site just for her would likely include static performance data, the data geek side of me wonders how one would model track and field participation data inside a database. As is often the case for those that have been around data for a while, we start to think of the tables we would need. Clearly, for our sample here we would need an athlete table, probably an event table with a list of possible events, another one for the meet name, just to name a few. We haven’t even gotten into data normalization yet, right? We should likely have a high_school table to maintain that information. A weather table to keep track of the rain and wind values, and much more. Here’s a quick visualization of what our database might look like in a relational database management system (RDBMS) world.

Relational Model

We would need all of these tables to be able to pull up data in our application to see which event Jane Doe competed in at a specific meet. Then JOIN it with all the other tables to be able to generate some useful information for a college athletic recruiter to see. That seems like a lot of joins (computational time). All to grab a relatively small percentage of the data from each row in our tables. For example, in the high_school table, we likely don’t need to display the school’s address and phone number on a student’s site itself. However, it would be nice to be able to provide a link to that information should a coach want to contact the school. We still, however, need to do the JOINs to get the information. Granted for those of us with some experience working with RDBMS technology, this example isn’t overly complicated and the SQL necessary to come up with the data and the specific JOIN statements aren’t horrendous, but we are still asking for some computational power to be expended to do the joins and retrieve the data.

Another Way to Model Data

What if there was another way to model our data? What if we could model our data in a way that was more application specific and suited our needs for showing off an athlete’s skills to potential recruiters? Further, what if we could do that and get data back from our database? And do so without JOIN operations and get all the data we need for our application at once? Sounds pretty amazing, yes? Well, that is precisely where we can use NoSQL and a Document Model for our data. Let’s have a look at how we might model our athlete’s data in MongoDB using their data model.

Document Model

To start with, in the document model, we can think about the information our application needs. Things like athlete name, event, time/distance accomplished for that event, when and where the event took place, what high school the athlete is from, etc. Instead of making unnecessary trips to the database, we can design our data for our application.

Our document, therefore, could be designed to hold all of the data our application would need. We could have our document look like:

Looks a lot like JSON

Something might seem familiar about this format too. It is modeled in JSON which, at least for me, is a much friendly format that table upon table. It also allows us to develop quickly. What happens when our student decides to do another sport in the fall and winter? In our RDBMS model that will involve more tables and joins. In our document model we can simply add another sport name, event, and statistic we want to track.

Another great feature of our document model is that we don’t need to be concerned with NULL values. If an athlete doesn’t participate in the long jump, there isn’t a reason to maintain a value for that. If they suddenly do participate in the long jump at a given meet, we can record that data as well. Similarly, if Jane and Kendra are involved in different sports, it is absolutely okay for their schemas to look different. They can even have different information. This is the concept of flexible schema and can be very powerful.

Document Model Key Features

There are several reasons why using a document model is becoming more and more popular. Some of them are:

  • The large amounts of data many applications generate combined with changing data types.
  • Rapid development times and agile development practices often require quick iterations of a product. A flexible schema in a document data model easily allows for this.
  • Gone are the days in which accessing data is from a single device to a single audience. Data needs to be always on and globally accessible in today’s world. This requires data stores to be able to scale accordingly and provide application specific data.

Conclusion

For all these reasons the document data model shouldn’t be discounted for your next project. In fact, I may just use such a model for my daughter’s recruiting site. After a long day at the track meet she threw her second best throw of the javelin ever at 92′ 6″. Perhaps not NCAA Division I bound. However, maybe with a web application backed by a document model a college somewhere will notice her.


Follow me on Twitter @kenwalger to get the latest updates on my postings.

There are a few MongoDB specific terms in this post. I created a MongoDB Dictionary skill for the Amazon Echo line of products. Check it out and you can say “Alexa, ask MongoDB for the definition of a document?” and get a helpful response.

 

Facebooktwitterredditlinkedinmail