North East Blog Directory

July 14, 2017


Fun and Games with i2c, esp8266 and MongooseOS

I have been using mongoose-os with the esp32, and wanted to try similar with the esp8266.
One of the examples I wanted to try was the adafruit-ssd1306 app, which is a js programm that calls the c-libraries through an api. Find it here 

Flashing it was ok

Loaded arduino-adafruit-ssd1306/esp8266 version 1.0 (20170712-183120/???)
Using port /dev/ttyUSB0
Opening /dev/ttyUSB0...
Connecting to ESP8266 ROM, attempt 1 of 10...
Running flasher @ 460800...
Flasher is running
Flash size: 4194304, params: 0x0240 (dio,32m,40m)
2656 @ 0x0 -> 0
262144 @ 0x8000 -> 94208
128 @ 0x3fc000 -> 0
4096 @ 0x7000
94208 @ 0x8000
774144 @ 0x100000
4096 @ 0x3fb000
Wrote 874416 bytes in 19.38 seconds (352.48 KBit/sec)
2656 @ 0x0
4096 @ 0x7000
262144 @ 0x8000
772016 @ 0x100000
4096 @ 0x3fb000
128 @ 0x3fc000
Booting firmware...
All done!

Then started up mos


All ok….the i2c display isn’t working yet, because the pins in the configuration is wrong. The Wemos d1 mini only has a few pins broken out and not the 14,15 in the demo.
So….from the Wemos, d1 and d2 are the pins for i2c. I changed the configuration to 1,2 and saved.
Instability ensues.
I need to flash it again to get the connection back. I try again, this time changing the connections to use the d5 and d6 on the Wemos. Again, instability, and multiple resets. I read a bit about the resets and thought it might be power instability, something to do with the filesystem(SPIFFs).
With fresh eyes I returned, I tried to just change the configuration to turn on debug for the I2C.
And look! When it was on, I saw in its reset, that the I2C debug issued warnings like GPIO6 is part of SPIFFs and shouldn’t be used.
One of the experiments, with pins 6, 7 scrambled the Wemos so  much that I couldn’t reflash it without getting serious.

Serious being a 5.8k resistor between GPIO0(which is D3) and Ground. Well it did in the end. First I had to learn a valuable lesson.

D pins on the Wemos are not the same number as the GPIO pins on the ESP8266.  maps it out.

d1 and d2 on the Wemos, are NOT GPIO1 and GPIO2, neither is d6 GPIO6. D1 and D2 are GPIO4 and GPIO5.

Display now works. No strange resets. Hope this will be of use to someone else.


by Brian at July 14, 2017 09:48 PM

July 13, 2017

Ryan Tomlinson

The Process Delusion

Speed wins in software development. It sounds wrong but it’s true. When people hear this they just can’t see why. They confuse speed with rushing or a reduction in quality. As a result of this fallacy they optimize for perceived quality. Adding process ensues. It’s usually reactionary; a deployment goes out and causes an outage, a post-mortem is held and the action is to add a sign off process by a Director of Engineering. Over time these process can easily surmount to a productivity slump.

Jeff Bezos summarises the problem with this cultural mentality in his 2017 annual letter:

"A common example is process as proxy. Good process serves you so you can serve customers. But if you’re not watchful, the process can become the thing. This can happen very easily in large organizations. The process becomes the proxy for the result you want. You stop looking at outcomes and just make sure you’re doing the process right. Gulp. It’s not that rare to hear a junior leader defend a bad outcome with something like, “Well, we followed the process.” A more experienced leader will use it as an opportunity to investigate and improve the process. The process is not the thing. It’s always worth asking, do we own the process or does the process own us? In a Day 2 company, you might find it’s the second."

This type of mentality produces stale engineering organizations. Over time you’re so locked in that you lose agility, autonomy, ownership and you’ve built The Titanic. Ironically companies that find themselves in this situation believe that “Agile” development methodologies can actually help them out in this situation. More process ensues.

So process is bad then right? Of course not. Question all requests to add process, whether externally pressured or within the teams. Automate as much as possible. Often the driver for process is actually visibility. Visibility can be automated. Most importantly understand your processes and document them. Associate timings against each process and dedicate time in your teams sprint (work day) to kill or automate constraints. A good way to do this is to produce a Value Stream Map for your team.

A bit of a contrived example but take a deployment process for example.

In this Value Stream Map I’m only mapping out the times for each process but typically we would put timings on the transitions too to indicate how long the wait is between processes. In doing so we can identify bottlenecks/constraints and look at ways to automate or remove these steps. If a request comes in to add a new process, add it to your value stream map and assess the impact of doing so.

Don’t let process own you. Prioritize autonomy and ownership but don’t lose sight of the benefits of standardization.

by Ryan Tomlinson at July 13, 2017 04:07 PM

# This site is managed by the team at SuperMondays, is hosted by the team at Consilience and is maintained on github.