Who is still flashing his/her own drivers?

I used a Raspberry Pi to flash my driver, it was relatively easy. My technical background has nothing to do with software/firmware development.

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.