Author Archives: teel9174

Arduino delay(), millis(), etc. cause execution to halt in a library

I ran into an interesting issue yesterday while rewriting some Arduino code into a library. I figure out what was the issue but I’m not sure as to why. If someone reads this and can point me to the reason why this was an issue, please comment on this post. I would appreciate it.

PROBLEM STATEMENT (Observation): Adding any timing function in my library file would halt the execution. The time functions includes delay(), delayMicroseconds(), micros(), and millis().

ROOT CAUSE: The time function was being called in the constructor of the class. If the time function was moved to another method and called separately, the time function would work.

RESOLUTION: Modified the code to create the object, then make a call to a public method of the class. I used begin() as I have seen in other classes.

Problem code demonstrating the issue




Working code demonstrating the solution





My Glowforge finally arrived this week. I pre-ordered it in October 2015 so it took a little over two years of waiting to finally get it.

I designed and printed the obligatory escutcheon for the print button. I chose to name my Glowforge Scotty in honor of James Doohan. His character was my inspiration for becoming an engineer in the first place so I felt it was fitting.

The escutcheon after being printed.

The escutcheon after removing the tape covering.

A few thoughts on the Glowforge interface.
The interface and workflow will take a bit of getting use to but I think it will be fine once I’m more familiar with it. At first I was getting frustrated as I created a PNG image to scale. When I imported it, I thought it was too small until I realized the scale is in inches not mm. Once I realized my error, I looked for an option to change it but could not find one. I attempted to find a way to scale it to the correct size but there is no option to type in the size or view the exact measurement. It is necessary to guess what size it is by looking at the ruler on the screen which is not very accurate. What I ended up doing was using the 1:1 scale printout and placing it in the Glowforge so I could attempt to scale it correctly. Once I did that, I could not figure out how to do cuts where I wanted them. I did some reading and found that an SVG is needed for cuts. I then used Inkscape to create an SVG from a modified image with only the cuts. This worked and I was able to scale it exactly. I then created another PNG file with just the engraving and uploaded both files. I still needed to scale the engraving but that was easy and not critical. Once everything looked good, I pressed the print button. The Glowforge performed the cuts but not the engraving. I then removed the cut image and clicked print again. This time the engraving was done. On my next print, I will need to see what I did wrong here so I do not make that mistake again.

Overall it was easy to use the Glowforge but I do have a few concerns. Firstly, a desktop application to prepare the print would afford a better setup experience. Secondly, it is not possible to print if your network connection is down for any reason or if Glowforge goes out of business. While it is nice to use a device this way, it does leave users vulnerable to the existence of the company and the health of the web servers.

The original PNG file I created.

A modified PNG for the cuts. This file could not be used for the cuts as PNG files may only be used for engraving. I needed to convert this file to SVG using Inkscape.

The modified PNG for the engraving.

Overall, I’m pleased with the Glowforge. I just hope that the company and the web-service run well for many years to come so I may continue to use the Glowforge.

BTW: The size of the escutcheon is 119.903 x 119.903 mm. I was not able to upload the SVG for the cuts so if you decide to use the PNG, you will need to convert it to SVG and resize it.

All Electronics LCD-101 (256×128 LCD) with Arduino

All Electronics has a rather large LCD display which will work great in a Jeopardy! like game that I am building. The display should be rather easy to use with an Arduino or Raspberry Pi but searching for Arduino or Raspberry Pi projects using the display turns up very few details. Fortunately the SED1330F datasheet is fairly well written. With some experimentation, it is possible to figure out how to get it to work. Especially helpful is table 32 in section 9.1.2. Some of the parameters need to be changed but it is a great example of how to get the display to work.

Here is a very short video of the LCD running from an Arduino UNO. The video starts with the display showing the result from the test2 function from the sample code below. I then upload the code again with the test2 function call commented out and the testDataSheetSection9 function call uncommented.



I plan to post more information as the project progresses. I do want to mention a few things that I found out in regards to the display.

  • You may wonder if the HG25504 is single or dual-panel display. It is a one panel display. This becomes obvious when you look at the ICs on the back of the display. The columns are driven by four HD66204FC Dot Matrix LCD column driver with 80-channels. If each column was used on these chips, they could drive 320 columns. This is 64 more columns than the display has but no where near 512 columns which would be required for a dual-panel configuration.
  • Included ICs and function
    • HD66204FC (Qty 4) Dot Matrix LCD column driver with 80-channels
    • HD66205FC (Qty 2) Dot Matrix LCD common driver with 80-channels
    • SED1330F (Qty 1) LCD Controller
    • HY6264A (Qty 1) Static RAM (8K bytes)
    • KA324D (Qty 1) Quad Operational Amplifier
  • Vo (LCD Contrast Voltage) – You really do need to apply at least -10V to Vo in respect to ground. There are some posts regarding this display stating that tying it to ground is enough but it is not. I had applied a negative voltage but was only seeing something when Vo was near ground potential. I was able to initialize the LCD but could not see anything displayed. I knew the screen was initialized because with Vo being close to ground potential, I saw one or more lines on the LCD when it was initially powered up. When I initialized the LCD, the line(s) were gone. I was getting frustrated as I could not display anything on the screen after initializing it. When I finally used a different power supply, I could see that I had been doing things right.
  • Power Requirements (You may have different results)
    • LCD Contrast (-10.5VDC @ 3.5mA)
    • LCD Logic (5VDC @ 10mA)
    • Arduino Uno (5VDC @ 10mA
  • The SED1330F supports 8080 and 6800 family processors. This matters as the LCD is wired for one or the other and the control lines change function based on the wiring of the LCD. Section 2.4.3 of the datasheet specifies that SEL1 and SEL2 determine the operation. Both SEL1 and SEL2 are connected to ground on the LCD therefore it is operating in 8080 mode.

CNC Machine

I have had a MyDIYCNC Machine sitting around for a few years now. I was having some problems with the controller boards so I set it aside and am just getting back to take another look at it. I found that one of the boards that was sent to me was indeed bad but MyDIYCNC no longer sells machines or parts. I then decided to go to Amazon and pick out a controller board to try. I picked the SainSmart CNC TB6560 3 Axis Stepper Motor Driver Controller Board & Cable. This board seems to work quite well. I have been having a bit of a time getting it to work properly in LinuxCNC but I have got it to home and move but it seems to be at 1/2 scale. I am still tweaking with the settings to see if I can get it to work 100%.

A few notes about wiring and hardware. The MyDIYCNC instructions refer to the motor which moves the Z axis carrier as the Y axis. It appears that it should really be the X axis and the table should be the Y axis. If it were the Y axis, the home position would be in the wrong corner of the machine. I played with the configuration a bit to see if I could get it to work as expected but I had no luck. Finally when I decided to try to swap the X and Y axes did home line up in the correct corner. I could have swapped A & B around on the Y motor and that may have reversed the direction of the motor but I did not want to go there. Swapping the axes made the most sense.

Here is a short video of a test of the CNC. The spindle has a ink cartage in it and is simply running the default LinuxCNC project. The drawing should be 5.3 inches wide but is only half that size.

Here are the settings for LinuxCNC.

Base Information

  • Machine Name: MyDIYCNC_inches
  • Axis configuration: XYZ
  • Reset Default machine units: Inch
  • Driver type: Other
  • Driver Timing Settings (The Stepper Drive Timing page on states that 150,000 ns should be used for all values however the current version of LinuxCNC has a max value of 100,000.)
    • Step Time: 100000
    • Step Space: 100000
    • Direction Hold: 100000
    • Direction Setup: 100000
  • Base Period Maximum Jitter: 9000

Parallel Port 1

  • Outputs (PC to Mill):
    • Pin 1: Amplifier Enable (Invert)
    • Pin 2: X Step
    • Pin 3: X Direction
    • Pin 4: Y Step
    • Pin 5: Y Direction
    • Pin 6: Z Step
    • Pin 7: Z Direction
    • Pin 8: Unused
    • Pin 9: Unused
    • Pin 14: Spindle ON (Invert)
    • Pin 16: Unused
    • Pin 17: Unused
  • Inputs (Mill to PC):
    • Pin 10: Both Limit + Home X (Invert)
    • Pin 11: Both Limit + Home Y (Invert)
    • Pin 12: Both Limit + Home Z (Invert)
    • Pin 13: ESTOP In
    • Pin 15: Unused
  • Parport Base Address: 0
  • Output pinout presets: Sherline (The value here is not important. It is actually used with the “Preset” button to load values.)


Selections here really do not matter. I have not figured out how to use these yet. I may look into it more in the future.

Axis X

  • Motor steps per revolution: 800 (Steppers included with MyDIYCNC are 50 steps per revolution. The TB6560 board has the switches set for 1/16 microstepping. 50 x 16 = 800)
  • Driver Microstepping: 2.0 (Someone posted that 2 meant that microsteping was being used. I had this set to 32 earlier.)
  • Pulley teeth (Motor:Leadscrew): 1.0:1.0 (All axes are direct drive so they are all 1:1.)
  • Leadscrew Pitch: 20.0
  • Maximum Velocity: 0.4
  • Maximum Acceleration: 30.0
  • Home location: 0.125 This took awhile to get. If using the limit switches as home switches as well, we need to back the machine off so that the limit switches are not active when at home position. I choose to back them off 1/8 inch on all axes.)
  • Table travel: 0.0 to 5.5
  • Home Switch Location: 0.0
  • Home Search velocity: -0.05
  • Home Latch direction: Same

Axis Y

  • Motor steps per revolution: 800
  • Driver Microstepping: 2.0
  • Pulley teeth (Motor:Leadscrew): 1.0:1.0
  • Leadscrew Pitch: 20.0
  • Maximum Velocity: 0.4
  • Maximum Acceleration: 30.0
  • Home location: 0.125
  • Table travel: 0.0 to 8.0
  • Home Switch Location: 0.0
  • Home Search velocity: -0.05
  • Home Latch direction: Same

Axis Z

  • Motor steps per revolution: 800
  • Driver Microstepping: 2.0
  • Pulley teeth (Motor:Leadscrew): 1.0:1.0
  • Leadscrew Pitch: 20.0
  • Maximum Velocity: 0.4
  • Maximum Acceleration: 30.0
  • Home location: -0.125
  • Table travel: -4.0 to 0.0
  • Home Switch Location: 0.0
  • Home Search velocity: 0.05
  • Home Latch direction: Same

Almost Done

Do you want to quit?

Screenshot added for completeness

I plan to continue to look into what is going on with the scaling and settle on the correct settings or at least settings which will work.

Test Video

I would like to add more videos to the blog. One of the problems that I have had is the time it takes to perform post processing on videos to add different sources and information. I found the Open Broadcaster Software application and started messing around with it and found that it is quite good, once you get use to how it works. Here is my first attempt at creating a video with the software.

BTW: Yes, I totally ripped off some ideas from Adafruit. I’m not too creative so I copied what I like. I will attempt to change it but it is tough as Limor and Phil have created a very nice format for the shows that Adafruit produces. I also like Ben Heck and Dave Jones (EEVBlog) videos as well but I seem to watch more of the videos Adafruit puts out.

Here is my first recording.

I2C Communications between Raspberry Pi and Arduino – Update

Over the past few days, I have been able to bit bang the I2C bus with the PIGPIO library. I found a very helpful example at which was posted by crj11. This example was using the pigpiod_if.h library. This worked well but required the application to be run with elevated privileges (sudo) which was not acceptable as I needed to run the application from a Python script which in turn was running every 5 minutes from a cron job. The final solution was to use the pigpiod_if2.h and run the pigpio daemon on startup.

The final solution has been running for a few days with three sensors connected over a total of 9 feet (~3 meters) of cable. The data has been logged at Adafruit.IO which I have made public. I may remove or rename the Dashboard in the near future so here is a screenshot of the page.

I have also updated the GitHub site for the project so there are now two releases available. Version RC_0.0.1 is the version using the hardware for I2C control and version RC_0.1.0 is the bit bang version.

I still have more work to do to make this project valuable to others. I plan to create some better documentation on the project and provide a full write-up to allow someone to follow along and build there own from start to finish. Right now, 80% to 90% is captured in various places but there are obvious gaps such as the connection to the Raspberry Pi. One can figure this missing information out by looking through the right source files and piece it together however I do not like it when I find a project write-up that is only 80% to 90% documented. It is still better than nothing or only 10% to 25% though.

I hope someone will find some of the information here useful.

Sensor with one cable connected

I2C Communications between Raspberry Pi and Arduino – Update, BOM, and Source Control


I have been working on this project over the past couple of weeks when I have free time but have not been posting updates. This is a general update which is why the title is different from the other posts regarding this project.

My boards from OSH Park arrived last week. I was able to populate them and test them out. Fortunately I did not make any errors on the PCB or schematic so they all worked as designed. There are a few things that I would change on a future version if I choose to make another version of the board.

  1. I would put the ICSP header on the bottom of the board so it does not stick out from the front. This would make it much easier to assemble and would make it possible to not have any exposed circuitry which may allow the device to be damaged from static electricity.
  2. I would move the resistors toward the bottom of the board if possible. It would allow the DHT11 sensor to stick out further from the case.
  3. I would also try to push the ATtiny85 a little further towards the bottom for the same reason as the resistors.

Currently I am looking to bit bang the I2C bus on the Raspberry Pi. I seem to have gotten around the clock stretching issue if there is only one device connected to the I2C bus but as soon as I add another device, the clock stretching becomes an issue again. I really wish that the Pi Foundation would work with Broadcom and fix the issue with the I2C bus.

Here are some pictures.

This slideshow requires JavaScript.

Bill of Materials (BOM)

Materials List (For One Sensor)

  • QTY 1 – PCB (Source: OSH Park)
  • QTY 2 – 3.5mm 4 Pole Audio Jack, J1 & J2 (Source: MCM Electronics NOTE: I ordered 27-9485 but received ones which look like 27-9487)
  • QTY 1 – 2×3 Position Male Header 2.54mm Pitch, JP1 (Source: MCM Electronics NOTE: This is a 2×13 header. You will need to cut it for 2×3 header.)
  • QTY 1 – T-1 3mm LED, LED1 (Source: MCM Electronics NOTE: May choose another color)
  • QTY 1 – CDS Photoresistor Photoelectric 5549 GL5549, PH1 (Source: Ebay)
  • QTY 2 – Resistor 1/4W 10K Ohm, R1 & R2 (Source: MCM Electronics)
  • QTY 1 – Resistor 1/4W 220 Ohm, R3 (Source: MCM Electronics)
  • QTY 1 – DHT11 Digital Temperature & Humidity Sensor Moudle, SE1 (Source: Ebay)
  • QTY 1 – ATMEL ATtiny85, U1 (Source: Newark)

Materials List for Raspberry Pi Hat

  • Qty 1 – Perfboard (Source: Adafruit)
  • Qty 1 – GPIO Header for Raspberry Pi NOTE: The one you will need depends on which model of Raspberry Pi you are using. (Source: Adafruit 2×13 Header for original Raspberry Pi or 2×20 Header for newer Raspberry Pi)
  • QTY 1 – 3.5mm 4 Pole Audio Jack (Source: MCM Electronics NOTE: I ordered 27-9485 but received ones which look like 27-9487)
  • Optional items

Source Control

I have added the source files for the Hardware and Software onto GitHub. I did this so the community may have access to the files and any updates to them. I mainly did it because I was having a hard time remembering which set of files I last worked with especially if a few days went by when I could not work on the project. I think this is a win-win for me and anyone interested in this project.

The files are located at When you first go to the page, it may look like there are mo project files included in the project. If that is the case it is because I am still trying to get everything working properly before I commit code to the master branch. You will see a button with the text “Branch: master” and a downward arrow. Click that button and select another branch such as “dev”. You will then see the project files in their current state.

If you wish to contribute, add a comment here or if you can request through GitHub, do that. I will reply once I see the request but keep in mind that it may be a few days.

I2C Communications between Raspberry Pi and Arduino – Part Four

It has been two weeks since my last post but it has been out of frustration on porting the code over to the ATtiny85. The first thing that I ran into was that the Wire library is not supported on the ATtiny85. I needed to modify my code to work with the TinyWireS library. This did not seem too bad and worked once in a while. It was a bit frustrating as I followed examples and it appeared that I was doing everything correctly but that is typically how it goes when coding.

I finally took a look at the specs for the ATtiny85 and realized that memory may be my issue so I started to pare down the memory requirements. The Arduino IDE was not complaining but I recalled an posting that was published on Adafruit a couple of years ago called Arduino Memories. After rereading the article and looking at a couple of other references, I determined that I needed to tackle the memory is see if it was an issue.

At some point in my debugging, I had noticed that the examples for TinyWireS were utilizing a buffer and pointer method to do fast reads and writes. I had a significant switch statement on the request data handler so I removed that and went with the buffer option. By doing so I reserved a whopping 256 bytes for the buffer. This was a very stupid move which I realized when I took a look at the specs for the the ATtiny85. The ATtiny85 has only 512 bytes of RAM so I was consuming half of it for the buffer which did not leave much room for anything else.

I dropped the buffer size down to 32 bytes which helped a great deal. After reducing the size of the buffer, I could get communications between the ATtiny85 and the Raspberry Pi to work a few times before the communications stopped working. I further refined the code to reduce memory usage and swapped out the Adafruit DHT library for one written by Rob Tillaart for the DHT11 only.


With these modifications, I was able to get the code down to using 113 bytes of RAM and 4,918 bytes (60%) of Flash.

With these changes, the code works quite well but sometimes it appears that the ATtiny85 does not read the correct request from the Raspberry Pi. After some searching it was found that there is a known issue with the Raspberry Pi and clock stretching. It appears that there is a bug which has not been fixed yet if the slave stretches the clock at the right moment and the stretching is too short. The ATtiny85 implements I2C in software so this is going to happen at some point.One of the best articles on this issue is the Raspberry Pi I2C clock-stretching bug.

There are some suggested fixes which I need to read more to understand well enough to use. The most promising fix appears to use Python to perform I2C communication in software. The recommendation is to use the PiGPIO library.

Below is the code that I have thus far on the ATtiny85.

Here is the code on the Raspberry Pi to verify that things are working.

Running the Raspberry Pi program produces the following result.


Next step is to see if I can resolve the clock stretching issue and then connect to to post data. If it is not possible to address the clock stretching issue, it would be possible to identify when it occurs and reset the power to the I2C slave devices. I am trying to avoid that solution but I may need to resort to that solution.

I2C Communications between Raspberry Pi and Arduino – Part Three

Today’s goal is to send a string from the Arduino to the Raspberry Pi. The setup is the same as from day two.

After several attempts and stupid mistakes, I was finally able to get a “Hello World” message from the Arduino to the Raspberry Pi.

Here is the code for the Arduino

Here is the code for the Raspberry Pi

Compile the code
gcc testi2c03.c -o testi2c03

Run the code
./testi2c03 254

We can see that once the string ends, the data on the I2C buss is 255. Let’s tweak the code on the Raspberry Pi to stop once we receive 255.

Compile the code
gcc testi2c03b.c -o testi2c03b

Then run the application
./testi2c03b 254

We can see that the output is now cleaner.

Let’s do even better and print the string as a string instead of a list of characters.

Compile the code
gcc testi2c03c.c -o testi2c03c

Then run the application
./testi2c03c 1 2 3 254 250 251

Yes, I included additional arguments this time. The code was setup to handle this which is really nice. This allows us to teak the code if we like to print out what the values actually are and get some additional information. So let’s create a new application which will do exactly that but will not take in any arguments. I am also going to add a few other things such as detecting if we are using a Raspberry Pi Rev 1 or Rev 2 as well as scanning the I2C Bus.

I was doing some searching on valid I2C addresses and found a great reference article from Total  Phase at 7-bit, 8-bit, and 10-bit I2C Slave Addressing. The article provides a diagram showing the valid range of 7-bit I2C addresses.


From this diagram, we can see that the address used in the examples is a reserved address. I will change the address in the Arduino code so that it is in the valid address range.

Here is a modified version of the code which finds all connected I2C devices. Determines which ones are the sensors that we are interested in, and reads values from each one. This will be a great program for making certain that the design works and all of the sensors are working.

Arduino Code

Raspberry Pi Code


Compiling the Raspberry Pi code is a bit different as we need to link the math library. In order to do this, we need to add -lm to the command line.

gcc testi2c03d.c -o testi2c03d -lm


Here is the results of running the application.


The passing of a string was successful however there are several standards which may be better suited to the goal that I have in mind. One worth further consideration is the System Management Bus (SMBus). For the moment, I am leaving the code as is since the information that I need to send may be sent as simple integer responses. A future enhancement will be to get a better messaging system in place.

The next step is to replace the Arduino with a ATTiny85 and get it all working.

I2C Communications between Raspberry Pi and Arduino – Part Two

The goal of the day is to get the Raspberry Pi and Arduino talking to each other over I2C.

I followed a few examples provided on the internet and was able to get the two to talk to each other. Just to be clear, the Raspberry Pi will be the I2C master and the Arduino will be the slave. One of the nice advantages to this configuration is that it is not necessary to do any voltage level shifting between the two devices. If you are not aware, the Raspberry Pi GPIO is at 3.3V and the Arduino is at 5V. If the Arduino were to supply 5V to any of the Raspberry Pi’s GPIO pins, the Raspberry Pi will be toast.

I followed the tutorial at Below are some of the high level steps.

  1. Download the latest Raspbian image from
  2. Unzip the file and write the image to the SD Card using Win32DiskImager from
  3. Once the Raspberry Pi boots, open a terminal window and run raspi-config to enable I2C Support
    sudo raspiconfig
  4. Select “Advanced Options” from the menu
  5. Select “I2C” from the Advanced Options menu
    Select “Yes”
    Select “OK”
    Select “Yes”
    Select “OK”
    ”Select “Finish”
  6. Install i2c-tools
    sudo apt-get update
    sudo apt-get install i2c-tools
  7. Run i2cdetect to make certain that i2c-tools installed properly
    i2cdetect –y 0
    i2cdetect –y 1
    If all worked well, you will see the following output
    If there are devices connected to the I2C pins, you will see the devices listed as in this example.
  8. Wire up the Arduino and Raspberry Pi
    Raspberry PI        Arduino
    GPIO 0 (SDA)    <–>    Pin 4 (SDA)
    GPIO 1 (SCL)    <–>    Pin 5 (SCL)
    Ground    <–>    Ground
  9. Upload Code to the Arduino
  10. Write the application on the Raspberry Pi
    nano testi2c02.c
  11. Type of copy paste the following code
  12. Save the file by pressing <Ctrl> + o

  13. Exit the editor by pressing <Ctrl> + x
  14. Compile the application
    gcc testi2c02.c -o testi2c02
    If you do see errors, go back and edit the file to correct them.
    Once the changes are made, recompile and if you do not see any error messages, you are good to go.
  15. Run the application
    ./testi2c02 1 {Gets the temperature in Celsius}
    ./testi2c02 2 {Gets the relative humidity in percent}

    ./testi2c02 3 {Gets the light level}

    ./testi2c02 4 {Turns the LED On}

    ./testi2c02 5 {Turns the LED Off}

    ./testi2c02 6 {Flashes the LED when reading sensors. This is the default behavior of the LED}

    ./testi2c02 7 {Echos the number 7. This may be repeated with any other number up to 255}


That’s all for the day. Next I plan to try to send strings and develop a format for messages.