4 channel Light saber driver design, may the light be with you.

I would love to see some action here. TK? …Have you got anything to report? …TK? …Anybody?

I got kind of ninja’d by other parts of life for a few months.

Also, um, I don’t actually have any driver boards to print and build. Texas_Ace, do you have these up on oshpark? I didn’t see the saber driver listed there.

I never heard back from you on weather it was ok and what you wanted so I didn’t bother uploading it in case it needed changes. lol

If you think it will work for you I can upload it.

I think it’ll probably work. If you’re willing though, it’d also be nice to have one with a pin and pad for an e-switch instead of the voltage divider. I think I can probably use the inverted VCC method for measuring voltage, and an e-switch likely makes the interface easier to navigate.

Or I could maybe use the 4th PWM pin for an e-switch, and use only three colors. I’m not sure how much value there is in adding a 4th color channel, and it should be fairly easy to stick the switch wire into one of the vias on pin 2 or 3.

Is there no use for adding a little bit of white to the mix? You can get some bright tinted colors this way. But I must say, I have no idea how a saber is yo be used:)

The idea was that you could use the R1/R2 pads to setup the e-switch if you didn’t need the voltage divider. I went ahead and added a dedicated set of pads for the switch though.

Here is the oshpark link: OSH Park ~

Software PWM can work very well as long as you have a timer available (that is not used for anything else) and don't frequently need to suspend interrupts (such as to write to NVM) which will glitch the PWM output. It's fairly easy to implement - here's pseudocode that you would put in an 8-bit timer's overflow interrupt routine. The only overhead you'll need is a variable for the output (duty cycle) you want and a flag bit that toggles to keep track of the phase of the output.

if timer overflowed to zero (interrupt):

toggle the flag

if the flag is set:

turn on the output pin

load the timer with a value of (255 - duty cycle)

else if the flag is clear:

turn off the output pin

load the timer with the value of duty cycle

The way this works is by scheduling the following interrupt to occur in a variable amount of time. By loading the timer with a low value, it will take longer before overflowing past 255 again and the subsequent interrupt will scheduled further out, and vice versa for a high value. So as an example, say the timer runs at 1MHz and the duty cycle is set to 200 (of 255). The interrupt will fire and turn on the output, then load 55 into the timer. The timer then has to count up 200 cycles before firing the interrupt again, when the output is turned off. Then 200 is loaded into the timer, so it only has to count up 55 cycles before firing again and starting the process over. This gives a high output for 200us and a low output for 55us, so we get a ~4kHz PWM signal at ~78% duty.

This can be extended slightly to give better performance at the extremes (0 and 100%) by adding a test for 0 and 100% duty before setting the output:

if timer overflowed to zero (interrupt):

toggle the flag

if the flag is set:

if duty cycle is not zero, turn on the output pin

load the timer with a value of (255 - duty cycle)

else if the flag is clear:

if duty cycle is not 255, turn off the output pin

load the timer with the value of duty cycle

My AVR skills are rusty but I think a simple implementation would look like this, assuming you set up timer0 as an 8-bit timer with an overflow interrupt:

bool flag;

uint duty;

ISR(TIM0_OVF_vect)

{

flag=~flag;

if(flag){

output_pin=1;

TCNT0=(255-duty);

}

else{

output_pin=0;

TCNT0=duty;

}

}

Thanks tterev3! :+1:

TA, is this board optimized to (also) work with the new 4-channel firmware from Flintrock? I know you made this for TK, but we might like to use it in a regular flashlight too. :innocent:

I’d love to see some of our firmware people comment a bit about what tterev3 said, too (ToyKeeper, Tom, Flintrock).

It should work fine with the right firmware although it is not really setup for a flashlight and is pretty large.

All 4 of the output pins can be PWM so it is just a matter of getting firmware that takes advantage of it.

I missed David EF's post. never mind. Anyway, yeah, the code should work. It's not exactly like ttrev3 said, but similar. The PWM match is already built into the chip, so it uses a match itnerrupt and an overflow int (and I doubt you'll find smaller ones anywhere). Just the 4th waveform generator that was missing. Anyway, yeah, it should be ready to go if you're happy with preset mode ramps, and it can get the eswitch and Vcc read too. I hadn't known about this thread. I'm not that interested in sabres but it seems like a fun test case.

Well, it’s less than 26mm, so it’s large but not huge. There are some lights, especially 26650 lights, that can use that large of a driver. I did notice that it doesn’t have a ground ring. That in itself will make it a challenge to use in most lights. But, the parts selection and layout are what I was referring to when asking about the compatibility. If the circuit schematic is basically compatible, then a flashlight-friendly board can be made easily. That’s what I’m hoping for. :wink:

TA I think you'll find it pretty easy to customize the simplified attiny.h to whatever layout you've got. If really needed it is even possible to move the 4th pwm from the traditional cap pin to the traditional voltage pin, but I did not include that as a "user-visible" option.

.. or just get me some details and I'll set it up.

With the almost staggering number of mode choices available in a single firmware now (by using mode groups and config options), I think preset mixes would be a fine place to start. The modes would just need to be RGBW-level modes, versus the white-lighting-level modes we use normally.

In the future, it would be great to have a dual-switch control where one switch moves you through channels and the other operates smooth ramping (and/or typical “modes”) . Then it will just be “click A-switch” to choose which channel to change, then “click-hold B-switch” to ramp brightness of that channel (or “click B-switch” to use preset “modes”), then back to “click A-switch” to select the next channel and continue. I don’t know how hard this will be to write and I don’t want to make demands on anyone’s time. It’s just a dream of mine for now. :innocent:

Yeah, that's going to need hardware support. You've got to get that second switch on the reset pin. From a software perspective, it's easiest if it's normally high, and the switch pulls it down to 0.5V. I'd wire it like this:

GND <-----------------------R10--------------------------------R11------------- VCC

|

|

/ Switch

|

|

Reset Pin

Or you need two different pull down voltages on the main pin, but I think the above is simpler as far as software. Might even work without changing anything.

Depending on how things go, I might try to use a tiny841 and acupuncture or a bed of nails for flashing. That would provide more pins and a newer MCU. I’ll probably also try to align the LED connections directly under the holes in the heat sink, so a short wire can go directly up to each emitter and the board itself can be pressed against the heat sink.

I just need to learn a PCB layout tool first. :slight_smile:

That’s all for later though. For now, I can get things like 90% done (and make a working saber) with the provided layout.

All of my designed come with the source files that are pretty easy to edit once you get the software. Sadly for you, I don’t think diptrace is on linux but you could most likely use a virtual machine or even wine.

I figure I’ll probably use KiCad. It’s what my Linux circuit geek friends recommended, and Oshpark supports its files directly. It appears to be a little on the complex side compared to some, but it also appears to be pretty powerful. And I’m not doing anything particularly complicated, so I don’t have to be picky. :slight_smile:

Before that though, I have some firmware to write. So much firmware. And parts to order. And tools to try.

If you are starting on a new MCU anyways, I HIGHLY recommend the 1617 mcu : http://www.mouser.com/ProductDetail/Microchip-Technology/ATtiny1617-MFR/?qs=sGAEpiMZZMvqv2n3s2xjsdZc02topxxIyb2htVHofo5O1dwzOibzLA%3D%3D

It is what I think flashlights should and will be moving to in the future. It offers many advantages with no cost increase or other downsides if learning a new chip anyways.

I mean 16kb and 22 i/o pins, whats not to like and thats before you really dig into the spec sheet. It also has multiple reference voltages making it much simpler to create a driver that can work with any input voltage.