digispark:tutorials:programming
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
digispark:tutorials:programming [2013/08/20 08:06] gogol [Creating Digispark Compatible Clones] |
digispark:tutorials:programming [2016/06/09 12:03] (current) |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ======Beginners Guide to Extended Programming Attinys with Digispark====== | ======Beginners Guide to Extended Programming Attinys with Digispark====== | ||
| - | //**Preface**: As I am not an native english speaker, you are more than welcome, to fix any mistakes in grammar or spelling. It will help me, improving my foreign language skills. | + | //**Preface**: As I am not an native english speaker, you are more than welcome to fix any mistakes in grammar or spelling. It will help me improving my foreign language skills. |
| - | This page is meant, as an first overview over all digispark related hardware-programming methods. Its meant as a kind of landing page, where users can link from the forums.// | + | This page is meant as an first overview over all digispark related hardware-programming methods. It's meant as a kind of landing page where users can link from the forums.// |
| - | There are three ways, how you can write program code: ISP, HVSP, and Self-Programming. When you start playing around with an digispark, you are using the self-programming feature of the Attiny. | + | There are three ways you can store binary program code into an AVR controller: ISP, HVSP, and Self-Programming. When you start playing around with a digispark you are using the self-programming feature of the Attiny. |
| =====Self-Programming the Attiny – or the digispark way of life===== | =====Self-Programming the Attiny – or the digispark way of life===== | ||
| - | To enable that feature, you need to use one of the other two methods before, to get a piece of code on the attiny, which than would allow you, to pull additional code into the attiny or changing the additional code. Uploading that initial code is one of the tasks in the digispark-production. | + | To enable that feature you need to use one of the other two methods mentioned before to get a piece of code on the attiny. This will then allow you to pull additional code into the attiny or change the additional code. Uploading that initial code is one of the tasks in the digispark-production. |
| - | The code making this possible, is the [[https://github.com/Bluebie/micronucleus-t85|bootloader micronucleus]], written and maintained by the board-member bluebie. | + | The code making this possible is the [[https://github.com/Bluebie/micronucleus-t85|bootloader micronucleus]], which is written and maintained by the board-member bluebie. |
| - | This bootloader resides in the first 2k of the 8k memory of the attiny, and allows you, to use the remaing 6k for your programs. The big benefit of that piece of smart code ist that fact, that you need to other hardware tool for programming a digispark, like for the other two methods. It will even go one step ahead, and making it possible, that you can use the digispark, programming other core attinys in two (or lets say one and a half way). | + | This bootloader resides in the first 2k of the 8k memory of the attiny and allows you to use the remaining 6k for your programs. The big benefit of that piece of smart code is that you need no other hardware tool to program a digispark as you would for the other two methods. It will even go one step further and make it possible for you to use the digispark for programming other core attinys in two (or lets say one and a half) different ways. |
| - | For that purpose micronucleus emulates USB hardware, as the attiny has no on-board USB device. Communication is done with an host component, even called micronucleus, on Windows systems its for example //micronucleus.exe//. | + | For that purpose micronucleus emulates USB hardware as the attiny has no on-board USB device. Communication is done with a host component called micronucleus. On Windows systems it's //micronucleus.exe//. |
| - | To hide this special way programming the digispark, digistump has patched the IDE adding a own version of avrdude (that program, which is mostly used in the arduino-world). The avrdude of digistump is an wrapper, deciding to call either the original avrdude (for everything, which is not an digispark) or micronucleus in case of the digispark. | + | To facilitate this special way of programming the digispark, digistump has patched the IDE by adding a custom version of avrdude (a program which is mostly used in the arduino world). Digistump's custom version of avrdude is a wrapper which calls either the original avrdude for everything which is not a digispark, or micronucleus in the case of a digispark. |
| There are however some drawbacks: | There are however some drawbacks: | ||
| - | The emulation of an USB-interface has influence to 2 of the six pins of the attiny: Both are regulated with a Zener-diode, which limits the voltage on those two pins to a max of 3.6V, influencing some use cases like analogRead() or high-levels for digitalWrite(). One of those two pins has also an pullup-resistor connected, creating even more problems to this kind of usage. | + | The emulation of a USB interface affects the usage of 2 I/O pins, P3 (analog3) and P4 (analog2). Both are regulated with a Zener diode which limits the voltage on those two pins to a max of 3.6V. This affects some uses like analogRead() or high levels resulting from digitalWrite(). P3 also has a 1.5K pullup-resistor creating even more problems for this kind of usage. |
| - | The advantage of this solution is, that this way of programming the Attiny, makes the use of one more GPIO-pins possible, the pin PB5. This pin is used otherwise as reset, which is needed for programming the chip with one of the simple external ISP-programmers. | + | An advantage of the emulated USB solution is that this way of programming the Attiny frees one more GPIO pin; pin PB5. This pin is otherwise used as reset, which is needed for programming the chip with an external ISP programmer. |
| ====Small Introduction to pin-names==== | ====Small Introduction to pin-names==== | ||
| - | //You need to be very careful, when it comes to PIN names on the AVR microcontrollers. There are plenty of names around, depending of functions or locations. Further enumeration depends, if that is done logical or physical.// | + | //You need to be very careful, when it comes to PIN names on the AVR microcontrollers. There are plenty of names around depending on functions or locations. Further enumeration depends, if that is done logical or physical.// |
| - | //There are the pin numbers of the core chip, starting with one at the special marked pin gping counter-clockwise around the chip. Than there are the numbers of GPIO-pins, AVR groups those to internal ports, where up to 8 pins can be aggregated. Those ports are named with letters (A, B, ..). Unfortunately the attiny85 is missing the port A, so the GPIO pins are called PB0 to PB5. And as you see, in the logical enumeration they start with 0, and there is no match to the physical pin number. When it now comes down to the digispark itself, those 6 pins are named P0 to P5 on the PCB; however in the schematics enumeration starts with 1.// | + | //There are the pin numbers of the core chip, starting with one at the special marked pin going counter-clockwise around the chip. Then there are the numbers of GPIO-pins which AVR groups to internal ports, where up to 8 pins can be aggregated. Those ports are named with letters (A, B, ..). Unfortunately the attiny85 is missing port A, so the GPIO pins are called PB0 to PB5. And as you see, in the logical enumeration they start with 0 and there is no match to the physical pin number. When it comes down to the digispark itself, those 6 pins are named P0 to P5 on the PCB; however in the schematics enumeration starts with 1.// |
| - | //There are a lot of other names, depending of functions for special protocols or chip-functions, like SCK, MISO, MOSI. Those additional functions are even not related to corresponding GPIO-pins. On the attiny85 SCK is together with PB2 on physical pin7. On the attiny167 fo example SCK resides with PA5 on physical pin 8. So pay allways attention to documentation before making assumptions!// | + | //There are a lot of other names, depending of functions for special protocols or chip-functions, like SCK, MISO, MOSI. Those additional functions are even not related to corresponding GPIO-pins. On the attiny85 SCK is together with PB2 on physical pin7. On the attiny167, for example, SCK resides with PA5 on physical pin 8. So always pay attention to documentation before making assumptions!// |
| | | ||
| Its not much more to say, about the internal programming, as that is the out-of-the box behaviour. | Its not much more to say, about the internal programming, as that is the out-of-the box behaviour. | ||
| =====In-System Programming – The way most other attinys are loaded===== | =====In-System Programming – The way most other attinys are loaded===== | ||
| - | ISP was developed, to allow manufacturers programming of the chip, even when it is soldered on the final PCB. | + | In-circuit programing (ISP) was developed to allow manufacturers using the microcontroller chips to program them, even while soldered on the final PCB. |
| - | That is meant to have a cheap way, updating code to fix bugs or extend capabilities without unsoldering the chip. | + | That is meant to provide a cheap way to update code, to fix bugs, or to extend capabilities without unsoldering the chip. |
| - | There are however as well some restrictions to this mode too: SCK uses MISO, MOSI and SCK, and there is no influence on those three pins allowed. AVR recommends using resistors between the pin and the shared resource. | + | There are, however,some restrictions to this mode as well: ISP uses MISO, MOSI and SCK (as well as RESET), and there is limited interference with those three pins allowed. Atmel recommends using resistors between these ISP pins and their other uses in a circuit. |
| - | In general its a good recommendation, to read [[http://www.atmel.com/images/atmel-2521-avr-hardware-design-considerations_application-note_avr042.pdfAVRs | design considerations]]: | + | In general it's a good recommendation, to read [[http://www.atmel.com/images/atmel-2521-avr-hardware-design-considerations_application-note_avr042.pdfAVRs | design considerations]]: |
| - | As IS-Programming needs the enabled RESET function (and therefore disabled GPIO function of the shared physical pin), there is no way, to program an out-of-shelf digispark with any ISP device, because the digispark has disabled the reset function. | + | As ISP connection needs the enabled RESET function (and therefore disabled GPIO function of the shared physical pin), there is no way, to program an off-the-shelf digispark with any ISP device, because the digispark has disabled the reset function. |
| ===Interjection: Fuses=== | ===Interjection: Fuses=== | ||
| - | //Disabling the reset-function is something, you can do with either ISP or HVSP programming. A attiny-fuse has nothing to do, with fuses you know from electrical devices. Its one bit in a register of bits, which are stored independently in the attiny. Those registers control the behavior of the attiny, when the attiny starts. Some of those fuses and additional registers have an strong influence on the ways, to program an attiny or any other atmel device.// | + | //Disabling the reset-function is something, you can do with either ISP or HVSP programming. An attiny fuse has nothing to do, with fuses you know from electrical devices. It's a one bit in a register of bits, which are stored independently in the attiny. Those registers control the behavior of the attiny when the attiny starts. Some of those fuses and additional registers have an strong influence on the way to program an attiny or any other Atmel device.// |
| - | //There are three fuse bytes, which are controlling the behavior:// | + | //There are three fuse bytes which control the behavior:// |
| - | //The extended fuse byte, where bit number 0 controls, if self-programming is enabled or not. For the disgispark self-programming is disabled.// | + | //The extended fuse byte, where bit number 0 controls whether self-programming is enabled or not. For the disgispark self-programming is enabled.// |
| - | //The high fuse byte, where bit 7 controls, if external reset is disabled, bit 6 switches debug wire, bit 5 the capability of ISP// | + | //The high fuse byte, where bit 7 controls whether external reset is disabled, bit 6 switches debug wire, bit 5 the capability of ISP// |
| - | //The low fuse byte controls the clock settings. If the clock settings are not matching the expectation of preloaded bootloaders (like the micronucleus), the chip won’t start and therefore programming the core this way, is as well disabled.// | + | //The low fuse byte controls the clock settings. If the clock settings are don't match the expectation of a preloaded bootloader, like the micronucleus, the chip won’t start and therefore programming the core this way, is, as well, disabled.// |
| - | //Important is also the lock byte, where two bits control, if ISP and HVSP are allowed to change and/or verify flash and eeprom.// | + | //The lock byte is also important; two bits control whether ISP and HVSP are allowed to change and/or verify flash and eeprom.// |
| // If one of the lockbits is set, the chip needs to be erased (which will automatically reset the lockbits) before further programming. Erasing can only be done using HVSP but will not change the three fuse bytes.// | // If one of the lockbits is set, the chip needs to be erased (which will automatically reset the lockbits) before further programming. Erasing can only be done using HVSP but will not change the three fuse bytes.// | ||
| - | As the digispark cannot be programmed via ISP (at least not, without prior modification), the digispark itself however is allready and ISP programmer! All you need is the right connection between the digispark and the target device. | + | The digispark cannot be programmed via ISP (at least not without prior modification), but the digispark itself is already an ISP programmer! All you need is the right connection between the digispark and the target device. |
| - | Staying in the digispark world, we assume as an programming target an attiny85 chip. | + | Staying in the digispark world, we assume as a programming target another attiny85 chip. |
| - | There is another open source project out there, the [[http://littlewire.cc/|littlewire]] from Ihsan Kehriban, whom you can meet as well in the digispark forum, as both projects have more in common, as you will see very soon: | + | There is another open source project out there, the [[http://littlewire.cc/|littlewire]] from Ihsan Kehriban, whom you can meet as well in the digispark forum, as both projects have much in common, as you will see very soon: |
| - | Compare the schematics of both projects, and you will see, that both implementations share the same basics: They have both the zeners and the pull-up resistor for USB communication. They are now both using micronucleus as boot loader. | + | Compare the schematics of both projects, and you will see that both implementations share the same basics: They both have the zeners and the pull-up resistor for USB communication. They are now both using micronucleus as boot loader. |
| - | The difference is only, that the digispark has an voltage-regulator on board, to drive additional devices and made all GPIO pins available on the breakout, while the littlewire makes only MISO, MOSI, SCK and RESET together with +5V and GND available on an AVR compatible layout. | + | The difference is only that the digispark has a voltage-regulator on board to power the attiny85 and additional devices, and the digispark makes all GPIO pins available on the breakout, while the littlewire makes only MISO, MOSI, SCK and RESET together with +5V and GND available on an AVR compatible layout. |
| The most simple way, to use the digispark as an ISP is: | The most simple way, to use the digispark as an ISP is: | ||
| Line 134: | Line 134: | ||
| Further you need to be aware, that as soon, as you are uploading another arduino-sketch via USBtinyISP to that device, where you have before installed the micronucleus boot-loader, the bootloader is gone and replaced the the program, you uploaded after it! | Further you need to be aware, that as soon, as you are uploading another arduino-sketch via USBtinyISP to that device, where you have before installed the micronucleus boot-loader, the bootloader is gone and replaced the the program, you uploaded after it! | ||
| - | To use this chip in the digispark way, you have two possibilities: You can create either an adapter with the zener-diodes and the three resistors for example with an old USB-cable (following the schematics from littlewire or digispark)// | + | To use this chip in the digispark way, you have two possibilities: You can create either an adapter with the zener-diodes and the three resistors for example with an old USB-cable (following the schematics from littlewire or digispark) |
| - | {{:digispark:tutorials:zener-adapter.jpg?300|USB Adapter build from old mouse-cable}} | + | |
| + | {{ :digispark:tutorials:zener-adapter.jpg?300 |USB Adapter build from old mouse-cable}} | ||
| or you use an digispark and cut off the attiny with an sharp knife (which is a wonderful second life for an digispark, where the controller is already dead): | or you use an digispark and cut off the attiny with an sharp knife (which is a wonderful second life for an digispark, where the controller is already dead): | ||
| - | {{:digispark:tutorials:removed-attiny.jpg?300|Digispark with removed attiny}} | + | {{ :digispark:tutorials:removed-attiny.jpg?300 |Digispark with removed attiny}} |
| + | |||
| + | If you use now the digispark prototype shield kit with the 8pin socket you created before, you can plug the prepared chip into that device, and upload sketches using the digispark-programmer. That is the reason, why you should connect all six pins of the extension-shield, when you not are planning to build two of this kind of shields. | ||
| - | If you use now the digispark prototype shield kit with the 8pin socket you created before, you can plug the prepared chip into that device, and upload sketches using the digispark-programmer. That is the reason, why you should connect all six pins of the extension-shield, when you not are planning to build two of this kind of shields.\\ | ||
| After that you can take out the chip and place it in that application, where you need six pins of the attiny, without the influence of the zeners and the pullup resistor.\\ | After that you can take out the chip and place it in that application, where you need six pins of the attiny, without the influence of the zeners and the pullup resistor.\\ | ||
| + | One device with six lines connected and the attiny cut off on the digispark besides the digispark littlewire ISP | ||
| + | |||
| + | {{ :digispark:tutorials:both-devices.jpg?300 |}} | ||
| + | |||
| Once you have created your digispark, and plug it to your PC, you will realize, that it generates trouble with USB device recognition. This is caused by the fact, that there is only the bootloader installed and no program. The bootloader starts the chip, waits the usual 5 seconds for possible programming action and gives control to the non-existent program. That causes the digispark to run into reset. So you should upload a small sketch, like the start-sketch after installing the boot-loader. | Once you have created your digispark, and plug it to your PC, you will realize, that it generates trouble with USB device recognition. This is caused by the fact, that there is only the bootloader installed and no program. The bootloader starts the chip, waits the usual 5 seconds for possible programming action and gives control to the non-existent program. That causes the digispark to run into reset. So you should upload a small sketch, like the start-sketch after installing the boot-loader. | ||
| - | The procedure to create an full compatible digispark is: | + | ===The procedure to create an full compatible digispark is:=== |
| * Burn Bootloader with 5-pin option and using USBtinyISP as programmer | * Burn Bootloader with 5-pin option and using USBtinyISP as programmer | ||
| Line 152: | Line 159: | ||
| * When the on-board LED is blinking, go back to the USBtinyISP device, select the 6-pin board and upload the bootloader again (which will not upload, as it changes the reset-function in first step) | * When the on-board LED is blinking, go back to the USBtinyISP device, select the 6-pin board and upload the bootloader again (which will not upload, as it changes the reset-function in first step) | ||
| - | ===High Voltage Programming or how 12V rescue chips=== | + | ====High Voltage Serial Programming (HVSP) or How 12V Rescues Chips==== |
| - | Now comes the day, that you have accidently fused some chips with reset-disabled, before the bootloader was installed. Or you killed the bootloader, tried different clock-sources or whatever. In that case there is only one way: \\ | + | Now comes the day that you accidentally fused some chips with reset-disabled before the bootloader was installed. Or you killed the bootloader, tried different clock-sources, or whatever. In that case there is only one way to correct the problem; you will need to use high-voltage serial programming (HVSP). High voltage is 12 Volt, so there is no risk. The problem is however, that the protocol used for this kind of programming differs from SPI and makes HVSP-programmers more complicated. |
| - | The use of high-voltage programming. High voltage is 12Volt, so there is no risk. The problem is however, that the protocol used for this kind of programming differs from SPI and makes HVSP-programmers more complicated. | + | |
| - | But knowing, that you need HVSP only in cases, where you have locked the controller down, its again easy: The digispark is as well able, to unlock the doors. For that step follow the [[http://digistump.com/board/index.php/topic,1039.0.html|recipe of Fuse Resetting]] in the forum.\\ | + | |
| - | With this little extension to the digispark you are able to reset the fuses to values, where ISP and Self-programming is enabled again. | + | |
| + | You will only need HVSP in cases where you have locked the controller down, and the digispark is able to unlock these doors. Read [[http://digistump.com/board/index.php/topic,1039.0.html|recipe of Fuse Resetting]] in the forum for instructions on how to reset fuses. With this little extension to the digispark you will be able to reset the fuses to values where ISP and Self-Programming are once again enabled. | ||
| + | {{ :digispark:tutorials:fuse-resetter.jpg?300 |}} | ||
digispark/tutorials/programming.1377011200.txt.gz · Last modified: 2013/08/20 08:06 by gogol
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Noncommercial-Share Alike 3.0 Unported
