I have an Ice Tube clock that I received as a gift over a year ago last Christmas. I finally got around (this year) to building it and I have it going now - and I love it.
However, I use it at work and because I'm concerned about it 'disappearing' I usually unplug it when I leave work and lock it up. That means it is unpowered for about 14 hours or so. I have found that my battery is now no longer holding up the time. At each power-up I have to reset the date and time.
So, I'm just wondering, do you think this is because I have it unplugged too long or could it be because the battery was already quite old?
I read with interest Jarchie's comments about the software and hardware mods to improve battery life and I might pursue that but I was just wondering on a stock clock with me unplugging it each day, is this going to cause dramatically shortened battery life?
Thanks for sharing your thoughts on this.
Jerry
Ice Tube Clock - Battery Life
Moderators: adafruit_support_bill, adafruit
Please be positive and constructive with your questions and comments.
- adafruit_support_bill
- Posts: 88092
- Joined: Sat Feb 07, 2009 10:11 am
Re: Ice Tube Clock - Battery Life
It could be a combination of the two, but probably more of the former. These batteries don't have tremendous capacity and the intent of the design was just to maintain the time through the occasional blackout.do you think this is because I have it unplugged too long or could it be because the battery was already quite old?
- phild13
- Posts: 247
- Joined: Mon Sep 10, 2012 1:05 pm
Re: Ice Tube Clock - Battery Life
If you are going to lock it up an a regular basis, then I would suggest that you use Johns firmware for the clock. It will enable the battery to last much longer.
- terranjerry
- Posts: 38
- Joined: Tue Feb 11, 2014 1:39 pm
Re: Ice Tube Clock - Battery Life
Ok, thanks guys for the recommendations. I know it's dumb to have to lock it up each evening but I really like the clock, put in a fair effort to make it really clean in my construction and since AF doesn't sell it anymore :( I want to protect my investment. I think Phil's recommendation is a good one - I'll just try to add the mods that reduce the battery drain.... either that or I'll buy stock in a battery company! :) Thanks again for the kind replies,
Jerry
Jerry
- adafruit_support_bill
- Posts: 88092
- Joined: Sat Feb 07, 2009 10:11 am
Re: Ice Tube Clock - Battery Life
Phil's advice is good. JArchie's firmware should conserve your battery power better than the standard firmware.
The Ice Tube was one of my favorite kits. It is a shame we had to discontinue it. But the supply of NOS VFD tubes is rapidly drying up and it is impossible to source them in reasonable quantities anymore. :(
The Ice Tube was one of my favorite kits. It is a shame we had to discontinue it. But the supply of NOS VFD tubes is rapidly drying up and it is impossible to source them in reasonable quantities anymore. :(
- terranjerry
- Posts: 38
- Joined: Tue Feb 11, 2014 1:39 pm
Re: Ice Tube Clock - Battery Life
Bill,
The Ice Tube Clock is a wonderful kit - well engineered, fun to build, and great looking when finished! It is a royal shame the tubes are not reasonable to obtain in quantities any more but I can definitely understand that. I tip my hat to your team in designing and supplying such a great project. I will enjoy mine until the tube gives up which I hope will be a while yet.
Btw I loved my Monochron clock too! Another great kit!
Kind regards,
Jerry
The Ice Tube Clock is a wonderful kit - well engineered, fun to build, and great looking when finished! It is a royal shame the tubes are not reasonable to obtain in quantities any more but I can definitely understand that. I tip my hat to your team in designing and supplying such a great project. I will enjoy mine until the tube gives up which I hope will be a while yet.
Btw I loved my Monochron clock too! Another great kit!
Kind regards,
Jerry
- jarchie
- Posts: 615
- Joined: Sun Jun 24, 2012 2:16 pm
Re: Ice Tube Clock - Battery Life
Sorry I'm late to the party; I haven't been checking the forums recently. But I thought a few late comments might still be of interest.
There are two independent parts of the circuit that consume power in sleep mode. The microcontroller consumes ~30 uA, and the R1/R2 resistor divider uses ~10 uA. That's 40 uA total or about a month of sleep time on a standard coin cell (~40 mAh).
Upgrading to an ATmega328p with my firmware will reduce the microcontroller sleep current to ~2 uA, making the total draw about 12 uA. So just switching firmware will increase total sleep time to about 5 months.
The R1/R2 resistor divider can be attached directly to the voltage regulator by cutting one trace and soldering one wire. When combined with the microcontroller current reduction, this reduces sleep current draw to ~2uA. That's over two years of sleep!
These power reduction mods are described fully in this post.
You might also consider the automatic dimmer mod. Keeping the display only as bright as necessary given the ambient lighting will reduce phosphor exhaustion and extend tube life.
Finally, there are display scheduling features in my firmware which can help save tube life. I don't know if these are of interest, but here's an excerpt from the usage documentation:
Hope that helps. Good luck and happy hacking!
There are two independent parts of the circuit that consume power in sleep mode. The microcontroller consumes ~30 uA, and the R1/R2 resistor divider uses ~10 uA. That's 40 uA total or about a month of sleep time on a standard coin cell (~40 mAh).
Upgrading to an ATmega328p with my firmware will reduce the microcontroller sleep current to ~2 uA, making the total draw about 12 uA. So just switching firmware will increase total sleep time to about 5 months.
The R1/R2 resistor divider can be attached directly to the voltage regulator by cutting one trace and soldering one wire. When combined with the microcontroller current reduction, this reduces sleep current draw to ~2uA. That's over two years of sleep!
These power reduction mods are described fully in this post.
You might also consider the automatic dimmer mod. Keeping the display only as bright as necessary given the ambient lighting will reduce phosphor exhaustion and extend tube life.
Finally, there are display scheduling features in my firmware which can help save tube life. I don't know if these are of interest, but here's an excerpt from the usage documentation:
firmware/USAGE wrote: "cfg disp" / "auto off" -- Automatic Display Off
Some users may wish to inactivate the display when no one is around, as doing so should extend VFD lifetime. Other users may wish to inactivate the display at night, as extra light can interfere with sleep. When the display is inactive, pressing any button will enable the display for one minute.
"off dark"
Enable or disable automatic inactivation at night (when dark). This option is only available if the automatic dimmer is enabled, which requires a photoresistor and pull-up. Unless this option is disabled, the user will be prompted for a darkness detection threshold ("thrsh XX").
"off time"
Enable or disable automatic inactivation during certain hours. For example, if the clock is at the workplace of someone with a 9-to-5 schedule, the display may be disabled from 5:00pm to 9:00am.
"off days"
Enable or disable automatic inactivation during certain days. For example, if the clock is at the workplace of someone with a Monday-through-Friday schedule, the display may be disabled during weekends.
"on days "
Force the display to be active on certain days (overrides off time). For example, if the clock is at the home of a person with a 9-to-5 Monday-through-Friday schedule, they might set the "off time" to 9:00am to 5:00 pm and set the "on days" to weekends, so the display would be enabled whenever the person is home.
Hope that helps. Good luck and happy hacking!
- terranjerry
- Posts: 38
- Joined: Tue Feb 11, 2014 1:39 pm
Re: Ice Tube Clock - Battery Life
John,
Thank you so very much for the reply. I had noticed your post you referenced after my original post in this thread. Thanks for all that great info. I liked all your mods and as soon as I can purchase and receive the programming interface AF sells, I intend to apply all those mods you mentioned. This should help me get a long life out of the clock.
This is great fun - both to build the clock and to hack it a bit to achieve optimum life and enjoyment. I want to thank you so much for sharing all your tips. You clearly understand both hardware and software very well. Thanks again!
Jerry
Thank you so very much for the reply. I had noticed your post you referenced after my original post in this thread. Thanks for all that great info. I liked all your mods and as soon as I can purchase and receive the programming interface AF sells, I intend to apply all those mods you mentioned. This should help me get a long life out of the clock.
This is great fun - both to build the clock and to hack it a bit to achieve optimum life and enjoyment. I want to thank you so much for sharing all your tips. You clearly understand both hardware and software very well. Thanks again!
Jerry
- terranjerry
- Posts: 38
- Joined: Tue Feb 11, 2014 1:39 pm
Re: Ice Tube Clock - Battery Life
John,
One more question for you and I apologize if this is very naive but I'm just learning about these Atmega processors. I wanted to get an Atmega328P to use your low power consumption software and I found this one locally....
http://www.microcenter.com/search/searc ... ATmega328P
and I was wondering if it would work. It says it is an Arduino which I am guessing is only in reference to the software that is on the chip. I assume if I bought it and used the AVR programmer to put your code in it, it would just wipe out the Arduino software and put the clock software in. Does that sound correct?
By that question I am assuming an Arduino is just a software package that runs on an Atmega processor - not a hardware specific variant of an Atmega - would that be true?
I know this is kind of the expensive way to get an Atmega328P but it's available locally so I don't have to wait to mail-order it.
Thanks for sharing your thoughts on this!
Jerry
One more question for you and I apologize if this is very naive but I'm just learning about these Atmega processors. I wanted to get an Atmega328P to use your low power consumption software and I found this one locally....
http://www.microcenter.com/search/searc ... ATmega328P
and I was wondering if it would work. It says it is an Arduino which I am guessing is only in reference to the software that is on the chip. I assume if I bought it and used the AVR programmer to put your code in it, it would just wipe out the Arduino software and put the clock software in. Does that sound correct?
By that question I am assuming an Arduino is just a software package that runs on an Atmega processor - not a hardware specific variant of an Atmega - would that be true?
I know this is kind of the expensive way to get an Atmega328P but it's available locally so I don't have to wait to mail-order it.
Thanks for sharing your thoughts on this!
Jerry
- jarchie
- Posts: 615
- Joined: Sun Jun 24, 2012 2:16 pm
Re: Ice Tube Clock - Battery Life
I'm very glad you asked. The Arduino chip will work but wiping the chip is a bit more challenging than programming a blank chip. Here's an excerpt from the firmware/README file:
Digi-Key sells blank ATmega328p chips and offers USPS first class shipping. If you're in the USA, first class on a small chip is usually just a few bucks--about what the $4 chip costs.
http://www.digikey.com/product-search/e ... 328P-PU-ND
The setup you linked to does had an Arduino-type board included with the chip; with a breadboard and a bunch of jumpers, you could probably use that to reprogram the provided chip.:: Programming Fails with an Arduino Chip ::
The Arduino Uno chip is an ATmega328p, but will not work in an Ice Tube Clock without reconfiguration. Arduino chips have their fuse settings configured to use an external 16 MHz oscillator for the system clock. The Ice Tube Clock does not provide a suitable external oscillator, and without an external oscillator, an Arduino chip will not function--not even to be reconfigured.
To provide an external oscillator for reconfiguration, insert the Arduino chip into an Arduino board. Next, connect a programmer to the ISP on the Arduino board and reprogram the fuses with the xmas-icetube Makefile: "make install-fuse". The ATmega328p's fuse settings are now configured to use the 8 MHz internal oscillator and can be installed and programmed as described in the INSTALLATION section.
This method is also described in the following thread:
http://forums.adafruit.com/viewtopic.ph ... 22#p184722
Digi-Key sells blank ATmega328p chips and offers USPS first class shipping. If you're in the USA, first class on a small chip is usually just a few bucks--about what the $4 chip costs.
http://www.digikey.com/product-search/e ... 328P-PU-ND
- terranjerry
- Posts: 38
- Joined: Tue Feb 11, 2014 1:39 pm
Re: Ice Tube Clock - Battery Life
Thanks very much for the reply John!
I haven't read much about the fuses and clearly need to so I can understand the architecture better.
I understand though what you are telling me and I appreciate the info on how to proceed.
Perhaps I will wait and just order the proper chip to save myself some grief.
However, that said, I do have a regular Arduino board at home (I think it's the Uno) which would probably provide the clock needed to reburn the fuses to support the IceTube clock. So, I could buy the chip locally that is configured as an Arduino I believe and plunk it down into my Uno board and redo the fuses as you described.
I might do that just for the educational value though I know you have to be careful with the fuse messing else you end up with a boat-anchor Atmega.
Thanks for the info. I'll let you know how I progress with it. I am VERY anxious to try out your cool software and my AVR programmer came just yesterday (woot - and from Adafruit!) so I'm ready to start on that this weekend. fun fun!
Jerry
I haven't read much about the fuses and clearly need to so I can understand the architecture better.
I understand though what you are telling me and I appreciate the info on how to proceed.
Perhaps I will wait and just order the proper chip to save myself some grief.
However, that said, I do have a regular Arduino board at home (I think it's the Uno) which would probably provide the clock needed to reburn the fuses to support the IceTube clock. So, I could buy the chip locally that is configured as an Arduino I believe and plunk it down into my Uno board and redo the fuses as you described.
I might do that just for the educational value though I know you have to be careful with the fuse messing else you end up with a boat-anchor Atmega.
Thanks for the info. I'll let you know how I progress with it. I am VERY anxious to try out your cool software and my AVR programmer came just yesterday (woot - and from Adafruit!) so I'm ready to start on that this weekend. fun fun!
Jerry
- jarchie
- Posts: 615
- Joined: Sun Jun 24, 2012 2:16 pm
Re: Ice Tube Clock - Battery Life
If you have an Uno board and the Adafruit USBtinyISP, reprogramming the fuses should be straightforward. The xmas Makefile should take care of setting the correct fuses which pretty much eliminates the possibility of bricking the chip. If you run into issues just post back to this thread, and I'd be happy to help.terranjerry wrote:However, that said, I do have a regular Arduino board at home (I think it's the Uno) which would probably provide the clock needed to reburn the fuses to support the IceTube clock.
- terranjerry
- Posts: 38
- Joined: Tue Feb 11, 2014 1:39 pm
Re: Ice Tube Clock - Battery Life
I guess I need some help yet. :o)
I built my USBTinyISP per the instructions but was not sure what to do with R4 and R7 (the extra resistors) but left them out thinking I was not using the POV interface so the instructions said leave them out. I did.
I installed the driver per the web site (but I have to admit all those drivers being checked really threw me and I don't know which one(s) I need based upon those names. So, I went with the defaults. After doing so, I attached the USBTinyISP to the computer and it came up with a green light. So far so good.
I downloaded John's code and built it - the hex files were created as expected. Then I tried to run the command 'make install-all' and I got errors. The red LED came on and stayed on and I saw these errors.
(Note my avrdude is version 5.10)
$ make install-all
avrdude -B 4 -P usb -c usbtiny -p atmega328p -u -U lfuse:w:0x62:m -u -U hfuse:w: 0xD1:m -u -U efuse:w:0x06:m -U flash:w:icetube_flash.hex:i -U eeprom:w:icetube_e eprom.hex:i -U lock:w:0x2B:m
avrdude.exe: error: usbtiny_receive: usb_control_msg: sending control message fa iled, win error: A device attached to the system is not functioning.
(expected 4, got -5)
avrdude.exe: AVR device initialized and ready to accept instructions
Reading |
avrdude.exe: error: usbtiny_receive: usb_control_msg: sending control message fa iled, win error: A device attached to the system is not functioning.
(expected 4, got -5)
avrdude.exe: error: usbtiny_receive: usb_control_msg: sending control message fa iled, win error: A device attached to the system is not functioning.
(expected 4, got -5)
################
avrdude.exe: error: usbtiny_receive: usb_control_msg: sending control message fa iled, win error: A device attached to the system is not functioning.
(expected 4, got -5)
################################## | 100% 0.06s
avrdude.exe: Device signature = 0x000000
avrdude.exe: Yikes! Invalid device signature.
Double check connections and try again, or use -F to override
this check.
avrdude.exe: error: usbtiny_transmit: usb_control_msg: sending control message f ailed, win error: A device attached to the system is not functioning.
avrdude.exe done. Thank you.
make: [install-all] Error 1 (ignored)
I tried repeating the command a few times - no joy.
So, I unplugged everything and reconnected everything and now I get a minus 1 error like this...
$ make install-all
avrdude -B 4 -P usb -c usbtiny -p atmega328p -u -U lfuse:w:0x62:m -u -U hfuse:w:0xD1:m -u -U efuse:w:0x06:m -U flash:w:icetube_flash.hex:i -U eeprom:w:icetube_eeprom.hex:i -U lock:w:0x2B:m
avrdude.exe: initialization failed, rc=-1
Double check connections and try again, or use -F to override
this check.
avrdude.exe done. Thank you.
make: [install-all] Error 1 (ignored)
So, I think I went from bad to worse perhaps.
I appreciate any tips you might offer. I'm sure this is a cockpit problem but the pilot is quite confused and probably shouldn't be flying at this point.
Thanks!
Jerry
I built my USBTinyISP per the instructions but was not sure what to do with R4 and R7 (the extra resistors) but left them out thinking I was not using the POV interface so the instructions said leave them out. I did.
I installed the driver per the web site (but I have to admit all those drivers being checked really threw me and I don't know which one(s) I need based upon those names. So, I went with the defaults. After doing so, I attached the USBTinyISP to the computer and it came up with a green light. So far so good.
I downloaded John's code and built it - the hex files were created as expected. Then I tried to run the command 'make install-all' and I got errors. The red LED came on and stayed on and I saw these errors.
(Note my avrdude is version 5.10)
$ make install-all
avrdude -B 4 -P usb -c usbtiny -p atmega328p -u -U lfuse:w:0x62:m -u -U hfuse:w: 0xD1:m -u -U efuse:w:0x06:m -U flash:w:icetube_flash.hex:i -U eeprom:w:icetube_e eprom.hex:i -U lock:w:0x2B:m
avrdude.exe: error: usbtiny_receive: usb_control_msg: sending control message fa iled, win error: A device attached to the system is not functioning.
(expected 4, got -5)
avrdude.exe: AVR device initialized and ready to accept instructions
Reading |
avrdude.exe: error: usbtiny_receive: usb_control_msg: sending control message fa iled, win error: A device attached to the system is not functioning.
(expected 4, got -5)
avrdude.exe: error: usbtiny_receive: usb_control_msg: sending control message fa iled, win error: A device attached to the system is not functioning.
(expected 4, got -5)
################
avrdude.exe: error: usbtiny_receive: usb_control_msg: sending control message fa iled, win error: A device attached to the system is not functioning.
(expected 4, got -5)
################################## | 100% 0.06s
avrdude.exe: Device signature = 0x000000
avrdude.exe: Yikes! Invalid device signature.
Double check connections and try again, or use -F to override
this check.
avrdude.exe: error: usbtiny_transmit: usb_control_msg: sending control message f ailed, win error: A device attached to the system is not functioning.
avrdude.exe done. Thank you.
make: [install-all] Error 1 (ignored)
I tried repeating the command a few times - no joy.
So, I unplugged everything and reconnected everything and now I get a minus 1 error like this...
$ make install-all
avrdude -B 4 -P usb -c usbtiny -p atmega328p -u -U lfuse:w:0x62:m -u -U hfuse:w:0xD1:m -u -U efuse:w:0x06:m -U flash:w:icetube_flash.hex:i -U eeprom:w:icetube_eeprom.hex:i -U lock:w:0x2B:m
avrdude.exe: initialization failed, rc=-1
Double check connections and try again, or use -F to override
this check.
avrdude.exe done. Thank you.
make: [install-all] Error 1 (ignored)
So, I think I went from bad to worse perhaps.
I appreciate any tips you might offer. I'm sure this is a cockpit problem but the pilot is quite confused and probably shouldn't be flying at this point.
Thanks!
Jerry
- terranjerry
- Posts: 38
- Joined: Tue Feb 11, 2014 1:39 pm
Re: Ice Tube Clock - Battery Life
Success!
The pilot recovered the plane before all hope was lost.
Seems the instructions should probably say that if you don't use R4 and R7 in the assembly of the USBTinyISP you 'should' put a jumper in R4 and R7.
It says you 'may want to' install a jumper.
Since some of us are just learning how this all works, it might be more helpful if the instructions explained what "loaded pins" means since that might have driven my thought process in the right direction of installing the jumpers.
I presume this is because it is up to the user as to whether or not they need to program 'loaded pins' but if you don't know - you might infer from these instructions that you should leave them out (as I did). Anyway, no harm and no foul; just a bit of confusion on my part. ;o)
Here is what I got when I corrected this - it looks right to me now but I still have to reassemble the clock and see how it goes.
avrdude -B 4 -P usb -c usbtiny -p atmega328p -u -U lfuse:w:0x62:m -u -U hfuse:w:0xD1:m -u -U efuse:w:0x06:m -U flash:w:icetube_flash.hex:i -U eeprom:w:icetube_eeprom.hex:i -U lock:w:0x2B:m
avrdude.exe: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.01s
avrdude.exe: Device signature = 0x1e950f
avrdude.exe: NOTE: FLASH memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude.exe: erasing chip
avrdude.exe: reading input file "0x62"
avrdude.exe: writing lfuse (1 bytes):
Writing | ################################################## | 100% 0.00s
avrdude.exe: 1 bytes of lfuse written
avrdude.exe: verifying lfuse memory against 0x62:
avrdude.exe: load data lfuse data from input file 0x62:
avrdude.exe: input file 0x62 contains 1 bytes
avrdude.exe: reading on-chip lfuse data:
Reading | ################################################## | 100% 0.00s
avrdude.exe: verifying ...
avrdude.exe: 1 bytes of lfuse verified
avrdude.exe: reading input file "0xD1"
avrdude.exe: writing hfuse (1 bytes):
Writing | ################################################## | 100% 0.02s
avrdude.exe: 1 bytes of hfuse written
avrdude.exe: verifying hfuse memory against 0xD1:
avrdude.exe: load data hfuse data from input file 0xD1:
avrdude.exe: input file 0xD1 contains 1 bytes
avrdude.exe: reading on-chip hfuse data:
Reading | ################################################## | 100% 0.02s
avrdude.exe: verifying ...
avrdude.exe: 1 bytes of hfuse verified
avrdude.exe: reading input file "0x06"
avrdude.exe: writing efuse (1 bytes):
Writing | ################################################## | 100% 0.01s
avrdude.exe: 1 bytes of efuse written
avrdude.exe: verifying efuse memory against 0x06:
avrdude.exe: load data efuse data from input file 0x06:
avrdude.exe: input file 0x06 contains 1 bytes
avrdude.exe: reading on-chip efuse data:
Reading | ################################################## | 100% 0.00s
avrdude.exe: verifying ...
avrdude.exe: 1 bytes of efuse verified
avrdude.exe: reading input file "icetube_flash.hex"
avrdude.exe: writing flash (30168 bytes):
Writing | ################################################## | 100% 24.04s
avrdude.exe: 30168 bytes of flash written
avrdude.exe: verifying flash memory against icetube_flash.hex:
avrdude.exe: load data flash data from input file icetube_flash.hex:
avrdude.exe: input file icetube_flash.hex contains 30168 bytes
avrdude.exe: reading on-chip flash data:
Reading | ################################################## | 100% 15.00s
avrdude.exe: verifying ...
avrdude.exe: 30168 bytes of flash verified
avrdude.exe: reading input file "icetube_eeprom.hex"
avrdude.exe: writing eeprom (65 bytes):
Writing | ################################################## | 100% 0.33s
avrdude.exe: 65 bytes of eeprom written
avrdude.exe: verifying eeprom memory against icetube_eeprom.hex:
avrdude.exe: load data eeprom data from input file icetube_eeprom.hex:
avrdude.exe: input file icetube_eeprom.hex contains 65 bytes
avrdude.exe: reading on-chip eeprom data:
Reading | ################################################## | 100% 0.03s
avrdude.exe: verifying ...
avrdude.exe: 65 bytes of eeprom verified
avrdude.exe: reading input file "0x2B"
avrdude.exe: writing lock (1 bytes):
Writing | ################################################## | 100% 0.01s
avrdude.exe: 1 bytes of lock written
avrdude.exe: verifying lock memory against 0x2B:
avrdude.exe: load data lock data from input file 0x2B:
avrdude.exe: input file 0x2B contains 1 bytes
avrdude.exe: reading on-chip lock data:
Reading | ################################################## | 100% 0.00s
avrdude.exe: verifying ...
avrdude.exe: 1 bytes of lock verified
avrdude.exe done. Thank you.
Thanks again to all who have helped me on this journey! Jerry
The pilot recovered the plane before all hope was lost.
Seems the instructions should probably say that if you don't use R4 and R7 in the assembly of the USBTinyISP you 'should' put a jumper in R4 and R7.
It says you 'may want to' install a jumper.
.If you are using the UsbtinyISP with a SpokePOV kit, install R4 and R7 (1.5K) as well. If not you may want to switch these resistors for jumpers (see the second photo for a 'finished' shot) as it will mean that target boards with loaded pins can be programmed
Since some of us are just learning how this all works, it might be more helpful if the instructions explained what "loaded pins" means since that might have driven my thought process in the right direction of installing the jumpers.
I presume this is because it is up to the user as to whether or not they need to program 'loaded pins' but if you don't know - you might infer from these instructions that you should leave them out (as I did). Anyway, no harm and no foul; just a bit of confusion on my part. ;o)
Here is what I got when I corrected this - it looks right to me now but I still have to reassemble the clock and see how it goes.
avrdude -B 4 -P usb -c usbtiny -p atmega328p -u -U lfuse:w:0x62:m -u -U hfuse:w:0xD1:m -u -U efuse:w:0x06:m -U flash:w:icetube_flash.hex:i -U eeprom:w:icetube_eeprom.hex:i -U lock:w:0x2B:m
avrdude.exe: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.01s
avrdude.exe: Device signature = 0x1e950f
avrdude.exe: NOTE: FLASH memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude.exe: erasing chip
avrdude.exe: reading input file "0x62"
avrdude.exe: writing lfuse (1 bytes):
Writing | ################################################## | 100% 0.00s
avrdude.exe: 1 bytes of lfuse written
avrdude.exe: verifying lfuse memory against 0x62:
avrdude.exe: load data lfuse data from input file 0x62:
avrdude.exe: input file 0x62 contains 1 bytes
avrdude.exe: reading on-chip lfuse data:
Reading | ################################################## | 100% 0.00s
avrdude.exe: verifying ...
avrdude.exe: 1 bytes of lfuse verified
avrdude.exe: reading input file "0xD1"
avrdude.exe: writing hfuse (1 bytes):
Writing | ################################################## | 100% 0.02s
avrdude.exe: 1 bytes of hfuse written
avrdude.exe: verifying hfuse memory against 0xD1:
avrdude.exe: load data hfuse data from input file 0xD1:
avrdude.exe: input file 0xD1 contains 1 bytes
avrdude.exe: reading on-chip hfuse data:
Reading | ################################################## | 100% 0.02s
avrdude.exe: verifying ...
avrdude.exe: 1 bytes of hfuse verified
avrdude.exe: reading input file "0x06"
avrdude.exe: writing efuse (1 bytes):
Writing | ################################################## | 100% 0.01s
avrdude.exe: 1 bytes of efuse written
avrdude.exe: verifying efuse memory against 0x06:
avrdude.exe: load data efuse data from input file 0x06:
avrdude.exe: input file 0x06 contains 1 bytes
avrdude.exe: reading on-chip efuse data:
Reading | ################################################## | 100% 0.00s
avrdude.exe: verifying ...
avrdude.exe: 1 bytes of efuse verified
avrdude.exe: reading input file "icetube_flash.hex"
avrdude.exe: writing flash (30168 bytes):
Writing | ################################################## | 100% 24.04s
avrdude.exe: 30168 bytes of flash written
avrdude.exe: verifying flash memory against icetube_flash.hex:
avrdude.exe: load data flash data from input file icetube_flash.hex:
avrdude.exe: input file icetube_flash.hex contains 30168 bytes
avrdude.exe: reading on-chip flash data:
Reading | ################################################## | 100% 15.00s
avrdude.exe: verifying ...
avrdude.exe: 30168 bytes of flash verified
avrdude.exe: reading input file "icetube_eeprom.hex"
avrdude.exe: writing eeprom (65 bytes):
Writing | ################################################## | 100% 0.33s
avrdude.exe: 65 bytes of eeprom written
avrdude.exe: verifying eeprom memory against icetube_eeprom.hex:
avrdude.exe: load data eeprom data from input file icetube_eeprom.hex:
avrdude.exe: input file icetube_eeprom.hex contains 65 bytes
avrdude.exe: reading on-chip eeprom data:
Reading | ################################################## | 100% 0.03s
avrdude.exe: verifying ...
avrdude.exe: 65 bytes of eeprom verified
avrdude.exe: reading input file "0x2B"
avrdude.exe: writing lock (1 bytes):
Writing | ################################################## | 100% 0.01s
avrdude.exe: 1 bytes of lock written
avrdude.exe: verifying lock memory against 0x2B:
avrdude.exe: load data lock data from input file 0x2B:
avrdude.exe: input file 0x2B contains 1 bytes
avrdude.exe: reading on-chip lock data:
Reading | ################################################## | 100% 0.00s
avrdude.exe: verifying ...
avrdude.exe: 1 bytes of lock verified
avrdude.exe done. Thank you.
Thanks again to all who have helped me on this journey! Jerry
- jarchie
- Posts: 615
- Joined: Sun Jun 24, 2012 2:16 pm
Re: Ice Tube Clock - Battery Life
Congratulations on figuring out everything yourself! Well done.
By the way, I recommend using jumpers for R4 and R7 on the USBtinyISP. That configuration works for both loaded and unloaded pins. Installing the resistors for R4 and R7 means the programmer will only work with unloaded pins (or very lightly loaded pins). So installing jumpers makes the USBtinyISP work as a general purpose programmer.
In the case of the Ice Tube Clock programming works with both resistors and jumpers installed as R4 and R7. So you would be fine either way. But you are correct that something must be installed in place of R4 or R7; programming fails otherwise.
By the way, I recommend using jumpers for R4 and R7 on the USBtinyISP. That configuration works for both loaded and unloaded pins. Installing the resistors for R4 and R7 means the programmer will only work with unloaded pins (or very lightly loaded pins). So installing jumpers makes the USBtinyISP work as a general purpose programmer.
In the case of the Ice Tube Clock programming works with both resistors and jumpers installed as R4 and R7. So you would be fine either way. But you are correct that something must be installed in place of R4 or R7; programming fails otherwise.
Please be positive and constructive with your questions and comments.