---

Group Assignment

Go to the group assignment page

Individual Assignment

This week I will be making an ISP (In-system programming) or in-circuit programmer.

I chose to do Brian's ISP. I chose it for its simplicity and cost as it is stripped down to a bare minimum of components.

Image from Brian's ISP's page

Image from Brian's ISP's page

The process will be split into phases: Milling, Stuffing/Populating, Debugging, Programming:

Milling

In this phase I will be using the following:

• Fab Modules
• Mach3
• The CNC

Fab Modules

- I started by downloading the Traces (1000 dpi) and Outline Cutout (1000 dpi) of the circuit provided in Brian's tutorial.

Image from Brian's ISP's page

Image from Brian's ISP's page

- At Fab Modules

I selected the option "image (.png)"

Image capture from my computer

I chose the image file

Image capture from my computer

Once the image is loaded, I selected "output format" and then "G-codes (.nc)"

Image capture from my computer

In Process, I selected "PCB traces (1/64)"

Image capture from my computer

Before calculating, I changed the cut depth to 0.05, half of the default value, as I was being a bit cautious.

Image capture from my computer

Then I pressed calculate

Image capture from my computer

After calculation, I proceeded with an inspection of the tool path to make sure that all traces were covered. By holding the left mouse button, I was able to move the image, and with the wheel button, I could zoom the image to better check the tool path.

Image capture from my computer

By holding the right mouse button, I was even able to see it from a different perspective.

Image capture from my computer

Lastly, I saved the file for the milling process.

Image capture from my computer

Image capture from my computer

For the outline, I followed the same steps as before, except I chose "PCB outline (1/32)" instead of traces.

Image capture from my computer

2- Mach3

I started preparing the CNC by milling a pocket the size of the blank PCB (76x50x1.5 mm).

Image capture from my computer

Milling the pocket

Photo of my CNC making a pocket for the blank PCB

Finished pocket

Photo of my CNC finishing the pocket

Gluing double-sided tape on the FR1 board

Back of the blank PCB

The end result is this.

Finishing the outside of the ISP

Milling the cutout of one of the ISPs

Photo of my CNC milling the cutout

Removing the PCB from the pocket.

Photo of the PCB being removed from the pocket

I used a blade and sandpaper to remove shavings left from the milling process.

Photo of the cleaned PCB

I removed the double-sided tape from the back of the PCB.

Photo of the back of the PCB

3- Stuffing

Based on the tutorial on Brian's ISP page, I started by creating a spreadsheet with the components and their positions.

Image capture from my computer

Image from Brian's ISP's page

BOM

After that, I proceeded to solder all components in place.

4- Pre-Debugging

I started with a visual inspection.

Photo of my semi-finished ISP

OK, I need to clean a bit more.

With the multimeter, I looked for shorts, especially between Vcc and GND, and nothing was detected.

Overall, the board seemed fine, so I proceeded with the programming.

---

5- Programming

In order to program the fabricated programmer, I made use of a piece of hardware called USBasp. On his website, Thomas Fischl describes it as:

"USBasp is a USB in-circuit programmer for Atmel AVR controllers. It simply consists of an ATMega88 or an ATMega8 and a couple of passive components. The programmer uses a firmware-only USB driver, no special USB controller is needed."

My old and faithful USBasp

You use it just like the USBtiny.

The header poking out of the transparent plastic cover is the "slow SCK" jumper: it lowers the programming clock so the USBasp can talk to chips running at a slow clock (below about 1.5 MHz). The USBasp I have does not detect speeds automatically, so you simply install the jumper to change speed modes. This is necessary, for example, when programming an ATtiny44 or 45 still running at its factory 1 MHz clock, while a faster chip like the AT90USB1286 can be programmed at the normal speed. The new firmware on these programmers can usually detect the speed of the chip automatically, like on the ones sold today on AliExpress for less than 2 dollars.

So going back to the software, under Ubuntu for Windows 10 (Windows Subsystem for Linux), I started by installing the programming environment with the command sudo apt-get install avrdude gcc-avr avr-libc make

Capture of my computer screen

With the prior command, the programs got downloaded.

Capture of my computer screen

I then downloaded the firmware source to a directory. Following that, I ran the command make

Capture of my computer screen

Using Sublime Text, I edited the Makefile and replaced the entry "PROGRAMMER ?= usbtiny" with "PROGRAMMER ?= usbasp".

As explained before, since I was making a USBtiny, I did not have a programmer other than the USBasp, so that's why I replaced the code with the one compatible with my device.

Capture of my computer screen

I then ran

make flash

Capture of my computer screen

But no success. So I ran lsusb to get the list of available USB devices.

And I got a message "unable to initialize libusb: -99"

Capture of my computer screen

After a quick search on Stack Overflow, I found out there is no support for USB in the Windows 10 Ubuntu shell yet! Argh!

Note: I haven't confirmed yet, but apparently in 2020, USB is supported in the Windows Subsystem for Linux, but it was not at the time I made these exercises.

Capture of my computer screen on Stack Overflow

Then I gave up on Ubuntu Bash for Windows 10 and ran a copy of Ubuntu under VMware Player. In Ubuntu, I ran:

sudo apt install avrdude gcc-avr avr-libc make

Capture of my computer screen

This time, after running lsusb, I could see that the device was present.

I ran

make

in order to compile the firmware.

Capture of my computer screen

I then ran

make flash

But again, I got an error message.

I realized that Brian's ISP has to have a jumper installed in order to program the ATtiny45, and yes, I forgot to solder the jumper.

The programmer needs to have the jumper soldered while programming and then have it removed afterwards.

That made me remove the shrink tube I had installed before.

Photo of my semi-finished ISP

So I did it!

And it works!

Capture of my computer screen

Next, I ran

make fuses

Capture of my computer screen

After having the firmware uploaded and fuses burned, my new ISP would not be recognized.

So back to debugging…

I ended up measuring each resistor value and replacing the ATtiny with a new one. With a multimeter, I found out that the R1 1K resistor was not working. I replaced it, and voilà! Board detected!!! Oh, also, I decided to install a USB connector I cut from an old cable, and after some washing, that's how it looks.

Photo of my tiny ISP without cover

Photo of my tiny ISP with cover and programming

Final command make rstdisbl

Capture of my computer screen

It worked! Now I remove the jumper!

Capture of my computer screen

It works! That is proved by the detection of the USBtiny by the Linux command lsusb as shown in the picture above and zoomed below:

Capture of my computer screen

6- Final Test

Not tired of changing platforms, I decided to test Windows. Here is a screenshot of how I load the driver for my USBasp. I use this very useful software that makes installing drivers on Windows 10 less traumatic.

To load the driver on Windows, I use the tool "Zadig_2.2.exe".

Capture of my computer screen

Here I show a recent screenshot that proves the USBtiny is detected under Windows. Since I did this exercise years ago, I do not have the driver installation procedure outlined for Windows, but I have shown its detection before on Linux as well as now on Windows.

Recent capture of my computer screen

After the driver installation, I tested burning my 3D printer board's firmware under Windows. The firmware I burned, as just outlined, was the firmware for a Printrboard I made years ago with the open-source plans.

In the terrible footage below, you can see this happening with the command avrdude -c usbtiny -p at90usb1286 -U flash:w:BootloaderHID.hex:i -U lfuse:w:0xDE:m -U hfuse:w:0xdb:m -U efuse:w:0xF0:m

To eliminate confusion about whether the fabricated USBtiny burns or not, let's dissect the code above:

1. The first part avrdude is the name of the program.
2. Then -c usbtiny defines the programmer name; "usbtiny" is the fabricated programmer name.
3. Next -p at90usb1286 is the target IC to be programmed, here the AT90USB1286 that is installed on my Printrboard.
4. -U flash:w:BootloaderHID.hex:i defines the name/location of the firmware to be loaded, in this case "BootloaderHID.hex".
5. -U lfuse:w:0xDE:m -U hfuse:w:0xdb:m -U efuse:w:0xF0:m is the part of the command that burns the fuses.

All of the above is shown in the terrible footage ;-) below.

All working!

← (Feb 19) Computer-controlled Cutting · all weeks · 3D Scanning and Printing (Mar 04) →

Related: Electronics Design, Embedded Programming