I took a systems and control course back in my GCSE days and own a Raspberry Pi, yet haven’t done any “electronics” work for years. That’s not to say I’ve haven’t talked about this stuff, I just haven’t done anything.

However the other day I was kindly given a NodeMcu dev kit to have a play around with, an awesome little microcontroller with WiFi, many GPIOs and I’m sure a lot more things I don’t understand at this moment. A £25 Amazon cart later to get some components (I could have stopped at £15 – but those Amazonians are clever with their recommendations) I’m finally ready to get back into some electronics.

Talking to the board (eventually)

I got started by reading through the NodeMCU documentation on uploading code, assuming the board would have come pre-flashed with firmware. ESPlorer seemed straight forward enough, so downloaded it, plugged in my NodeMCU over USB (got a blue light, it works!) and got started.

It detected that the MCU was on COM3, and so I attempted to connect. This was far from successful, getting stuck on “Communication with MCU…” which led to me downloading the driver, realizing that was silly because I already had it, and almost giving up. Fortunately, a little Googling later I realized I had to press the RST (reset, I assume?) button.

However, all I got now was it telling me it couldn’t autodetect the firmware, to reset the module or continue, and some incorrectly encoded characters. I attempted to run a simple “Hello World” but this just resulted in the MCU shouting at me with more characters. So I stopped.

Here’s where I assumed earlier assumptions were wrong, and I did need to flash some firmware. I grabbed a cloud build of NodeMcu (a nice feature) with the default settings and used pyflasher which was able to flash the firmware with extreme ease. I give full credit of this step to pyflasher, I hardly did anything.

However, although this was super easy it did absolutely nothing to help my situation. I was still on the same message.

This was when I noticed that the baud rate in my flashing application was set to 115200, rather than the 9600 I was attempting to use. I had assumed this was different due to the flashing vs normal access, but figured it was worth trying out.

This finally gets me in. I print “Hello World” in triumph.

Blinking

But I can’t stop there. I’ve finally got my access, surely I need to do something with it? So I set myself a mini challenge. Figure out this GPIO stuff, and make an LED blink. I’ve got the documentation, how hard can it be?

Turns out not very, the firmware makes interacting with GPIO very easy, and it is all well documented. However I’m feeling lazy and use a example I find in a GitHub issue online.

-- Blink using timer alarm --
timerId = 0
dly = 1000
-- use D4
ledPin = 4
-- set mode to output
gpio.mode(ledPin,gpio.OUTPUT)
ledState = 0
-- timer loop
tmr.alarm( timerId, dly, 1, function()
    ledState = 1 - ledState;
    -- write state to D4
    gpio.write(ledPin, ledState)
end)

This works nicely. The on-board LED blinks on and off. I feel like a master of electronics, bringing together code and component. I’ll rewire my flat later.

With further online research, I find reference to another on-board LED on pin 0. A little bit of code tweaking and I have that one blinking instead.

-- Blink using timer alarm --
timerId = 0
dly = 1000
-- use D0
ledPin = 0
-- set mode to output
gpio.mode(ledPin,gpio.OUTPUT)
ledState = 0
-- timer loop
tmr.alarm( timerId, dly, 1, function()
    ledState = 1 - ledState;
    -- write state to D0
    gpio.write(ledPin, ledState)
end)

Works nicely, but think I need to play around a little more, lets get both LEDs going.

-- Blink using timer alarm --
timerId = 0
dly = 1000
-- set mode to output
gpio.mode(0,gpio.OUTPUT)
gpio.mode(4,gpio.OUTPUT)
-- track states
led0State = 0
led4State = 1
-- timer loop
tmr.alarm( timerId, dly, 1, function()
    led0State = 1 - led0State;
    led4State = 1 - led4State;
    -- write state to leds
    gpio.write(0, led0State)
    gpio.write(4, led4State)
end)

But this is still using the on-board LEDs, which feels like a cop-out. Surely I need to get something working externally.

I draw power from the the pin labelled D2, route that to the LED, that to a 220Ω resistor (preventing too much current heading back) then finish up by sending it to the ground pin. I simplify my code again, this time using pin 2.

-- Blink using timer alarm --
timerId = 0
dly = 1000
-- set mode to output
gpio.mode(2,gpio.OUTPUT)
-- track state
led2State = 1
-- timer loop
tmr.alarm( timerId, dly, 1, function()
    led2State = 1 - led2State;
    -- write state to D2
    gpio.write(2, led2State)
end)

I run the code with high expectations, and nothing happens. I thought I had this?

I’m inspecting my circuit, when I notice the labels on my pins go “D0”, “D2”, “D2”, “D3” etc. What’s the betting I’m using a mis-labelled D1?

I modify my script, replacing references to pin 2 with 1, and get my flashing LED.

-- Blink using timer alarm --
timerId = 0
dly = 1000
-- set mode to output
gpio.mode(1,gpio.OUTPUT)
-- track state
led1State = 1
-- timer loop
tmr.alarm( timerId, dly, 1, function()
    led1State = 1 - led1State;
    -- write state to D1
    gpio.write(1, led1State)
end)

This makes me very happy. I have my LED wired up to an MCU and code switching it on and off. For anyone who knows anything about this stuff, this is nothing. But for me, this little blue flashing light is awesome.

I switch off the MCU and start tidying up the components that are now distributed over my desk. That’s enough for one day.

Actually, just one more thing…

Yes it’s late, but there’s this example on the NodeMcu homepage to connect to WiFi. I have to test run that right?

I run the script, then run the “getip” function a few more times. It only takes a few seconds at most to connect and show me a local IP. Works a treat.

print(wifi.sta.getip())
wifi.setmode(wifi.STATION)
wifi.sta.config("SSID","password")
print(wifi.sta.getip())

Right. Bed time. I’ll leave the rest for some other day.