Digispark kickstarter ATtiny85 & ICSP programming adapter
Posted: 17 Feb 2018, 18:56
Frank & I have been using this cheap & dependable ATtiny85 board for some time in various R/C projects, and as the Pro-Mini ICSP adapter was popular I thought I'd post my ATtiny85 adapter.
I've switched to the Digispark board where previously I've used the ICP07 Pic board, for the simple reason that the manufacturer has hiked the ICP07 price - they now cost three times as much as when I started using them in the RDT encoder, Tiny-6, Codamac, etc.
The ATtiny85 board comes with an inbuilt but unshrouded USB plug for simple USB programming via a special USB bootloader. This is bad with a capital B - the bootloader delay in this case is five full seconds! They come with 'blink' loaded (theres an LED on P1), and with the fuses set for 16mhz, but on power up, five seconds elapse (an eternity!) before blinking commences.
In any case theres little room in a Tiny85 to waste on unnecessary bootloaders!
I remove the redundant USB connector with a junior hacksaw, a couple of strokes of the permagrit block gets the edge of the board smooth, and then its programmed as usual using a USBASP via SPI.
Heres a before & after shot, with a PP3 for size reference - after the mod, they're really small, less than 3/4" square:
The internal pull-up resistors which are enabled when ports are configured using pinMode(buttonPin,INPUT_PULLUP); for example
have quite a high resistance compared to other chips (about 25k ohms) only so are only very weak pull-ups.
In the case of the Digispark board, P3 and P4 are the USB data connections, and both have some protection circuitry in the form of resistors & 3v6 zener diodes which the 25k internal pull-up cannot overcome. The result is that if P4 is configured as an input using say:
pinMode(4,INPUT_PULLUP);, when open-circuit, P4 will always read as a zero.
This affects only P4, P3 has an additional on-board pull-up resistor of 1.5k and so behaves as expected.
A further effect of this is that when used as analogue inputs, P3 and P4 are restricted to 3.6v max by the zener clamping diodes D1 & D2 - and the additional 1k pullup on P3 affects its linearity as an analogue input - see diagram. In the bottom two photos you can see how the unwanted protection circuitry can easily be removed, if required - physically remove the diode D1 with your thumb-nail, and D2 by pressing it sideways with a watchmakers screwdriver. The lead-free solder is very soft and they both break away quite easily with no need to cut tracks or drill PTH holes! This will remove all the USB protection circuitry around P3 and P4 and revert them to 'normal' ATTiny85 behaviour.
P1 has an on-board LED with a 1k resistor and whilst this doesnt affect its operation as an output, when configured as an input, obviously the resistor and led combination are working in opposition to the 25k pull-up and so needs to be taken into account. Its like the Nano's D13.
P5 is by default the chip reset input and needs a fuse reprogramming to change it to a digital I/O pin, after which, since its no longer a reset pin, the USBASP wont work and a high voltage programmer is subsequently necessary. So unless you're very keen, ignore P5 completely.
As supplied, P0 & P2 are the only 'clean' pins with nothing attached.
This is a great board, very handy for less complex projects, really cheap and so very small after sawing off the USB tab. It seems that some 'best practise' things are surfacing, these are just my own observations:
1) P0, P1 & P2 behave just as you would expect. P1 has the inbuilt LED so is handy as an indicator output like D13 on a larger Arduino.
If used as an input, the source should be low enough Z to overcome the LED/resistor combination.
2) P3 has an on-board 1.5k pull-up regardless of the pinMode setting you give it. Bear this in mind, its ideal as a 'button' input for example.
3) P4 will appear to ignore 'input_pullup' configuration and should be driven from a relatively strong source (Z less than say 10k) or used as an output
4) P5 is the reset pin, its not generally available as an I/O pin unless you do a fuse change and have a high-voltage programmer.
5) the USB bootloader is very clever but wastes 25% of the memory unnecessarily and takes a full 5 seconds before running your program. Ditch it!
6) ICSP works great with a USBASP using the adapter shown below, bypasses the troublesome bootloader and as you are not using
the USB tab it can be chopped off, leaving the board just under 3/4" square.
7) if the P3 & P4 weirdness is a concern, it can easily be resolved with a small mod as described here.
“De-fluffing” a DigiSpark:
As can be seen in the diagrams above, some of the DigiSpark pins have additional circuitry on the PCB which we need to remove as it affects the linearity when those pins are used for joystick inputs. Three pins are affected:
P1 has an LED with a series ballast resistor (R5) to ground, this distorts readings when used as an analogue input.
P3 has one of the two USB data connections and has a 1k5 pull-up resistor and a 3v6 zener diode (D1) to ground.
P4 has the other USB data connection and has a 3v6 zener diode (D2) to ground.
These components affect the linearity of the P1, P3 and P4 when used as analogue inputs and in the case of P3 and P4 actually limit the maximum voltage that can be read.
Luckily these unwanted additions are easily removed - but first to identify the culprits: (click to enlarge)
Remove the marked components using a jewellers screwdriver, they should easily flick away, but a stubborn component can be gently ‘chiselled’ to break it up. Remove either one of the two components nearest P3, the LED or its ballast resistor – I always go for whichever has the least solder.
Again, I stress, this is really easy to do and takes seconds, in fact D1 and R3 can be liberated with just your thumbnail! The final 'de-fluffing' is to saw off the USB tab. Dont worry, there are no traces or connections there to worry about, it can safely be removed altogether, flush with the edge of the board.
Heres the programming adapter - just two headers on a length of vero for the chip and the usual 6-pin USBASP header:
I later added an extra header pin on the neg rail, so my PPM tester plugs onto neg & port P0 (ppm), and also a resistive ground-lead for testing button inputs. This means the programming adapter doubles as a simple tester:
The board is a loose fit over the headers of course so a small sponge block under the top-left corner wedges the board at an angle and secures the connections.
One thing I have noticed is that although the clock speed is stable, its not precisely the same from one chip to another, at a nominal 16mhz some are very slightly over, some are very slightly under, but that hasnt been a problem as the variation is minimal and for anything 'timing critical' the clock can be tweaked in the software by setting 'OSCCAL'. Its because the RC clock is actually 4mhz multiplied up with a PLL
so any slight variations are multiplied four times.
Heres an RDT encoder made with this board (Remote Dethermalizer) for free-flight models, with a Futaba-style OrangeRx module for size:
Here is a Veroboard layout. Note that the USBASP header has cuts between adjacent holes, as does the 5v and 0v connector for the Attiny. The short blue link (negative) on the right and short red link (pos) on the far left can both be just a solder blob.
Cheers
Phil
The term "De-fluffing" © Ceptimus 2019
I've switched to the Digispark board where previously I've used the ICP07 Pic board, for the simple reason that the manufacturer has hiked the ICP07 price - they now cost three times as much as when I started using them in the RDT encoder, Tiny-6, Codamac, etc.
The ATtiny85 board comes with an inbuilt but unshrouded USB plug for simple USB programming via a special USB bootloader. This is bad with a capital B - the bootloader delay in this case is five full seconds! They come with 'blink' loaded (theres an LED on P1), and with the fuses set for 16mhz, but on power up, five seconds elapse (an eternity!) before blinking commences.
In any case theres little room in a Tiny85 to waste on unnecessary bootloaders!
I remove the redundant USB connector with a junior hacksaw, a couple of strokes of the permagrit block gets the edge of the board smooth, and then its programmed as usual using a USBASP via SPI.
Heres a before & after shot, with a PP3 for size reference - after the mod, they're really small, less than 3/4" square:
The internal pull-up resistors which are enabled when ports are configured using pinMode(buttonPin,INPUT_PULLUP); for example
have quite a high resistance compared to other chips (about 25k ohms) only so are only very weak pull-ups.
In the case of the Digispark board, P3 and P4 are the USB data connections, and both have some protection circuitry in the form of resistors & 3v6 zener diodes which the 25k internal pull-up cannot overcome. The result is that if P4 is configured as an input using say:
pinMode(4,INPUT_PULLUP);, when open-circuit, P4 will always read as a zero.
This affects only P4, P3 has an additional on-board pull-up resistor of 1.5k and so behaves as expected.
A further effect of this is that when used as analogue inputs, P3 and P4 are restricted to 3.6v max by the zener clamping diodes D1 & D2 - and the additional 1k pullup on P3 affects its linearity as an analogue input - see diagram. In the bottom two photos you can see how the unwanted protection circuitry can easily be removed, if required - physically remove the diode D1 with your thumb-nail, and D2 by pressing it sideways with a watchmakers screwdriver. The lead-free solder is very soft and they both break away quite easily with no need to cut tracks or drill PTH holes! This will remove all the USB protection circuitry around P3 and P4 and revert them to 'normal' ATTiny85 behaviour.
P1 has an on-board LED with a 1k resistor and whilst this doesnt affect its operation as an output, when configured as an input, obviously the resistor and led combination are working in opposition to the 25k pull-up and so needs to be taken into account. Its like the Nano's D13.
P5 is by default the chip reset input and needs a fuse reprogramming to change it to a digital I/O pin, after which, since its no longer a reset pin, the USBASP wont work and a high voltage programmer is subsequently necessary. So unless you're very keen, ignore P5 completely.
As supplied, P0 & P2 are the only 'clean' pins with nothing attached.
This is a great board, very handy for less complex projects, really cheap and so very small after sawing off the USB tab. It seems that some 'best practise' things are surfacing, these are just my own observations:
1) P0, P1 & P2 behave just as you would expect. P1 has the inbuilt LED so is handy as an indicator output like D13 on a larger Arduino.
If used as an input, the source should be low enough Z to overcome the LED/resistor combination.
2) P3 has an on-board 1.5k pull-up regardless of the pinMode setting you give it. Bear this in mind, its ideal as a 'button' input for example.
3) P4 will appear to ignore 'input_pullup' configuration and should be driven from a relatively strong source (Z less than say 10k) or used as an output
4) P5 is the reset pin, its not generally available as an I/O pin unless you do a fuse change and have a high-voltage programmer.
5) the USB bootloader is very clever but wastes 25% of the memory unnecessarily and takes a full 5 seconds before running your program. Ditch it!
6) ICSP works great with a USBASP using the adapter shown below, bypasses the troublesome bootloader and as you are not using
the USB tab it can be chopped off, leaving the board just under 3/4" square.
7) if the P3 & P4 weirdness is a concern, it can easily be resolved with a small mod as described here.
“De-fluffing” a DigiSpark:
As can be seen in the diagrams above, some of the DigiSpark pins have additional circuitry on the PCB which we need to remove as it affects the linearity when those pins are used for joystick inputs. Three pins are affected:
P1 has an LED with a series ballast resistor (R5) to ground, this distorts readings when used as an analogue input.
P3 has one of the two USB data connections and has a 1k5 pull-up resistor and a 3v6 zener diode (D1) to ground.
P4 has the other USB data connection and has a 3v6 zener diode (D2) to ground.
These components affect the linearity of the P1, P3 and P4 when used as analogue inputs and in the case of P3 and P4 actually limit the maximum voltage that can be read.
Luckily these unwanted additions are easily removed - but first to identify the culprits: (click to enlarge)
Remove the marked components using a jewellers screwdriver, they should easily flick away, but a stubborn component can be gently ‘chiselled’ to break it up. Remove either one of the two components nearest P3, the LED or its ballast resistor – I always go for whichever has the least solder.
Again, I stress, this is really easy to do and takes seconds, in fact D1 and R3 can be liberated with just your thumbnail! The final 'de-fluffing' is to saw off the USB tab. Dont worry, there are no traces or connections there to worry about, it can safely be removed altogether, flush with the edge of the board.
Heres the programming adapter - just two headers on a length of vero for the chip and the usual 6-pin USBASP header:
I later added an extra header pin on the neg rail, so my PPM tester plugs onto neg & port P0 (ppm), and also a resistive ground-lead for testing button inputs. This means the programming adapter doubles as a simple tester:
The board is a loose fit over the headers of course so a small sponge block under the top-left corner wedges the board at an angle and secures the connections.
One thing I have noticed is that although the clock speed is stable, its not precisely the same from one chip to another, at a nominal 16mhz some are very slightly over, some are very slightly under, but that hasnt been a problem as the variation is minimal and for anything 'timing critical' the clock can be tweaked in the software by setting 'OSCCAL'. Its because the RC clock is actually 4mhz multiplied up with a PLL
so any slight variations are multiplied four times.
Heres an RDT encoder made with this board (Remote Dethermalizer) for free-flight models, with a Futaba-style OrangeRx module for size:
Here is a Veroboard layout. Note that the USBASP header has cuts between adjacent holes, as does the 5v and 0v connector for the Attiny. The short blue link (negative) on the right and short red link (pos) on the far left can both be just a solder blob.
Cheers
Phil
The term "De-fluffing" © Ceptimus 2019