In my previous blog posts, i was verifying the theory of using a functional programming language like Clojure with a very well-known IOT module ESP8266. It was a great success and we can see that we can now control that module’s GPIO pins by sending HIGH and LOW signals.
Now begins the next chapter. In this chapter we shall explore how we can control multiple of them. I would be asking myself questions like is it possible to control them synchronously and asynchronously? Can i use Clojure pipelines ? How about using Kafka ?
Using the Cloudiuno library, this code is testing the HIGH and LOW signals on PIN 0 with a 6 seconds delay.
I used a voltmeter to see if the voltage was changing after 6 seconds. So this is what i could see on my terminal while it was running.
And i had a voltmeter attached to the PIN 0 of ESP-01 to see if the voltage was actually changing. You would need a voltmeter to check if the voltage is changing after 6 seconds.
Then after 6 seconds,
During this experiment i noticed that the signal value was inversely proportional to the voltage that was being displayed on the multi-meter. I am still not sure why that happened. Could it be a bug in the library ?
Anyways, this is a great success as now we can finally use Clojure (The Functional Language of our choice) to program hardware such as the famous IOT module called “ESP8266” or to be more specific ESP-01.
I ordered few more of these from China which has now been delivered so i am thinking of a way to use them to prepare a good demo.
Wish me luck.. this is not the end, this is just the start so keep following !
Today, i am going to start with a fresh mind-set and i am going to reiterate some of the things just to make sure i am going in the right direction.
I started with the basic sanity tests.
Test # 1 : Hardware
So i have ESP-01, i have just verified that i haven’t burnt the IC yet by uploading the blinking example.
Test # 2 : Code
I went to Firmata Github and cloned the latest version of the code in my Arduino. For those who are not aware of how to do it the steps are listed in the readme of the linked github also i am copy/pasting them here:
Navigate to the Arduino application
Right click on the application icon and select Show Package Contents
Navigate to: /Contents/Resources/Java/libraries/ and replace the existing Firmata folder with latest Firmata release (note there is a different download for Arduino 1.0.x vs 1.6.x)
Restart the Arduino application and the latest version of Firmata will be available.
while reading through the code i saw the following note which suggests that we cannot use Serial.print() with ESP-01 which means it is hard to debug on ESP-01
Note: “The blue LED on the ESP-01 module is connected to GPIO1(which is also the TXD pin; so we cannot use Serial.print() at the same time)”
Test # 3 : Upload To test the code is uploaded properly, i uploaded the blinking example first so that i can see the internal LED blinking and then uploaded the StandardFirmataWifi version that stopped the blinking.
Test # 4: Firmata Test I used the same firmata test program that i used in my previous test to check if Firmata is loaded properly on the ESP-01. But again there were no buttons even though i had selected the correct port.
Looking at all those test results, i believe that Firmata Test Program is expecting ESP-01 to operate on a certain baud rate and it is not able to meet its requirements so TX and RX rate is very low and therefore no buttons are loading. But this is a hypothesis which i still need to test. So that will be my Test 5.
I started with a sketch for programming ESP-01 because it was quick and easy way to explore the Frtizing software.
I really thought it was a simulator and it would make my life easier by just letting me work on my laptop until the whole project is complete. But i couldn’t find the “play” button. No wonder why. After some research i found their FAQs and the first question was “Does it simulate my circuit?”
“Does Fritzing simulate my circuit? (a.k.a. Where is the play button?)No, sorry. We don’t think that the advantage of having a simulation is worth the effort. Hardware is very difficult to simulate and it would also complicate the usage of Fritzing. Also, we think that it is important that you get hands on with the real stuff, and that you should try out your circuits physically. We will however add some simple checks in the future, to help you avoid common mistakes. For a more complete discussion, see http://fritzing.org/forum/thread/413/, particularly the comment from Brendan Howell.”
This is why we should read about the software first before overthinking its benefits. Now, i am back to where i was before my last post which was about making firmata work with ESP-01/ESP-12.
I did some more research on this topic and found many useful links. After reading the solutions offered by other engineers, i have come up with my own which i will discuss in my next post.
Weekdays are hard for me to document the approach because i only get half an hour in my lunch time to work on this project and then when you are stuck you just want the answer before you can write something.
I finally decided to put my tools down and summarise the approaches and findings. Well, first things first. I was right in my previous post that i was not using the compatible Firmata version for ESP8266 which lead me to investigate if it is actually compatible with ESP8266. The latest versions are compatible with Firmata according to the documentation. Many people have used this approach to talk to their devices using different languages.
Anyways, back to the main thing again. No, i have not yet been able to get Firmata work with ESP8266. I am still investigating the problem. So my next approach after all those findings is to ditch the real hardware world and use Fritzing and test my code there. If it is what it seems like meaning that i can test my code on the virtual hardware then implementation would become very easy.
So here is the working code, which is suppose to talk to StandardFirmata in the ESP8266 and blink an LED. The code compiles properly and runs without any issues. But i don’t see any LED blinking.
Another approach i took was to verify if StandardFirmata is working. I used the Binary file from the project firmata-test and gave it the port my device was connected on. I got a completely blank UI as you can see in the screenshot which suggests there is some problem with the StandardFirmata. It may be incompatible with the type of hardware i am using for this test.
I also have ESP-12 handy, so the next test would be just to verify if StandardFirmata has compatibility issues with the ESP series. But also there is some good news, its about another way of compiling Clojure into binary, it needs more discussion so i will go in detail in the upcoming posts.
Today is the day 2 of the FIOT, as discussed in the previous post i shall be exploring the ESP8266 with a mainstream software engineering functional programming(FP) language.
In my current employment, we work in Clojure due to the language’s pureness and immutability. There is a discussion on StackOverflow that you can follow to read more about it being “probably the closest” to functional.
Following is the picture of the hardware i have chosen for this experiment.
At this stage, we have a set hardware and programming language, now we need some sort of IDE to convert our code into binary right?
Wrong, it is not that simple.
Unfortunately, Clojure cannot be directly compiled into binary at this stage. So we would have to use an intermediate bridge to communicate with the hardware. This is where Firmata comes to the rescue. The concept is that your hardware will run a Firmata protocol server and you will use a client library to instruct the hardware to do the job. It is not ideal but it is one step forward then not using a functional programming language at all.
The Firmata protocol is based on the midi message format but fortunately, we don’t have to learn what they are as the client libraries are a good wrapper. Since we have picked Clojure we have the following client library choices:
I have chosen Clodiuno for this task simply because it has good documentation and the code is straight-forward. I noticed the examples in clj-Firmata are using channels in clojure which i don’t think is needed for a “hello world” program.
Today, i have started exploring how we can use Functional Programming with hardware. Typically, hardware programming is done in C, Assembly or dialects of C/C++. It is easy to compile the code written in those languages and convert it into binary to burn it onto the hardware as a new firmware.
A simple google search will show you that there are people in the past like John Lee who published a book in 1972, who presented the concept of describing hardware as notations. Then in 1985, Meshkinpour and Ercegovac  proposed another Functional Programming style language called FHDL. So the idea about using functional programming with hardware is not new but the approach that has always been taken is to develop a separate language from the mainstream software programming languages and look at hardware as a completely different world.
The book Infrastructure as Code disagrees with the idea that hardware should be treated separately from your software component. The reason for treating hardware separately in the past was that it was expensive and it took more effort to add a new hardware or get a bigger machine for your use case. There is no reason to do that anymore as hardware is more affordable and easily accessible.
So in the upcoming blog posts i shall explore one of the most famous ICs for Internet of Things ESP8266 using a functional programming language. I am interested in hardware parallelisation, performance and code simplicity. Also, i shall explore some design patterns for functional programming languages like function composability.
Lets start this journey!
 J. A. N. Lee, Computer Semantics, Van Nostrand Reinhold Company, 1972.
 F. Meshkinpour and M. D. Ercegovac, “A functional language for description and design of digital systems: sequential constructs,” in Proceedings of the 22nd ACM/IEEE Conference on Design Automation, pp. 238–244, ACM Press, 1985. View at Scopus
 M. D. Ercegovac and T. Lang, “A high-level language approach to custom chip layout design,” Technical Report MICRO Project Reports 1982-83, University of California, Berkeley, Calif, USA, 1982. View at Google Scholar