The Convoy drivers have pin 5 of the MCU grounded unnecessarily, which prevents flashing. By carefully cutting that trace, you should be off to the races in no time. Have a read through pretty much this whole page. There are some good pictures and explanations. If you run into more trouble (or to tell of your success story), hit us up over on that thread perhaps?
Me, I solely use lights with my own firmware (and mostly also my self designed drivers). I want the perfect UI (still a project in work, but close meanwhile) and I donāt want to memorize different UIs.
I was just checking to see if you were still on that MCU or had moved onto something else. Plus it was an easy way to let others know there is a development board available for the 1634.
Is that little QFN package any worse than an 85 when it comes to the internal clock changing speed with voltage and temperature?
Yeah, Iāll be sticking with the 1634 for a while. All the newer ones appear to be smaller or tighter packages, making adding paste more difficult. Iāve had enough problems as it is now, took awhile to get the pasting technique dialed in and the right sized holes in the stencils. 20 pins on 4x4mm is as tight as I want to go, so the 1634 is currently my best choice. I thought others would be well into the 1616 or 1617 by now considering the interest some showed in them, but have yet to see such a driver. Maybe itās still in development.
I havenāt tested myself but my impression is that the 1634 QFN isnāt any better than the 85 SOIC. I donāt worry too much about that though. I remember when I used those temperature characteristics to code an āinternal temperature sensorā in the ATtiny13A. It took too much out of the 1kb program size to be of any use for flashlight firmwareā¦ but it was fun, it worked
Iām one of those people who infuriates software/support guys because stuff just breaks on me. Last driver I tried to flash resulted in my laptop suffering multiple blue screens of death then difficulty recovering data from the hard driveā¦
At some point, I really should write a hardware abstraction layer for the MCU architecture, and add support for tiny84 / tiny841 / tiny1634. Then there would be a whole set of interfaces available for drivers with those chips. Itāll be kind of a pain though, and I have no hardware, so I havenāt started yet.
Iāve pretty much got the UI abstraction stuff to a mature stateā¦ but the hardware abstraction bits are still fairly early in the development process. Itāll take a while to do those parts.
Tindie.com sells development boards at a nice price. They have been flashed with an arduino bootloader but that should be easy to overwrite. Might even be able to read the fuse settings first.
I tried porting Anduril to a 1634. I thought it would be a good way to learn C. It did not go well but now I have a much better understanding of how much I donāt know.
The changes to the clock prescaler (mostly write enable) and watchdog timer will probably make it easier just to make a separate program. I think some stuff changed with reading and writing the eeprom as well. The changes will probably be childās play for you, but if you are going to invest much effort into it perhaps there is a newer chip with more memory that could be used. It would be a shame to have all the extra I/O pins available and then be hamstrung trying to use them.