Author Archives: teel9174

Learning Android Development using Big Nerd Ranch’s book

I have been contemplating learning Android development for a while now. I have dabbled in it in the past but never took a deep dive to create an application from scratch. I decided to go through a book from start to finish to see if that will give me what I need to finally take the dive.

Android Programming Book by Big Nerd Ranch

Link to the book on Amazon

The book is laid out really well and explains things much clearer than other books I have looked at over the years. I will say that Java development is still not much better than it was 20 years ago, at least on a Windows OS. I know some people will like to bash me for that comment but let me tell you about day one of working through the book and why Java still has a long way to go. (In retrospect after writing this, the blame is not really Java but the IDE. About 20 years ago, both were an issue but at least my issue is more to do with the IDE rather than Java.)

Installation of Android Studio seemed to go well. I got through the GeoQuiz example with no problems other than needing to use a physical device rather than the emulator due to Hyper-V being enabled on my system. I then worked on the challenge by copying the completed example and opening the copy. I made my changes and attempted to launch the application. I received an error that the apk could not be loaded or copied and a prompt was given to uninstall the apk with a warning that user data may be deleted. Since the application did not have associated user data, I clicked the button to uninstall the apk. Another error showed up in the log stating that the apk could not be copied or installation failed. (Sorry, I do not call the exact text.)

At this point, I assumed that the issue was with my device having the application installed from the sample so I decided to try the emulator. I was being a bit lazy so I clicked the link in the emulator selection to turn off Hyper-V. This change required a reboot so I let the PC reboot. On reboot, Windows 10 attempted to fix an error and stated that automatic repair failed to fix the issue. I attempted to turn Hyper-V back on from the command prompt but I was unable to do so from the Windows PE command prompt. I then decided to try turning off early anti-virus and the PC rebooted. Of course I was not happy about that especially since my AV software kept complaining that it could not reach the live-update site and other issues. Basically I had a mess to clean up. Once I finally got the OS squared away, I decided to go back to the challenge. Now Android Studio was having all kinds of issues. (All of these issues may be related to other attempts to boot back into Windows including restoring a previous restore point.)

I uninstalled Android Studio, deleted the files in the Program Files folder, rebooted, and reinstalled Android Studio. I was still having issues launching Android Studio. I finally found that I needed to delete the contents of the C:\Users\AppData\Local\Android\Sdk folder. I then needed to reinstall the SDK, emulator, and build tools. Once these were reinstalled, Android Studio behaved well as it did before. I attempted to run the application and the emulator launched so that was great news but I received the original error regarding the apk file.

I was at a loss but looked a bit more into the log file and it pointed me to a file in the C:\Users\Documents\AndroidStudioProjects\GeoQuiz – Challenge\app\build\intermediates\split-apk\debug\slices folder. I deleted all of the files in the folder but I still received the same message. This was getting quite frustrating so I decided to try deleting all of the files and folders in the C:\Users\Documents\AndroidStudioProjects\GeoQuiz – Challenge\app\build folder. I attempted to build and run the application again. Low and behold, this time the application launched in the emulator. Finally success.

With all of this said, I’m going to keep marching on. It is very frustrating to have the Android Studio behave this way but hopefully my rant here will help someone. If nothing else, it will serve as a reminder to myself what to do when this error occurs.

Here are some locations of note regarding where Android Studio places files. If you want to uninstall and reinstall Android Studio, you should uninstall, delete the following folders, and reinstall. (These may not be all of the locations but these are the ones I found.)

  • C:\Program Files\Android
  • C:\Program Files (x86)\Android
  • C:\Users\.android
  • C:\Users\.AndroidStudio3.1
  • C:\Users\.gradle
  • C:\Users\AppData\Local\Android

Pipboy 3000

OVERVIEW

My daughter wanted to cosplay as a character from Fallout 3 for Awesomecon 2018 in Washington D.C. We found Noe and Pedro Ruiz’s design on learn.adafruit.com 1 and decided to build it. She decided do this cosplay a few days before the event so it was going to be a challenge to complete it in time but we did it.

I thought getting the electronics in time was going to be the biggest challenge but the biggest challenge was reducing the time for the 3D prints. We started on Sunday and did not finish until Wednesday afternoon. (We did not print continuously so the overall print time was less but not by much.) Noe and Pedro have some tips on reducing print time and they worked in combination with tweaking the infill and layer height.

3D PRINTING

My 3D printer is the XYZprinting daVinci 1.0. The printer is a few years old now and is not the best 3D printer by far but it does a fair job. The printer only supports ABS fulfillment and XYZprinting filament cartridges. I have yet to take time to change the head to support PLA or hack the firmware so I can use other filaments. This limits me to the colors of filament that I may use in the printer. We looked for a brown or green filament to use for the Pipboy but did not find any to my daughter’s liking. We decided to print it in white and spray paint it. We found some metallic paint which seemed to work well. Additionally, we printed the screen visor in black and the LED diffuser in natural.

As a side note, I started using Simplify3D Slicing Software with the printer and it has made a world of difference with the print quality and control of the printer. The prints come out much closer to the designed measurements than the XYZprinting software could accomplish. The software gives more options than the XYZprinting software which really came in handy for this project. Noe and Pedro recommend removing some of the supports for the armband and base-main pieces. The XYZprinting software is all or nothing regarding supports but the Simplify3D software allowed me to remove some supports while leaving others in place.

HARDWARE

Noe and Pedro do a good job in the write-up but as with most build instructions, a few things are left out or are not clear. Here are a few notes that I made along the way but it is not a complete list as we were under a very restrict time constraint to get this project done. Unfortunately that means take notes and documenting issues was not a priority.

Additional Materials needed but not listed in the materials list in the overview.

  • Electronic Parts & Components
  • Tools & Supplies
    • (Optional) Hot Glue and Hot Glue Gun
    • Adhesive foam such as weatherstripping for doors and windows

Below are the connections to the 3.5″ LCD Shield that were used in our build.

PypBoy Function Pin Pin Function PypBoy
LED + 3V3 1 2 5V  
ENC A GPIO2 3 4 5V PB 1000C +
ENC B GPIO3 5 6 GND PB 1000C –
ROT 1 GPIO4 7 8 GPIO14 ENC SW
LED – GND 9 10 GPIO15  
ROT 2 GPIO17 11 12 GPIO18  
ROT 3 GPIO27 13 14 GND ROT –
ROT 4 GPIO22 15 16 GPIO23 ROT 5
  3V3 17 18 GPIO24  
  GPIO10 19 20 GND  
  GPIO9 21 22 GPIO25  
  GPIO11 23 24 GPIO8  
ENC – GND 25 26 GPIO7  

SOFTWARE

We made a few tweaks to the software but they were to change the map and display some different text on some screens and adding some missing code to change other displayed text. I plan to post those minor changes in a future post. The more major changes implemented were to get the pypboy program to launch on start and wire up the rotary encoder so we can safely shutdown the Raspberry Pi.

The shutdown code was modified from Inderpreet Singh’s code on Element14’s website2.

REFERENCES

  1. Noe and Pedro’s writeup on learn.adafruit.com: https://learn.adafruit.com/raspberry-pi-pipboy-3000
  2. Inderpreet Singh’s Shutdown Code on Element14’s site: https://www.element14.com/community/docs/DOC-78055/l/adding-a-shutdown-button-to-the-raspberry-pi-b

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

sample.ino

mylib.h

mylib.cpp

Working code demonstrating the solution

sample.ino

mylib.h

mylib.cpp

Glowforge

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.

test2(511);

testDataSheetSection9();

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.

001
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 linux.org 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

002
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.)

003
Options

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.

004
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

005
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

006
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

007
Almost Done

008
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 http://raspberrypi.stackexchange.com/questions/3627/is-there-an-i2c-library/4052 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.
adafruit_io_v0.1.0

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

Update

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 https://github.com/TeelSys/TeelSys_THL. 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.

Book1

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 adafruit.io 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.