How To Build a Flashlight With Perfect Modes (picture heavy)

818 replies [Last post]
Tido
Offline
Last seen: 26 weeks 1 day ago
Title: ★★
Joined: 05/28/2010
Posts: 185
Location: Berlin, Germany

So, you want a flashlight with modes that are just right but can't find the one, no matter how hard you look? You are especially craving for a light that can be programmed with light levels ranging from hardly visible to full blast can't-see-anything-but-dark-spots-for-a-few-minutes when accidentally shone into your eyes? Onna stick In a P60-style host? Well, today's your lucky day.

Building It

First, you will need to organize a few parts. From left to right, the NANJG 101-AK pimped with a fourth AMC7135 (other µC-controlled driver PCBs might also work), an XP-G R5 and a P60-style reflector with brass pill from KD.

 

 

 

 

Next, you sit down and write your own driver for the micro controller on the PCB. If you are lazy and have a PCB run by the ATtiny13, you might get the brand spanking new Budget Light Forum Versatile LED Driver and skip this step.

 

 

 

 

Now you flash the µC with your program...

 

 

 

 

...and assemble your flashlight. 

 

 

 

Et voilà! 

 

 

 

Testing It

Now let's take this baby for a test drive. First, highest output, picture taken with ISO 100, f/3.5, 1/25 sec.:

Nice!

 

 

 

 

Next up, lowest mode, same camera settings:

 

 

 

 

Is this thing even turned on? Let's take a look:

 

 

 

 

Well, maybe we need a longer exposure time. 30s should be plenty, right?

Hmmm well, let's just say it's really low.

Conclusion

Okay, I'll admit it, I'm just plugging the new open source driver for ATtiny13-controlled driver PCBs I just released. Since I got the idea for this project while reading BLF, I named it the Budget Light Forum Versatile LED Driver. I hope it can live up to its name. Some technical Notes: It can be built in two ways, either as programmable, like the Akoray K-106, giving you up to ten user programmable constant light modes (no strobes, SOS etc.). If built as fixed, up to ten modes can be defined at compile time, including all the fancy blinking stuff. And yes, it does a really low low mode. During testing it took my eyes almost a minute to adapt enough to the darkness just to find the spot on a white wall less than two meters away. If you think you might have a use for this, fetch your copy here and tell me what you think. All constructive criticism is welcome.

 

Edit: Updated links to the current version. Links to older versions: v0.1 v0.2 v0.3


SPAMBOT
SPAMBOT's picture
Offline
Last seen: 2 years 41 weeks ago
Title: ★★★
Joined: 07/16/2010
Posts: 466
Location: Old World
That is some seriously sexy

That is some seriously sexy stuff!

Now I just have to learn how to flash µC's ^_^

__________________

Now with all natural asbestos!

brted
brted's picture
Offline
Last seen: 3 days 3 hours ago
Title: ★★★★★
Joined: 01/12/2010
Posts: 2164
Location: Atlanta
Nice work!

So you can re-program the ATMEL chip while it is still in place? How much for the board? I guess it's USB? Seems like you could make some money selling custom drivers. People love the K-106 just for the programmable modes, so if you can program that in there (with ramping and everything?) then you've really got something.

Have you got it where it can have mode memory?

. . . . Later on a Wiki was started to help get people started on this:

http://flashlight-wiki.com/AVR_Drivers

Aleister
Aleister's picture
Offline
Last seen: 13 weeks 2 days ago
Title: ★★★
Joined: 10/23/2010
Posts: 440
Location: Greece
Very impressive! Where do you

Very impressive! Where do you find a "flasher" like the one you use? And which drivers can we use?

 

 

 

 

 

 

__________________

My flashlight has only 2 modes, day and night...

Tido
Offline
Last seen: 26 weeks 1 day ago
Title: ★★
Joined: 05/28/2010
Posts: 185
Location: Berlin, Germany
brted wrote:So you can
brted wrote:

So you can re-program the ATMEL chip while it is still in place?

Yes, it's in system programmable (ISP). As long as the security fuses aren't set, it can be reprogrammed this way.
brted wrote:
How much for the board? I guess it's USB?
The programmer is an AVR Dragon with the Dragon Rider extension board on top of it. This combo can be bought for around $90, but it is a system designed for development and education. Simple ISP programmers cost less than $20.
brted wrote:
Seems like you could make some money selling custom drivers.
Unless you're living in Germany, where it takes insane amounts of paperwork to sell anything in a commercial manner Wink
brted wrote:
People love the K-106 just for the programmable modes, so if you can program that in there (with ramping and everything?) then you've really got something.

Have you got it where it can have mode memory?

Yes, modes can be user-programmed like the K-106 (at least the way I think it is done there, I don't own one). Whether the driver provides mode memory or starts up in the first mode slot can be determined at compile time by setting or unsetting a #define in the source code.
Tido
Offline
Last seen: 26 weeks 1 day ago
Title: ★★
Joined: 05/28/2010
Posts: 185
Location: Berlin, Germany
Aleister wrote: Very
Aleister wrote:

Very impressive! Where do you find a "flasher" like the one you use? And which drivers can we use?

You can find ISP-capable flashers for AVRs for a few bucks on ebay (search for AVR and ISP), but it takes a bit of knowledge to set up the necessary tool chain. Don't expect to just plug the thing into an USB port and press a button. Also, if you don't want to solder leads to the chip's pins, you'll need a debugging clip like the one I use. One of those will cost twice as much ($18 shipped from Hong Kong) as the cheapest programmer you can find Wink In theory this driver should work with any ATtiny13-based board that uses the µC solely for regulating the light output via PWM. I've developed and tested it on the NANJG 101-AK. Another likely candidate is the AK-47, but I don't have one here to test it.
agenthex
agenthex's picture
Offline
Last seen: 45 weeks 4 days ago
Title: ★★★★★
Joined: 07/14/2010
Posts: 3024
Location: Merica
Hey Tido. I see that you used

Hey Tido. I see that you used a bunch of conditional #def's to get the right functionality (to the point of changing function headers). Is this done for any inherent reason or just a preferred embedded programming style? Seems like the way you split functionality to Programmable vs Standard, it's almost better to to have two programs/mains (if memory is an issue) that #include any standard functionality.

 

Also, have you tried or considered using the brownout detection for mode mem? I actually like the way you do memory better because it makes sense to me, but I think memory in many of the chinese lights set when you have the light off for a certain period, and I'm not really sure how they pull that off with just the brownout detection (ie discriminate between a short brownout and long one, do they use a cap to keep controller on but "browned out" or something?).

 

Thanks a bunch for doing this and releasing the code.

__________________

Reading this makes you smarter: http://lesswrong.com/

agenthex
agenthex's picture
Offline
Last seen: 45 weeks 4 days ago
Title: ★★★★★
Joined: 07/14/2010
Posts: 3024
Location: Merica
Well, I answered one of my

Well, I answered one of my own questions. I looked at the hex files and you're pretty close to the 1k limit. Seems programmable + other modes is out unless you get clever, like define the blinking modes as a short set of parameters and incorporate them into the same pwm set function.

__________________

Reading this makes you smarter: http://lesswrong.com/

Tido
Offline
Last seen: 26 weeks 1 day ago
Title: ★★
Joined: 05/28/2010
Posts: 185
Location: Berlin, Germany
Things aren't set in stone,

Things aren't set in stone, this is an alpha release, probably even more of a demonstration of what can be done. I'm not really happy about the programmable/fixed situation, but it was the only way to cram all the functionality into the tiny program flash without writing separate drivers.

Right now I'm not sure if I really want to keep the programmable light levels. After all, it's very hard to see a difference between, let's say, 75% and 80%. What is so attractive about the programmable light is probably not the fine grained control over light levels, but the ability to arrange the modes in a preferred order. Maybe it would be better to offer a number of fixed modes spaced at reasonable levels (e.g. 1%, 5%, 15%, 30%, 50%, 75%, 100%, strobe, beacon, whatever), from which three can be chosen in any order and stored into the mode slots (and the others could still be made available through a special click sequence). I'd be happy to hear some opinions on this.

Edit: Mode switching through brown-out detection is not planned so far. This would depend on the specs of external components (namely, the buffer cap) and right now I'm trying to keep this dependent only on the micro controller used.

sixty545
Offline
Last seen: 3 hours 4 min ago
Title: ★★★
Joined: 10/25/2010
Posts: 477
Location: Denmark
Awesome! I downloaded from

Awesome!

I downloaded from here and managed to make an identical hexfile to yours in the folder Fixed Modes, so something must be right. Can this one be used to flash it into an AK47?

I would like to make a driver with a logarithmic scale of levels such as:

12,5% - 25% - 50% - 100%  or one with:

11% - 33% - 100%

Thanks, Tido

Tido
Offline
Last seen: 26 weeks 1 day ago
Title: ★★
Joined: 05/28/2010
Posts: 185
Location: Berlin, Germany
The programmer looks usable
The programmer looks usable and at $11.50 delivered you're not taking much of a risk anyway. I don't know if the AK-47 is locked down, so you'll just have to try.

As for the modes, you might want to start lower. I used a PWM value of 16/255 for MODE_LOW, which is about 6% of maximum, and for me it is on the upper end of what I would want as a low mode. Of course the AK-47 uses only 3x 7135, so output would be about 25% lower than on the 101-AK. Just experiment and play around with the values a bit, that's what open source is for Smile

Vectrex
Vectrex's picture
Offline
Last seen: 6 weeks 3 days ago
Title: ★★★★★
Joined: 05/01/2010
Posts: 2717
Location: Gemany (according to my Black Cat)
Erleuchtete Grüße Tido, I

Erleuchtete Grüße Tido,

I have already seen some of your posts on messerforum.net and geocaching.de, cool stuff you are doing with your µC-programmer.

Keep on going, maybe we can find a flashlight manufacturer to implement one of those programmable drivers of yours into a custom BLF light.

MrLite comes to mind, since they offer a reprogramming service for almost all their lights.

agenthex
agenthex's picture
Offline
Last seen: 45 weeks 4 days ago
Title: ★★★★★
Joined: 07/14/2010
Posts: 3024
Location: Merica
Mode switching through

Mode switching through brown-out detection is not planned so far. This would depend on the specs of external components (namely, the buffer cap) and right now I'm trying to keep this dependent only on the micro controller used.

Do you know at least how they do it? According to a brief glance through this http://www.atmel.com/dyn/resources/prod_documents/doc1051.pdf, it seems the brownout reset would be triggered regardless. So I presume the program counter (part of general registers?) is retained through the brownout so they can discriminate by the entry point after power is resumed?

 

Also, where did you get the right clip? I think I have a wider/larger one somewhere but it might not fit on that circuit/pitch. I haven't done any real electronics stuff in a while.

 

As for picking modes, a big list of fine pwm ratios (you can stack them more densely in the eeprom, or just calcuate them) in programming mode that you can pick up to 3 from (using a n-click UI you already have) would be really nice. For example, I can envision doing the 6click to get to programming mode, clicking through the many modes, and 3clicking to pick out up to 3 modes consequtively. Since you write to a mode slot in eeprom and increment every time, it's safe to stop halfway through to re-pick just the first mode so it's not tedious. You can even stack on SOS modes in the programming phrase but that would still spill over 1k unless it was optimized a bit more.

 

__________________

Reading this makes you smarter: http://lesswrong.com/

agenthex
agenthex's picture
Offline
Last seen: 45 weeks 4 days ago
Title: ★★★★★
Joined: 07/14/2010
Posts: 3024
Location: Merica
My bad. I just found the doc

My bad. I just found the doc folder with the readme, which kind of helps. :)  You've already implemented the multiple slots. It wasn't clear just looking at the code.

 

I think the UI to do the programming is a bit tedious. Even what I described above is unnecessary. The programming can be done based on what mode/slot the user was already in.

 

For example, I'm in a mode/slot, and I'd like it to do something else. I 6click or whatever to go into programming, move through the modes to one that I like, 6click to leave programming, and that last level/mode I was in should be what I choose. Might need to be a tad clever (need x-click to be multiple of # of modes or something) to discern what mode I was in originally, but this UI would be simple and easy to remember.

__________________

Reading this makes you smarter: http://lesswrong.com/

Vectrex
Vectrex's picture
Offline
Last seen: 6 weeks 3 days ago
Title: ★★★★★
Joined: 05/01/2010
Posts: 2717
Location: Gemany (according to my Black Cat)
I have a spare AK-47 here...

I have a spare AK-47 here... it looks like this... received 2 or 3 weeks ago from DX... do you think it would be programmable Tido?

ATMEL 1022

TINY13A

Δ SSU

Tido
Offline
Last seen: 26 weeks 1 day ago
Title: ★★
Joined: 05/28/2010
Posts: 185
Location: Berlin, Germany
I think the programming UI

I think the programming UI needs to be a bit complex to prevent accidental re-programming. If you can re-program by just clicking away, you will end up with garbled modes more often than you'd like. Especially with the time-switched-on kind of mode switching, where it doesn't matter for how long the light has been switched off. It's easy to end up in programming mode by repeatedly using the light for less than two seconds, let's say for finding the key hole every day. I think the light should behave completely different the moment it enters programming mode and changing anything must require some sort of timed action by the user. If he just keeps clicking or does nothing, programming has to be aborted. This may make programming a bit tedious, but how often are you going to re-program the modes?

 

As for the brown-out switching, from the programming point of view, the only difference between a normal and a brown-out reset is the set BORF-flag in the MCUSR register. You can check at start-up whether the flag is set and act accordingly.

 

I got the programming clip from ebay, but the vendor I got it from isn't offering them any more. Search for "SOIC8 clip", there are a few available from other vendors.

 

 

 

Tido
Offline
Last seen: 26 weeks 1 day ago
Title: ★★
Joined: 05/28/2010
Posts: 185
Location: Berlin, Germany
Vectrex, there's an ATtiny13

Vectrex,

there's an ATtiny13 on the board and it's connected to the 7135s via PB1, so it should work with my program. The only question is whether the chip is still programmable. The only way to find out is to try it.

agenthex
agenthex's picture
Offline
Last seen: 45 weeks 4 days ago
Title: ★★★★★
Joined: 07/14/2010
Posts: 3024
Location: Merica
Sorry I don't have the code

Sorry I don't have the code in front of me, but can you use a mechanism to time the consequetive clicks? Like 6 clicks within 3 sec or something, which doesn't seem like typical user behavior. I personally think it's bad idea to require a manual for programming a flashlight. My experience is that people tend to avoid complex UIs.

 

Where did you get your nanjg? dx or kd? I just bought from dx.

 

Also, can you check if maybe a SOIC 16 clip would fit, clearing the other components?

__________________

Reading this makes you smarter: http://lesswrong.com/

Oxy Moron
Oxy Moron's picture
Offline
Last seen: 2 years 19 weeks ago
Title: ★★★★
Joined: 03/24/2010
Posts: 801
Location: USA
Very, very cool.   Tido

Very, very cool.

 

Tido wrote:

Right now I'm not sure if I really want to keep the programmable light levels. After all, it's very hard to see a difference between, let's say, 75% and 80%. What is so attractive about the programmable light is probably not the fine grained control over light levels, but the ability to arrange the modes in a preferred order. Maybe it would be better to offer a number of fixed modes spaced at reasonable levels (e.g. 1%, 5%, 15%, 30%, 50%, 75%, 100%, strobe, beacon, whatever), from which three can be chosen in any order and stored into the mode slots (and the others could still be made available through a special click sequence). I'd be happy to hear some opinions on this.

 

I can only speak for myself here but that is exactly what I want. I really don't need a gazillion different modes (which hasn't stopped me from buying lights that have about a million and one modes, but I digress) and even though I appreciate the ability to have absolute control, I don't really need that either. I know people who won't dare play with their (programmable) K-106s for fear of losing their moonlight/really darn low mode after they managed to get it just the way they wanted it. Having a bunch of reasonably spaced defaults would probably go a long way to improve usability.

Tido
Offline
Last seen: 26 weeks 1 day ago
Title: ★★
Joined: 05/28/2010
Posts: 185
Location: Berlin, Germany
agenthex wrote: Sorry I don't

agenthex wrote:

Sorry I don't have the code in front of me, but can you use a mechanism to time the consequetive clicks? Like 6 clicks within 3 sec or something, which doesn't seem like typical user behavior. I personally think it's bad idea to require a manual for programming a flashlight. My experience is that people tend to avoid complex UIs.

3 seconds in "absolute" time (on and off)? No, I can only record the time the light has been switched on.

 

agenthex wrote:

Where did you get your nanjg? dx or kd? I just bought from dx.

DX. Although they seem to sell board of different specs over time. One I bought over a year ago and used for several tests and projects is flashable. From the two I bought a few months ago, only one can be flashed and even that took a lot of tries initially. The other one won't even be recognized by the programmer. The two from the latest batch I received a few days ago gave me no problems at all.

 

agenthex wrote:

Also, can you check if maybe a SOIC 16 clip would fit, clearing the other components?

I don't think a SOIC-16 clip will work. I tried moving the SOIC-8 clip two pins to the left and right and it won't clear the chips on either side.

agenthex
agenthex's picture
Offline
Last seen: 45 weeks 4 days ago
Title: ★★★★★
Joined: 07/14/2010
Posts: 3024
Location: Merica
No, I can only record the

No, I can only record the time the light has been switched on.

 

Currently, you have the watchdog timer set to 2 sec and clearing clicks after this. As a practical matter, maybe using 1 sec for this and mode mem is a workable trade off?

 

If more than one timer is possible, or something to similar effect, you can also set a shorter timer to count the number of consecutive short ON periods (decrement clicks if longer) as a reasonable approximation of fast clicking. I can't think of non-pathological use cases that would violate this, especially with reverse clickies.  I suppose in the worst case this also works if we're willing to give up mode memory.

 

I don't mind buying a cheapo USBasp like the one above, but buying another $20 clip seems a bit excessive for just this one project (especially too many what-if's with drivers from dx). How many of the pins are active for programming? Would it be possible to just use a few generic probe/hook type clips?

__________________

Reading this makes you smarter: http://lesswrong.com/

Tido
Offline
Last seen: 26 weeks 1 day ago
Title: ★★
Joined: 05/28/2010
Posts: 185
Location: Berlin, Germany
agenthex wrote: Currently,

agenthex wrote:
Currently, you have the watchdog timer set to 2 sec and clearing clicks after this. As a practical matter, maybe using 1 sec for this and mode mem is a workable trade off?

If more than one timer is possible, or something to similar effect, you can also set a shorter timer to count the number of consecutive short ON periods (decrement clicks if longer) as a reasonable approximation of fast clicking. I can't think of non-pathological use cases that would violate this, especially with reverse clickies.  I suppose in the worst case this also works if we're willing to give up mode memory.

Sure, it would be possible to record, for example, that the light was turned on 1, 2 or 5 seconds the last time. But if we started making distinctions, we'd end up with something like "turn light off within a short period of time to do A, and to do B, turn it off within another, but different, period of time". That would be very confusing.

The problem is that the same action is used for different things. Turning on for a short time (let's call this a 'tap' for now) means either changing modes or, if done repeatedly, going into programming mode. Maybe a single tap shouldn't immediately start changing modes, but instead be used for shifting functions? Let's say, a single tap does nothing. Two taps get you into mode shift, where you can cycle through the programmed modes, four taps let you cycle through all available modes and six taps get you into mode programming. The main problem with this approach is that people unfamiliar with this UI will be very confused.

agenthex wrote:

I don't mind buying a cheapo USBasp like the one above, but buying another $20 clip seems a bit excessive for just this one project (especially too many what-if's with drivers from dx). How many of the pins are active for programming? Would it be possible to just use a few generic probe/hook type clips?

ISP programming uses four control/data leads plus power and ground. If you're willing to temporarily dedicate a driver PCB to development (and have a steady hand), you could just solder leads to the pins and terminate them in ATMEL's standard 2x5 ISP plug. This way you could simply plug it into the USBasp. Or if you just want to play around with the program logic, you could use something like this:Breadboard

(ignore the upper half of the board, that's a loftover from a different project). I'm using a normal DIP ATtiny13 for developing the program logic and only use the driver PCB for testing with real light levels. Keeps the risk of being blinded by accidental mode changes to a minimum Wink

agenthex
agenthex's picture
Offline
Last seen: 45 weeks 4 days ago
Title: ★★★★★
Joined: 07/14/2010
Posts: 3024
Location: Merica
The problem is that the same

The problem is that the same action is used for different things.

 

What I meant was short-click detection just makes the entry point to the programming state less ambiguous (which you described as a problem). A "short-click" is just a practical timed cut-off for each click before the code resets the count var, not anything to be measured time-wise. I don't mean to change the general paradigms discussed.

 

So, IOW what I proposed is still:

1. select mode you want to re-program

2. signal 6 shortclicks to enter programming

3. click through mode options just like any other mode light and stop on the one you want

4. signal 6 shortclicks to set and exit

 

Same as before, but you won't enter 2 as easily by accident which I agree is possible with the existing way count is done. The problem with the above might be that 4 needs to be disambiguated from possibly clicking through the modes quickly in 3. Should this be a problem, perhaps replace "6 shortclicks" with some other sequence (short-long-short?), but make it the same sequence so the user has to remember just one special signal to program the light.

 

To summarize, I think this minimizes the principles the user has to remember. It's basically down to:

 

2 states, general use state, and programming state

1 signal to enter or exit programming state

click to move to next light mode.

 

 

That's all they have to know, more or less.

The main challenge is a signal that is unambiguous, not impossible to tap out,  and allows us to know which mode they were in before they started signaling.

 

If anything above doesn't make sense, please feel free to PM me and we chat over IM or something.

---

So I suppose step-through debugging works well with your tools? I can't imagine trying to write that program without it, especially with printf's in morse. Smile

__________________

Reading this makes you smarter: http://lesswrong.com/

agenthex
agenthex's picture
Offline
Last seen: 45 weeks 4 days ago
Title: ★★★★★
Joined: 07/14/2010
Posts: 3024
Location: Merica
I've contacted the supplier

I've contacted one supplier in china, and he's now offering SOIC 8 clips in 1pc quanties for $10 shipped. This comes with the 10pin cable which is perfect for the USBasp's, and it's about half the price of anything else on ebay.

 

http://cgi.ebay.com/ebaymotors/ws/eBayISAPI.dll?ViewItem&item=400171159037

__________________

Reading this makes you smarter: http://lesswrong.com/

agenthex
agenthex's picture
Offline
Last seen: 45 weeks 4 days ago
Title: ★★★★★
Joined: 07/14/2010
Posts: 3024
Location: Merica
On avr programmers, it looks

On avr programmers, it looks like the dragon board is probably the cheapest for anything with debugwire. In your opinion, is it worth getting debug capability for playing around with this or other simple projects?

__________________

Reading this makes you smarter: http://lesswrong.com/

Tido
Offline
Last seen: 26 weeks 1 day ago
Title: ★★
Joined: 05/28/2010
Posts: 185
Location: Berlin, Germany
So far I didn't need the

So far I didn't need the Dragon's debugging functionality for this project, or, since this is my first µC project, for anything else. The code execution path is simple enough (always ends in an infinite loop somewhere) that it's easy to spot when it goes wrong somewhere. I'm sure I'll soon be using it for some other, more complex project coming along, but for this it would be overkill. One feature I did need was high voltage programming to unbrick the chip after setting the wrong fuses.

 

So, if you plan to do other things with it than just this project, get the Dragon, it's terrific value for money. Otherwise you'll probably be fine with the USBasp (as long as you always make double-sure the fuse bits are set correctly Wink).

 

On another note, I tried out the mode programming sequence you suggested. The first part (start from the mode you want to program, click x times, then select new mode from the extended list) works and is intuitive, but I'm not sure about the part where you store the selected mode by clicking again x times. I still think acknowledging should be done with some sort of timed sequence.

brted
brted's picture
Offline
Last seen: 3 days 3 hours ago
Title: ★★★★★
Joined: 01/12/2010
Posts: 2164
Location: Atlanta
Nice find on the clip,

Nice find on the clip, agenthex! I might have to give this a try. What do I need to run Tido's software?

sb56637
sb56637's picture
Offline
Last seen: 5 hours 31 min ago
Title: ==Administrator==
Joined: 01/08/2010
Posts: 4474
Location: The Light
Fascinating post, Tido! Very

Fascinating post, Tido! Very well done. Frontpage'd and Sticky'd.

__________________

Budget Light Forum ...where Frugal meets with Flashlight!

agenthex
agenthex's picture
Offline
Last seen: 45 weeks 4 days ago
Title: ★★★★★
Joined: 07/14/2010
Posts: 3024
Location: Merica
What do I need to run Tido's

What do I need to run Tido's software?

 

Easiest way is you need that clip to go from the chip in the light to something to propgram it. The cheapest programmer is the USBasp linked above for ~$10. Or the USBTinyISP for about the same, or the Pololu for ~$20. I think I might get the latter (or the AVR Dragon) because it claims to be directly compatible with AVR studio, the official Atmel tool.

 

The software for this is free. For the toolchain, you get WinAVR (tool/compiller collection) + AVRStudio (gui/ide) for the dev environment. Studio can program the dragon or pololu (supposedly clones an AVRISP), or you use AVRDude that comes with WinAVR to program the two cheaper programmers.

 

I think the above is correct from my web browsing, but I'm a little behind Tido with zero ucontroller projects under the belt Smile.

__________________

Reading this makes you smarter: http://lesswrong.com/

agenthex
agenthex's picture
Offline
Last seen: 45 weeks 4 days ago
Title: ★★★★★
Joined: 07/14/2010
Posts: 3024
Location: Merica
but I'm not sure about the

but I'm not sure about the part where you store the selected mode by clicking again x times. I still think acknowledging should be done with some sort of timed sequence.

 

I thought a bit today about this today, and I still think it's possible to make this work as long as there are no technical hurdles. The essential part is down to tuning the timing. For example, when a user is just clicking through real modes, they're likely to at least pay attention to what the level/mode is. That means they're unlikely to stay in every mode for less than 1 sec that many times in a row (human reaction time is like ~1sec). On the other side of that range, you also don't want to require users to click furiously just to get into the programming state. I think a  <1/3-1/2 second limit may be too demanding. So setting the ON timer to somewhere in between 0.5 and 1.0 seconds seems best.

 

Another angle to the above is to find reasonable cases where the user might accidently drop out of programming (the other case of entering into is taken care by the fact they have to click/cycle through the equivalent of all modes twice to get into programming). For example, if there are loads of the same type of levels (like >10 continuous levels), the user might habitually click through all of them quickly to get the highest or whatever. I think this might be mitigated by squeezing from both sides. One is to limit the number of continuous modes; the other is to increase the number of continuous clicks required. A reasonable solution might be to limit the number of selectable continuous modes to 7-8, and increase the number of clicks to 8 (conveniently giving the user 4 normally selectable modes).

 

Of course it's possible that all the above combined might not work for whatever reason. I thought about what would be an intuitive signal. Requiring the two "changes" in timing like 2short clicks, 2 long, then 2 short seems like difficult acrobatics. 1 change seems reasonable, for example 4short 2long. This kind of requires measuring on time, at least to 2 levels, so I'm not sure how you do that. Maybe set the timer again after first callback? One issue is that the counting can be confusing to users, especially given the way it's implement; it's doubly so if they use fwd clicky vs. reverse clicky. Regardless, I still strongly believe there should be one signal that they learn, and it should be the easiest one that can work. Conceptually I think the right way to picture this is that there's ideally a recessed programming state button on the flashlight, but we're doing this because we only have 1 button to work with and have to find some replacement/alternative for that second button.

 

Welcome to the world of UI design, where everyone has their opinion and the way to get it right is to keep iterating Smile.

 

BTW, do these guys keep the chip at the default 1 mhz, so you're getting like 4khz on the pwm? Surely it's lower?

__________________

Reading this makes you smarter: http://lesswrong.com/

Tido
Offline
Last seen: 26 weeks 1 day ago
Title: ★★
Joined: 05/28/2010
Posts: 185
Location: Berlin, Germany
  I thought a bit today about

 

I thought a bit today about this today, and I still think it's possible to make this work as long as there are no technical hurdles. The essential part is down to tuning the timing. For example, when a user is just clicking through real modes, they're likely to at least pay attention to what the level/mode is. That means they're unlikely to stay in every mode for less than 1 sec that many times in a row (human reaction time is like ~1sec). On the other side of that range, you also don't want to require users to click furiously just to get into the programming state. I think a  <1/3-1/2 second limit may be too demanding. So setting the ON timer to somewhere in between 0.5 and 1.0 seconds seems best.

Having taps of different length is no problem. The watchdog triggers repeatedly, so we could set it for 250ms and count the ticks in the ISR. To get the kind of tap, we just have to store a marker for "short tap" in eeprom on start up. When the ISR reaches 4 ticks, it overwrites the marker with "long tap" and at 8 ticks it clears it altogether.

The current development version uses 2n (where n is the number of programmable slots) taps to mark a mode slot for programming and go into extended mode selection. There you can cycle through all available modes. Staying in one of those modes for more than two seconds will select it as the new chosen mode. Next time the light is turned on, there is a timed sequence where the new programming can be acknowledged or discarded before the light returns to its normal mode of operation.

This sequence could be quite inconvenient for people who, for example, use a strobe mode from time to time, but don't want to waste a mode slot on it. They could just go to the extended selection, use that mode and abort the programming afterwards. The problem here is that the next time the light is turned on, they have to wait a few seconds before it can be used in the usual manner. By using a tapping sequence like short-short-long-short, this wait could be eliminated. When returning from extended mode, mode switching would immediately work as usual and only if the sequence is used, the slot is reprogrammed. The chances of accidentally hitting this sequence would be quite small, as people tend to switch through the modes at a constant rate. I think I will give this a try.

 

Welcome to the world of UI design, where everyone has their opinion and the way to get it right is to keep iterating Smile.

Yes, I know. That's why I kept to things like hardware architecture, low level drivers, automation and networking protocols at uni and stayed well clear of anything needing direct user interaction. It's such a drag to spend hours on something that doesn't really do anything of the interesting stuff Wink

 

BTW, do these guys keep the chip at the default 1 mhz, so you're getting like 4khz on the pwm? Surely it's lower?

It depends on the batch from which your driver comes. The first I got ran at 1MHz. The second I don't know, as I never managed to read the fuses and the latest batch ran at 9.6MHz. I set mine to 4.8MHz, as this makes ISP programming easy, delivers very high PWM frequency and guarantees reliable MCU operation down to ~2V.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.