Who is still flashing his/her own drivers?

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?

I mostly build and flash my drivers.

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.

Yeah, but itā€™s a lot easier with the arduinos Iā€™ve used. Just plug in the USB port, and let the IDE do everything else.

I think itā€™s the same C-subset language, IIRC, but flashing a dev board makes things significantly simpler than attinys on flashlight drivers.

I have some remains of knowledge and equipment from school times, so it is not a big challenge for me. Only need a little more time and willingnessā€¦

Me scrolling down and saw this:

I had quite a laugh
:+1:

I donā€™t use anything like that. The 1634 is the MCU that I use for my drivers, but I use the QFN size one and flash them using what I call ā€œacupuncture styleā€ method: Mod: BMF SRK v2 Roche Edition (Rebuilt into triple XHP 35 HI) - #18 by Mike_C

Tried a few times but never got atmel studio or usbasp working properly

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?

I flash mine because I like very specific things in firmware and theyā€™re not always available as options.

:blink: How?

Is your set to 5v or 3.3v?

I had problems trying to flash with it set to 3.3v.

Any guide how to do this on Raspberry Pi?

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 :slight_smile:

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ā€¦

+1

Not a bad idea!

Yikes. Do you use a microscope?

I suppose the SOIC is too big.

Answering the OP, Iā€™ve ordred the parts.

I know how to program in C but this will be new to me.

I have an oddball idea Iā€™d like to try. I think it will fit on a ATTiny13.

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.