Actions
Forum Thread Details
  • State Not Answered
  • Replies 8 replies
  • Subscribers 389 subscribers
  • Views 1842 views
  • Users 0 members are here
Related

Arduino IDE vs DigiSpark issue

tm_stump

I've been looking for information about a small problem I encountered programming a Digispark board (attiny85) using the Arduino IDE and a Pololu pgm04b programmer.  The setup works without having to burn a bootloader to the digispark, but here is the issue.  If I upload the sketch using the digispark 1 or 8 Mhz board choices, the program runs as it should with no problems.  If I use one of the 16 or 16.5 MHz choices, the program runs extremely slow with maybe some other problems as the counter built in to count button pushes doesn't update.  I'm trying to find out what changes, exactly, are being made during compilation that provides a defect in the compiled program when using the higher speed choices.  I'm no expert, but I'm hoping that someone is aware of something I may be overlooking.  To throw a wrench into the works I might mention that this appears to be digispark clone so it's entirely possible that the ATtiny85 used on the board is not only not up to par but I guess there's a possibility it's not a genuine ATtiny.  I have some plain ATtiny85 on the way to try this without the digispark hardware overhead.

The sketch/program is just a simple program to count momentary button pushes, display the button push counts and allow an LED to blink on even numbered counts.

thanks,

TM

Parents
  • 0

    OK, I think I found the issue but I can't explain why this happens.   The first and working board (digispark clone) compiled as a 16Mhz board had the Lfuse set to disable the clock divider CKDIV8 fuse, Lfuse:0x62 vs Lfuse:0xE2 (disabled).  The subsequent boards compiled at 16 Mhz had the Lfuse CKDIV8 enabled and so taking that board and just changing the Lfuse to disable CKDIV8, using avrdude -U lfuse:w:0xe2:m (+ the config params), the board works as expected.  This works in every case.  Now the question becomes 'why are the fuses compatible with the board choice not written in addition to the program?'  The only thing I can come up with is that I'm overlooking some setting that allows the entire sketch, including compatible fuse settings, to be written or changed.  Or maybe I found a bug when using clones with the digistump libs, but there's no feedback in searches for this type of problem so I doubt the bug factor is valid.  Back to the datasheet for a deeper dive!

    The resultant output of the incorrectly operating boards varied from very, very slow operation to giving a very slow display and an inverted display on the .96" OLED used to show the button count.  Very odd.

    thanks,

    TM

  • 0 in reply to tm_stump

    I think the fuses get set when you choose a different menu option, something like "Burn bootloader".

    Not done every time you upload as that takes too long.

Reply Children
No Data