Awesome, hopefully you have lots of memory left over.
Are you planning on sticking with the 85 or do you want to transition to the 1634?
I like the idea of making an adapter board to convert one of the new mcu’s to the old 85 footprint. The new one series has a chip with 2M of memory and a lot of pins. Enough for a crystal to make timing accurate and for an external temperature sensor on the driver and/or mcpcb. Plus only three pins on the programming key.
Not sure how feasible it is but you and the hardware people would be set for a long time.
It also has virtually no support in the open-source toolchains, so I don’t have a way to build code for it or flash code after building. I can’t really consider it as a viable option until those issues are fixed. It’ll be pretty cool some day though.
For now, the tiny1634 provides plenty of room to grow. It has twice as much ROM as tiny85, and a bunch of extra pins. I’ve also started on tiny841 support, but I don’t have it working yet.
I’ve been compiling for the the 1-series chips using GCC, you just need to include Microchip’s “device family pack” files. Now, I haven’t flashed them from Linux yet… I really need to try that.
The 1-series chips have been pretty nice. While limited to 4KB, the attiny412 makes a great PIC replacement in existing lights due to it’s pinout. I just replaced the MCU in my Convoy H1 with one (with RampingIOS). I’ve done the same with the D25 headlamp. For new development (custom boards), I’ve been using the X16 (ie: 416, 816, 1616, and 3216) where I need a smaller footprint, more pins, or more flash.
If you come up with something cool though, I bought 25 of the 1634 right before I switched over to mostly 1-series dev. Hopefully they’ll get used someday, even if it’s not by me.
It sounds like we should coordinate to get FSM supported added for those too. Or perhaps I should get off my butt and take a close look at the work you’ve already done. This may just boil down to me being slow.
Do you know if the newer chips have support in avr-libc? If so, that would make a lot of things easier. If not, it’s definitely still doable, but it’ll need to abstract out potentially the entire C library. Or at least parts of it, and how it hooks into other files.
Also, I’m way behind on getting your code into the repository. Would it be okay for me to import everything at Index of /blf/firmware ?
I took a look at FSM a while ago, I should take a stab at it. I haven’t worked with finite state machines since college (about 12-15 years ago!) but it shouldn’t be terrible. Mostly just swapping out register names. Oh, and for timed tasks I’ve been using the RTC instead of WDT. But that’s about it.
I’m using avr-gcc but you need to bring in the Atmel Device Family Pack files. A sample build script is here (originally based on one of yours)
Yup, you can grab the stuff I’ve got up there if you’d like.
It’s not exactly the cleanest code. It’s a spaghetti monster, after all. And the published branches don’t have tiny1634 support yet, so they lack the changes I made to improve portability.
I’m still pondering how best to support lots of different hardware simultaneously, in a manner which is relatively clean. It could use a lot of refactoring… beyond what I did for tiny1634 support. But I’m not sure exactly how to structure it yet.
The 3217 is cheaper and more future proof. I’d like to think that this latest generation chip would have better internal clocks and temperature sensors but I can’y find anything in the spec sheets to prove it.
No one spends more time programming and testing than you do. It doesn’t seem like it took a long time to outgrow the 13,25,45 and 85. This time you get to choose the new chip. Twice as much memory as a 1634 and a three pin programming key can’t be a bad combo.
I’ve written and flashed simple firmware for the 3217 for a specific project. I’ve got most of the stuff working: Internal temp sensor, ADC, PWM, pin interrupts, software reboot and RTC (instead of WDT). All I have left for full functionality support is OTSM with the low power consumption options to run the MCU from the cap. After that I just have to fix the definitions and I’ll be ready to go. Besides 3 pin flashing, the 1617/3217 interested me because it has a DAC. The choice between 1617 and 3217 was pretty easy, the 3217 only costs a few more cents than the 1617, no reason not to go with 32 kb.
I haven’t started testing it yet. I have a 3217 driver that will be on it’s way from OSH Park shortly. I had some space over so I included a via for DAC output so I can play with it a little. Just got to get my 1634 firmware fully compatible with 3217 by defines first.
The low-level hardware interfaces usually seem to me like the hardest part of making firmware. Each chip has its own particular way of setting registers to configure it in a useful manner. Once the hardware is configured though, I like building the upper layers of the code.
That’s why it takes me so long to add support for new MCUs in my UI toolkit. Most of that work is about the low-level interfaces, and I’m more of an application developer at heart… not as much of a hardware enablement developer.
I should probably rewrite the entire hardware abstraction API. What I have now is completely ad-hoc and not particularly coherent. But until I’ve added a few more chips, I don’t know how best to organize it. Attiny1634 was relatively easy compared to something like tiny3217 or a PIC chip, because it wasn’t much different than tiny85.
If you can help isolate the hardware-level stuff, I’d be glad to try and help with the porting to 1-series.
I’ve never looked at PIC but I probably should sometime as it seems that many non-BLF flashlight drivers use PIC. But it has been handy that the X12 AVR’s use a PIC layout (thinking retrofit here).
Tterev has done some beginners guides to pic’s, I think Toykeeper has stashed some of his work on the repository.
I think an adapter board would be the easiest way to tackle pic’s. Wight made one for the eight pin chips although I don’t think anyone ever finished the project.
Well… I dunno exactly when I’ll get around to porting the code, but I made a development board for the attiny816 (or 1616 / 3216). Basically the same at the 817 except it’s 20 pin instead of 24; I don’t plan on need 24 pins anytime soon. Instead of running through regulators or FETs, I’m just using the MCU output to run the LED (limited with resistors). Since this is just for testing, I don’t need it bright… actually, bright is bad because I’d just be blinding myself.
gchart, I’m not knocking you for threadjacking, because I’m just glad to see this development come to light. But this is very big news. It actually does deserve its own thread, if you can find the time.
I just cross-posted in my AVR Series-1 thread. I’ll try to continue posting updates over there. I just ordered the boards today, so it’ll be a little bit before they’re fully assembled. I guess I could start pulling code down and converting in the meantime… (like I really needed another thing to do )
That’s what FSM does. There’s a hardware interface on the back end, plus a UI toolkit on the front end. That way, the UI code is portable and doesn’t have to care (much) about the hardware it runs on.
However, it’s not exactly the cleanest code. It’s a spaghetti monster. It doesn’t do a great job of isolating the hardware-level parts from the library logic, so that gets kinda mixed in sometimes and could use cleaner abstractions. There’s probably a lot of stuff which doesn’t really make sense, but needs a fresh pair of eyes to notice the mess.
Thanks. I’ve been meaning to check on that project again, but I get distracted easily by other shiny things. It’s great to see that the code is available now, and published under GPLv3. There’s nothing wrong with arduino code though… I even used a couple arduino-isms while designing FSM’s interface. Anyway, it looks like loneoceans made things pretty clean.
I really like the flexibility of HQ’s programming key. There’s no reason you couldn’t adapt nearly any PCB design to use it (or some variation of it). I picked up 6ea from oshpark and can’t wait to try my hand at designing my own driver boards with integrated programming ports.
Thanks for open sourcing the design. I’ll probably try using kicad, so I’ll see if I can release some definitions for the footprint.
)