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

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.

Is that even supported in gcc yet? My copy ( gcc-avr 1:4.9.2+Atmel3.5.3-1 ) doesn’t seem to recognize it, unless it’s supported under a non-obvious name. It recognizes attiny841 though.

TK, if you want easy, I would recommend Eagle. It’s very intuitive to use and if you need to, you can use mattaus’ tutorial to get you started. It’s what most of us around here use, so if you get stuck on something, help is very near. We have lots of custom made library parts floating around here for Eagle as well. I tried looking at KiCad, since it’s included in Ubuntu’s repositories, but I couldn’t figure out how to do anything with it. Oshpark also supports Eagle files directly, and they have a design rules file for Eagle that you can download.

Good question, it is the latest MCU out so if it is not supported yet you can bet it will be soon. Although it could just simply not be in there by name yet but share the settings with another chip.

The latest AVR toolchain (3.6.0) was released in January, while the 1617 data-sheet initial release was in March.

Haven’t updated in a while, but I’ve got this mostly working now. I just have a few things left to do. Off the top of my head…

  • Improve button de-bouncing code because these saber buttons are really noisy and sometimes have pretty long leads.
  • Lay out a new PCB to make it more physically compatible with the hosts.
  • Try to eliminate some occasional timing jitter on the 4th PWM channel.
  • Add a couple more lighting effects.
  • Tweak default modes and calibration, and otherwise polish up little details.

Really not all that much left, but some of the remaining steps are going to be time-consuming.