Tag Archives: Eclipse

Unit Testing

by

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 →

Refactoring

by

Update:

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 →

Finishing cleanup Firmware V00

by

I decided that the code that interacts directly with the hardware registers can’t be rewritten to be much clearer to read. There should be a lot of commenting in the code explaining why the registers need to be set that way.  That is a big project and since I didn’t write most of that code, I don’t understand a lot of it.  I am choosing this week to just make sure this code is formatted in the Allman style and leave commenting for later.

I have now worked through all the .c and .h files in the project to made sure they are formatted in the Allman style. I decided to go back through all the names used for variables, functions, constants, and macros and format them all the same.  Since Espressif named all the system calls in lowercase underscore separated, system calls will follow that format.

The rest of the naming I decided as follows:

Macro: All caps with underscore separation followed by ()
DISPLAY_MENU()

Constant: All caps with underscore separation
USER_TASK_PRIO_0

Variable: Lower camel case
menuState

Non System functions: lower camel case with ()
getNewPassword()

I used Eclipse’ refactor feature to make these changes to all the files at once.

I had a couple of .h files that didn’t refactor correctly, but once i got those fixed, the code compiled and ran just like before.

The firmware is getting easier to maintain and edit.  I hope to move forward with the electronics design again soon.  I bought and received a new mixed signal oscilloscope and received it this last week, I plan on doing a review of it next week. I have uploaded these changes to Github, click the link in the right hand column to get the firmware source.

Have you used Eclipse’ refactor function before?  Did you have similar problems?

Firmware Stability with Voltage boost (Firmware V00H)

by

Since there seems to be some interplay between the SPI overlap mode and the Sigma Delta, I decided to disable the SPI RAM code to see if I can get the Voltage Boost working without crashes.  I used the // comment to make nullify the lines of code pertinent to the HSPI overlap mode.  Most IDEs let you select multiple lines and type CTRL-/ to comment out a block of code, and it toggles between commented and uncommented.

Note: IDE means Integrated Development Environment. Some IDEs are very advanced and checks if your code will compile while your are typing it in.  Others are just a simple editor with an integrated programmer/compiler.  In my case, I am using a program called Eclipse as my IDE.  It is very powerful as a code editor and I could automate compiling and uploading with it, but I have taken an easier path of making a few special shell files to automate the compiling/uploading process.

After commenting out the HSPI overlap code, I verified It would compile and run.  It compiled and ran. Good so far.  Next I started re-enabling the voltage boost circuit a little at a time. First, I turned of the FET allowing the current to flow into the boost circuit.  This is done by pulling GPIO16 low.  I did this by uncommenting two lines at the beginning of serial_init. (I also made a quick edit to a comment that was erroneous) I saved that and tried again. I measured Vpp at 2.75V.

The Sigma Delta Generator was set to a prescaler of 1 and duty of 0 from the last tests I had done.  Next I started changing the prescaler to see if the behavior has changed. 98 .. 99 .. 100 rst cause:2(Failure) Next I thought “maybe it’s the WiFi Modem”, So I disabled the modem.  I added the following three lines to the end of user_init()

    wifi_set_opmode(NULL_MODE);
    wifi_fpm_set_sleep_type (MODEM_SLEEP_T);
    wifi_fpm_open(); // force modem to sleep

98 .. 99.. 100 rst cause:2 (another failure)

Next I set GPIO16 to 1 in user_init() and commented it’s configuration out in seial_init(). Same result. Next I re-enabled system_set_os_print(). Maybe it’ll give me some useful message. No new messages came across the terminal emulator. I commented out the wifi_set_event_handler_cb() line. Still fails at 100.

So user_init() now:

sets the cpu frequency,
configures all the ports, including making sure all pins are disconnected from the sigma delta,
Initializes serial communications,
Initializes the Sigma Delta,
and disables the Modem.

cpu frequency is a system call,
Ports are just register writes,
serial communications are kinda of complex,
Sigma Delta is Just register writes,
and disabling the modem uses system calls.

This points to something in the serial communications.

Looking through the uart code, I noticed the ICACHE_FLASH_ATTR for uart_recvTask();  This is an ISR (interrupt service routine), and they shouldn’t reside in Flash, they should always be in ram.  I commented out the line and tried again. Again, same failure. I decided to sleep on it.

Moving forward, I continued to look at the serial communications code.  I decided to remove all the menu display code and just display the prescaler value with each keypress.  While making this change, I noticed that I had made a string buffer called outBuf of 32 bytes long. I used outBuf to format the Sigma Delta data before sending it out the serial port.  I counted it’s length, with a Duty of 0 and a Prescaler of 100 the terminating null character would be in position 35 of the buffer(That’s a buffer overrun).  I quickly shortened the string to leave the rest of the code intact and tried again.  And that solved it.

I re-enabled the menu.
Still working.

I re-enabled the boost voltage source.
Still working

Set the duty to  51(20%).
It is still working and I measured  2.72V at Vpp (2.72V doesn’t make sense)

Turns out I had both the Vpp drive and grounding transistors turned on causing the low voltage.  I set GPIO5 low and measured again with prescaler set to 4 and duty set to 102, I measured 22V on Vpp. Success!!!(little victory dance there)

I put a //TODO comment in my code to check everywhere I am using a string buffer for possibility of buffer overruns.

Putting a comment that starts with //TODO automatically adds it to a task list in the IDE. I can then go to the tasks list to see these notes. I now have stable but highly crippled code. I have uploaded the current state of the code to Github, click the firmware link in the right column to go get it or look at it.

When you are debugging do you have a technique that works especially well for you. Do you have a technique for finding buffer overruns? I would love to hear about your experiences.