Public thanks for the arduino-tiny core

So I've been ripping out my hair for the past week or so trying to debug an issue I've been having with a little tiny85 blinkenlichten I've been working on where a switch that falls through to a sleep after timing out worked for 8 modes out of 9, but the 9th mode just never slept consistently, the sketch seemed like it was restarting from loop() whenever I break'ed out of the function the switch case called. But only that particular function, and only part of the time and and and. Maddening, especially when it seemed to exhibit itself more when I let it run longer.

I finally just decided to go all in and switch over to the arduino-tiny core instead of the HLT core and after tweaking speeds (it's all nests of delay loops, so compiler optimizations affect it), initial results are promising. It sleeps when it should be! Power draw is what I expect - actually less in the main loop, by a third, and it still enters the low power sleep like I want it to. The arduino-tiny core includes the 16MHz PLL clock on the tiny85 without having to muck around in boards.txt, too!

It was far less annoying to switch than I had been afraid it would be after all the personalizations I'd made to the HLT core that I wasn't sure I'd remember. My code just up and compiled, although not with the appbundle I have for the Arduino Tiny with the PCREL-proof upgraded avr-gcc toolchain. Eh, Tom Carpenter's replacement ld should solve the 4k barrier when I start hitting it again.

So... Thanks!

(...of course, I'm sure I've jinxed it by suggesting that it seems to be working now...)

...after all the personalizations I'd made to the HLT core...

Do you use Git(hub)?

Do you use Git(hub)?

I do, but mostly only for my own code. I could probably dig into the dropbox changelog if anything particular comes up, though. That said, I probably overspoke - thinking back on it I probably only extended the boards.txt file for additional BOD levels and clocks, and I made up a separate bundle of the Arduino environment with the updated toolchain to get past the PCREL linker error. Part of my goal this week is to try to get my local Arduino toolchain back to as close to the distribution defaults as possible again, then re-apply changes in a controlled and documented manner so I know what I've all changed.

pfriedel:
Part of my goal this week is to try to get my local Arduino toolchain back to as close to the distribution defaults as possible again, then re-apply changes in a controlled and documented manner so I know what I've all changed.

Why go through all that trouble? Just use the latest version of WinAVR and be done with it.

Wrong OS. :slight_smile: I've been tempted to see about switching to avr-gcc and a more traditional make / compile / link process, though. But that feels like a bit more trouble anyway. I'm not entirely sure what I'd be leaving behind and what I'd be gaining in the process. Just not sure I'm ready to leave the nest, as it were.

Although that said, if there's a project and target I would convert with, this is probably it. Limited dependencies by nature and a light touch on the Arduino-isms, hrm. Might be an alternative option.

pfriedel:
Wrong OS. :slight_smile:

Mac OS? If yes, I believe something named "crosspack" takes care of the problem.

Lunux? If yes, I believe you can pick and choose the AVR-GCC version.

I've been tempted to see about switching to avr-gcc and a more traditional make / compile / link process, though. But that feels like a bit more trouble anyway.

It is for me (more trouble than it's worth). I hate fiddling with tools.

I'm not entirely sure what I'd be leaving behind and what I'd be gaining in the process.

For the latest WinAVR version you'd be giving up some bugs. The PCREL bug is the only serious one I've encountered.

For the latest AVR-GCC I believe you'd be gaining C++11.

Were I in your shoes I'd just replace ld.