Monthly Archives: December 2016

Scope Probe loading

by

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

Update:

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.

Testing:

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.

Analysis:

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.

Holidays:

Continue reading →

Easy SDK Upgrade

by

Update:

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

Process:

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)

by

Plan:

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

Implementation:

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)

by

Update:

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.

Conclusion:

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?