Multi File Failure

Side Project:

I received the OLED breakout PCBs from OHSpark this week #SSD1332Breakout. I also received some of the parts to build it with.  I am hoping to have a working OLED by the end of this next week.  I will start with it in SPI mode to use existing code that I know works.  Then I will have to migrate the library to use 8 bit parallel interface mode.

I have decided to move forward with the STM32F103 as the microcontroller for the Arduino Compass Toy.  The microchip part is still a possibility if the STM32 chip doesn’t work out.

The Challenge:

I posted an Arduino programming challenge to the community on Google+ and to twitter this week.

The challenge is to make a blink sketch that has nothing in it’s loop().

This is a just for fun challenge. The only requirements are that the LED blinks and loop() is empty.

I ask that submissions are made on February 22nd 2017 tagged with #ArduinoEmptyLoopChallenge

Click here to see the Google+ post.

Adventures in TDD:

Continue reading

Unit Testing

TDD/Unit Testing:

I searched some for TDD tutorials this week. and found a few. Unfortunately, I found tutorials with no or very little “hands on” practice.  So I am still looking for good tutorials.  When I find some, I will post links on this blog.

What I have gleaned from the tutorials so far is that when building your code, you replace your main file with your testing file(s) so that the tests can call each of the functions/methods individually with known values and should get back predictable results.

Embedded Units Testing:

For embedded systems unit testing, my code will be compiled to run natively on the development machine rather than being compiled for the target processor.  This means a different tool chain for test build than for production or debug builds.

Note: Tool Chain is the set of tools that are used to create machine runnable code from your source files.

Any API call or peripheral device needs to have mock code that can be run as part of the tests.

Note: Mock Code is software that represents things that are not on your testing machine, or would hinder testing.

“Hello World”:

Continue reading



No new information on the ADC feature request on Espressif”s forums.

Side Project:

I have started layout of the SSD1332 Breakout PCB.  I finished the layout and ordered PCBs from OSHPark.  Based on the datasheet for the SSD1332, I can get significantly better performance by using it in one of the 8 bit bus modes.  Someone suggested that I look at STM32 processors to drive the display with.  I will be considering that option this week.

Better Firmware:

Continue reading

Design Decision

Side Project:

I am moving forward with the Compass toy prototyping.  I am designing a simple breakout PCB for testing the display. I may put the display breakout for sale on Tindie.

Project Intent:

The primary goal of this project/blog is to show electronics design start to finish.

The design goal is an inexpensive in circuit chip programmer that will work for most devices available.


The Raspberry Pi Zero was released November of 2015 at a price of $5 US each.  I even got one with a copy of MagPi.  To Make it run any code at all, it needs a power supply and microSD card.

Of course I could continue with the current design.

Common components:

Both the Raspberry Pi and the current design need the following components.

Printed Circuit Board
Battery for power supply and charging circuit
Vpp Supply
Level Shifter Circuit
External ADC(Still undecided for current design)
USB to serial Bridge (not sure it’s necessary for R Pi)

Additional components for Raspberry Pi:

Continue reading

Level Shifter Research


My ADC feature request on Espressif’s BBS has had 118 views. Unfortunately no word from the developers.  This might mean I have to add an ADC chip to the design.

The problem:

I’ve been thinking about the level shifter and why it was causing my software to crash. 10M Ohm and 10pF capacitance are very small loads. The software crashing just because a scope probe is connecting is very bad.(stating the obvious)

The hypothesis:

Bidirectional level shifters are typically designed to react quickly to transitions and drive very weakly in the steady state. With the target pins unconnected the shifter is steady state and the scope probe might be enough to cause a problem.

The Experiment:

Continue reading



I have received a reply on the Espressif forum that gives a few suggestions.  The suggestions did get me thinking about the problem in a new way, I’ll see where this leads.

Moving Forward:

I have not been very motivated to work on this project.  The lack of feedback makes me wonder if anybody is getting any value out of what I write.  I have been very busy in my Embedded systems consulting business. I have worked on it for over two years now.  I feel like I have hit two significant roadblocks.

I have decided to fight this lack of motivation.  There are a few things I do when I am struggling with motivation.  There is a song by Martina McBride called “Anyway”, I like to play it when I am feeling discouraged.  I also saw a couple of Ted talks by Brene’ Brown about vulnerability and shame that I like to revisit.  They remind me that the risks I take in putting my work out to the world have intrinsic value.

Vulnerability is the birthplace of innovation creativity and change. — Brene’ Brown

Man in the Arena

The Roadblocks:

Continue reading

Scope Probe loading

Merry Christmas and Happy New Year.  I hope your holidays are filled with friends and of course blinky things.


I posted on Espressif’s forum under bugs for a feature request. At the time that I write this post, there have been 26 views of the request.  I hope it gets enough interest that Espressif considers my request.


I soldered a 2 pin header into pins 1 and 2 of the programming connector. I then connected 3.3 Volts to Pin1.  I hooked up my Oscilloscope to pin 4 and immediately saw data on the line.  Pin 4 is attached to MISO.  This is great news, the data is getting through the level shifter.  Unfortunately, the waveform shows a lot of noise.  Then I switched to 5V and I saw data again, but the firmware crashed very quickly.  I started out by assuming the 5 Volts was the problem. So I tried setting it back to 3.3 Volts and the system wouldn’t reboot.  Then I disconnected the voltage supply and still not booting.  Finally, I disconnected my oscilloscope probe and it would boot again.


The MISO line brings the code from flash into the processor. Any glitch on it could cause crashes/failures.  It appears that the scope probe added to the output of the chip was enough to cause a glitch back on the MISO line.  This is disappointing, scope probes are very minimal loads.  Typically 10pF and 10MΩ on the circuit.  That is less than most devices that I would want to program.  This is going to take some more time to look at.  I need to test with a larger load, and maybe some pullups/pulldowns.  I am beginning to think a port expander might be a better choice. It’s still early to make that decision.


Continue reading

Easy SDK Upgrade


I started the upgrade to the newest version of the SDK.


Upgrading went pretty smoothly.  I had previously downloaded the newest SDK. So I made sure there wasn’t a newer version.  Next I extracted the SDK folder from the downloaded zip file.  I renamed the old folder to indicate it’s version number. I renamed the new SDK folder to Uprogrammer. I copied the code folder (Uprogrammer Firmware) from the old SDK folder into this new one.

Then I compiled (Success), Uploaded (also success after I copied esptools folder), and interacted with the application over serial (again success). Everything seemed to be going great.

Then I opened Eclipse… It didn’t find the project.  So I set my file manager to show hidden files.  I noticed the .metadata folder was not in the new directory. I copied it and still no joy.  I did this for all of the hidden files and it still didn’t work.  I then realized I must not have gotten the spelling of my folder correct.  I checked, the ‘p’ in the folder name needed to be capitalized.

Finally, I checked Git-Cola to see if it worked correctly.  It came up and showed me a bunch of untracked files that were generated by the build I had just done (another success).

This was a very easy upgrade.

The request:

Continue reading

Vpp Control Loop (Firmware V00M)


This week I decided to work on the control loop. I decided to add a simple adjustment scheme to the 5 mS system timer event. And then create a way to change the required voltage in increments of 0.1 Volts starting at 10.0


I created a local “static” variable in the events.c file for the target voltage. I then created a function to set this variable target_voltage and another function to get the value of target_voltage.  I then added a simple if statement into the 5ms event that increments the duty cycle of the Sigma Delta if the measured value is too low and decrements it otherwise.  I compiled and tried this, Vpp is ugly.

pic_42_3 Continue reading

ADC analysis (Firmware V00L)


I forgot to post last week.  If you read this regularly, I am sorry.

Espressif has released a Version 2.0 of it’s SDK.  I am not quite ready to upgrade to that yet, I will wait until after I get my basic functionality tested.  Also, this is a major release, they might have added a few bugs, I can wait till some are fixed.

Voltage Control loop:

I decided to work on the voltage control loop. First step, get a better understanding of the ADC.  I needed to know if the system calls to read the ADC are blocking or nonblocking. An ADC takes time to finish. If it returns the sample from the previous call, I will have to take a second reading to get the correct value.  If it is blocking, I don’t want to call it from within the interrupt service routine (ISR).

Note:  When you call a blocking function, it finishes it’s job before coming back.  Non blocking starts the job and then comes back.

The SDK API is not specific as whether the system_adc_read() is blocking or not.  So I set up a test. Pin 10 of the programming connector connects back to GPIO14.  If I set GPIO14 high before calling system_adc_read() and set it low before calling it again, I can tell how long the call takes. I created a system timer event in events.c and used it to read the adc.  The system timer just calls an os task so it isn’t like an ISR.  I created a function called adc_read.  I initialized a variable, set GPIO14 high, call system_adc_read() and set GPIO14 low. I then set up the function to enable the timer task, I called it init_adc_timer().  I called this from user_init().  The code built. I uploaded it. I hooked up my scope to Pin 10 of the target header.

I got nothing, I didn’t hook up Vtarget.  I decided it was easier to probe GPIO14 directly on the ESP-12F. The pin was always high.  I checked the pin configuration in user_main.c. Nothing wrong there. I found a copy/paste error in events.c  I had copied the line to change GPIO13 to low and changed it to GPIO14 to set it high but didn’t change the one to set it low.  I fixed this and tried again.  I got the pulses I was looking for on the Oscilloscope.  The high pulse width measured 96.2 μS.  This is much longer than I would put into an ISR.  If i polled this read regularly, It would cause a significant loss in performance.

The Next Step:

I decided to see if I could access the ADC directly through hardware registers.  I couldn’t find any clear documentation on the ADC registers.  In the API, there is also a function call system_adc_read_fast().  This one requires wifi to be turned off when called.  I decided to try it turning Wifi off and back on after around each read.  I modified the code to try this change. Now the pulse width is 21.8 μS. Unfortunately, the wifi disconnects when I disable it. This is a problem.  I tried leaving the wifi enabled and it works. 21.8 μS is longer than I would want in an ISR so I will call it from the os_timer function and use it to make adjustments.  If I call this every 5 mS, it will tie up the processor for about 1/2 of 1% of the time.  This doesn’t seem like a lot, but I want to get as much performance as I can when I am programming a target.  And this control loop will have to be running while programming a target.


The results of my testing are not as good as I had hoped.  Maybe Espressif will come out with a non-blocking way to use the ADC in the future. Ideally, I would call a function to start the conversion, and the system would call back to my function with the result. As a final step I display the menu with the adc reading once every 200 cycles (1 second).  I have uploaded these changes to github click the link in the right column to go check it out.

Do you have any experience with the ESP8266 adc?  Have you found a work around for the blocking call?