Why we need to retire the blinking LED as the entry into embedded programming
Something that was true since 1985 changed in Q4 of 2018 and we are yet to feel all the repercussions.
Every ThinkPad, iPhone, Kindle…every Alexa, Nest, Homepod…every DJI Drone, Go PRO or Tamagochi, every Fitbit, every Pebble…every Xbox or Nintendo…every Walkman, every Game Boy, every C64, Amiga or Tandy.
Every piece of electronics which we geeked out about, used, abused, eventually bricked then forgot…
Each and every one of them hails from the same embryo.
The blinking LED.
It used to be the classic “Hello World” of the embedded world.
But for a while now it has been due for an update. An update that would reflect the vanishing boundaries between different domains of software development, as brought on by IoT. Consider Gartner’s prediction: by 2020, 20.4 billion devices will be connected to the Internet. It’s time to replace the LED blink with a “Hello, Cloud.”
We could have spent a few more years debating about it but a major turning point happened in the last quarter of last year, giving us a perfect excuse.
What happened in Q4 of 2018 is that Python became the most popular programming language, according to the 5-minute video below that recently went viral. To become number one, Python toppled Java. Java sat on the top spot since 2000 after dethroning C, which in turn knocked down Pascal in 1985.
C and Java are related so the transition between the two is not as interesting as the rise of Python. How did a scripting language replace a comparatively low-level language as the most popular in the world? Will Python seep into all aspects of programming from supercomputers to embedded systems the way C did? And will it have a 33-year run on the top like the c-family of languages?
It’s impossible to tell, of course. But whatever skeptics and detractors may say, Python is more diverse than given credit for. It has only started to show its potential for programming embedded systems. What it lacks in efficiency and speed of execution, it makes up for in speed of development and deployment. And in the world of 32-bit microcontrollers, and short, Agile-based development cycles, this is often a welcome trade-off.
To demonstrate the beauty and elegance of Python in embedded applications, I want to show you the “Hello Cloud” example of Zerynth, a company I work with. Zerynth offers a Python toolchain for embedded and IoT programming.
In just 12 lines of readable Python code, you can connect your device to the cloud and send a message.
In this example, I am sending a “Hello Cloud” message from a Xinabox CW02 board (174-3702) – figure 2, below – to the OKDO Cloud (one of many possible board and cloud vendor combinations supported by Zerynth):
from wireless import wifi # choose a wifi chip (esp32) from espressif.esp32net import esp32wifi as wifi_driver # let's import the OKDO cloud modules; first the IoT module... from okdo.iot import iot # ...then the http client from okdo.iot import http_client # initialize hardware wifi_driver.auto_init() # connect to wifi (replace “SSID” and “password” with your credentials) wifi.link("SSID",wifi.WIFI_WPA2,"password") # create a "thing" thing = iot.Device("lJilHMrRU39spSMoJATGdeVs","maker:4JQTMUt5kNoqW1VeVoeEuiyKAFik6Nek8pDYkGD",http_client.HttpClient) # connect to the cloud thing.connect() # run the client thing.run() while True: # sleep a bit... sleep(1000) # ...and Hello Cloud! (you can personalize the message) msg = thing.publish_asset("msg","Hello Cloud! :-)")
You can see the result here and in Figure 1, below.
Figure 1: Screenshot of the OKDO Cloud Dashboard showing the message. In this example, the OKDO dashboard is publically shared. The platform also allows users to configure private dashboards.
Figure 2: The Xinabox set used in this demo
A total of 12 lines of code to connect your device to the cloud!
Compared to this, the classic LED blinking example of the embedded world looks as feeble as a gesture of a man who just woke up from a coma and is told to blink once if he is conscious.
And to think that back in the ‘90s, I had to learn assembler to blink my first LED. Even if you wanted to do it in C, you’d need to do it differently depending on the target microcontroller.
In contrast, the Zerynth tool-chain adopts Java’s “write once, run anywhere” approach to the embedded world, through its Virtual Machine firmware.
Does Python provide an equal degree of low-level access to the underlying hardware the way C does?
But the beauty of Python is that it’s the perfect “glue language.” The Zerynth tool-chain takes advantage of this by implementing a hybrid Python/C approach.
This means that experienced embedded developers sacrifice nothing, while newcomers to the embedded world can put their Python powers to good use in a brand new domain.
In that regard, Python is the glue in more than one way. It breaks barriers and brings together domains of software engineering that have been separated ever since the dawn of the PC revolution.
If Python can bring us closer to the atmosphere of that homebrew-era of IT, before the compartmentalization and uber-specialization of developers when the biggest innovations took place — then I am rooting for it to keep its top spot among the most popular languages for decades to come.
CommentsAdd a comment
While it may be useful to establish some "hello world" basic first steps of cloud data / computing, it is a bad idea to define cloud communication as the the standard first step for embedded computing - for multiple reasons.
My biggest argument against it is that, as their first lesson, it would be teaching them the first thing to do is to connect to the cloud. That is a bad starting point for embedded systems. The majority of embedded applications do not need remote data sharing and control. A fundamental goal of embedded systems is secure, reliable operation. The simpler the system and the fewer dependencies on outside equipment, the more likely it is that this goal of secure, reliable operation will be achieved. Starting with the simplest local first step and building upon that also lays a groundwork for debugging and troubleshooting problems. You can't break a problem down into smaller steps if the smallest step you know is a big one - even if the toolset makes it easy to take that big step with just a few lines of code.
This isn't an argument against benefits of cloud computing or making cloud computing more accessible. It is an argument that cloud computing shouldn't be the first step of embedded systems.
I don't think the old 'blinking LED' is quite dead yet: if you're building an embedded system from scratch, as opposed to using an off-the-shelf board, it still has its uses. With boards like the Arduino and Raspberry Pi available, very few people design and build their own processor systems nowadays. In other words, only use the LED to prove that a fresh hardware design is capable of executing a program.
Of course, when I designed my first microcomputer system back in 1976, flashing a LED on a GPIO pin would have been a luxury! Microprocessors had no latched GPIO, only 8-bit data and (usually) 16-bit memory address busses. To determine that your finished design actually worked, you needed the shortest possible piece of code that would produce stable, identifiable waveforms on some pins. An ordinary oscilloscope would be used to monitor these signals.
In fact the code consisted of a single instruction: an unconditional jump to location 0000h, located at address 0000h - a so-called 'jump-to-self'. On the Intel 8080 this was a 3-byte instruction consisting of the op-code, JMP followed by the upper and lower bytes of the address in memory locations 0, 1 and 2. The memory was an external UV EPROM which was 'burned' by a separate programming device, after which it was plugged into a DIP socket on the board. No need for assemblers or bootloaders, you typed the three bytes into the programmer via its hex keypad having looked up the hex code for JMP, in this case C3. When the board was powered-up, the oscilloscope would have shown nice clean pulses on the first two address lines A0 and A1, but no activity on the others. If you saw that, it was usually enough to prove your hardware design was OK.
The blinking LED concept became the norm as microcontrollers with their latched GPIO pins took over for embedded designs.
Of course, none of this is necessary now with the availability of off-the-shelf boards such as Raspberry Pi and Arduino. However for people starting out with their first microcomputer (e.g. BBC Micro) which booted-up with a command prompt inviting them to type in a line of BASIC, entering PRINT "Hello World" and seeing the response was always a thrill!
I thought of this article after attending a couple of workshops on embedded Python, where people who had never programmed, properly guided, were able to read a temperature sensor and send the data to the cloud, clearly using a hardware and software setup already tested.
I think that for a particular type of crowd, this is a more exciting “I made something happen” moment than making an LED blink.
The whole beauty of it is that one can achieve an exciting result without needing to understand the mechanics of TCP/IP, any more than a person needs to know the physics of LEDs to make them blink.
I believe that for many people the “Hello Cloud” type of example will be a more enticing entry into the rabbit hole of embedded development. Eventually, this would lead to mastering the fundamentals.
That’s why I wondered if it was time to raise the “hello world” bar.
That said, I will concede that for many others, the blinking LED remains the most viable approach to learn about our world.
In the late 1980s, I flashed my first LED, writing a short program in PICmicro Assembler. But perhaps after all these years, I must have forgotten the satisfaction of seeing the LED flash for the first time.
Maybe I raised the bar a little too much, but it could be a good topic for discussion.
@AndreaGalizia Yes agree, we need "hello world", I'm powered up and operational and "HELLO WORLD" I am doing what many people want to do these days and communicate. I don't think it replaces the blinking LED but it certainly is the next greeting... Love this for the ESP32, I can blink LED's, find my WiFi, but totally stuck connecting to it! Would be great to have something functional and then analyse the code and work backwards to understanding.
Seen this on Twitter, my my what a storm. But hey it's a community and I'm glad that DesignSpark allows us to express our thoughts on such things. BTW I'm for both, but I see the point Andrea was making, also I'm sure more people have now read the article due to the twitter fallout.
I must echo the sentiments of the Twitterati: the blinking LED does not need to be retired as the first "Hello World" indicator for programming. For everyone who finds them self in a beginning class or who is curious about what we have come to call "Physical Computing", the blinking LED is the most powerful indicator of "I made something happen!". In the classes I have taught, and with the young and not-so-young I have coached, your Python program would have been more than simply impenetrable, it would have been utterly unapproachable. While I agree that Python is a fantastic learning tool and allows near instant gratification (the success of CircuitPython speaks for itself), the first "Hello World" can't be in the cloud (today and in the near future). It has to be immediate and visible and not require a connection to the Internet. In my experience, one of the best ways to empower new learners is with a few quick successes as they climb the hill of complexity. I have started with a simple breadboard, some resistors and flicker LEDs and gotten amazement and excitement when the damn things just lit up. With that success in their pocket, we quickly moved on to making a single LED blink. Once the students get over the shock of making a simple program work, we can move on to wiring several LEDs and making them fill the world with glowy goodness. Once we are past that, we can take those willing to make the gear change to a different language on to Python and the Internet. But Python and the TCP stack is the sixth or seventh step, not the first.