Thanks! I’ve been out on sort of a personal holiday (went out and played with the butterflies), but I should be able to add it soon.
Use DELAY_TWEAK to adjust the speed. The MCU clock speed is only spec’d to be accurate within about 5%, and I’ve found it’s often even worse than that. One MCU will do 70 seconds per minute while another does only 55 with the same code. So, you might need to adjust that value to get the timings right. I tried to give it a rough average as default, but I’ve seen anywhere from 850 to 1050 cycles per ms.
The output percents change based on the maximum power level — it will be different on a single XP-E2 versus XP-L versus a triple. This is because the 7135 chip runs at a fixed power level but the FET does not, so their relative contribution to the total changes with different emitters.
Because of this, the levels need to be re-calculated (and the source recompiled) for each class of light it’s used in, and a percent value would only apply to a specific combination of hardware. I calibrated the default to be visually linear (cube root model) on the BLF A6, with up to 140 lm on the 7135 and up to 1400lm on the FET. I estimated the initial values then tweaked it until my light box showed the desired results.
As for PWM on turbo, I picked those settings because they measured the highest in my light box. Specifically, FET plus 7135 together produced less light than the FET alone. And I vaguely recall someone (comfychair?) measuring max output curves on fast vs phase mode with a high-speed scope, deciding that phase was slightly better.
Yes, it should work… aside from that issue you found.
Thanks for reminding me about that. I should probably release an update with a compile switch for it like what you made.
Youch, that sucks! I’ve reflector-shorted things enough times that now I always cover the bottom of the reflector with kapton tape. Then again, I also usually test out a build on a bench power supply at low amperage before I try it with a real battery.
This really depends on what you are doing. The power from the ISP is enough to power the MCU, so if you’re testing start up routines like off time cap testing and brown out detection you should unclip it.
It’s a pain in the * to unlcip ’em all the time. That’s why I built this setup with relays that vex_zg donated after showing me his solution. Now I just press a button to unclip:
Nice! That certainly beats my cheap setup… I just have a few different drivers attached via long wires to decapitated hosts, with extra wires soldered on to connect a battery by hand. I have to clip the clip each time, and frequently hold it in place during flashing because it won’t stay on its own.
So, what I have is cheap, compact, and only took a few minutes to make… but it’s also inconvenient. I hope you don’t mind if I drool a little over your dev setup.
I’ve posted this in another thread, but it’s relevant here. This is what I use to test features and develop firmware. It can be powered from a battery or from the programmer. The 7135’s on the nanjg aren’t connected to anything. The only problem with it was that I had to unplug and replug the usb cable to reset the programmer sometimes before I could flash the attiny. I think maybe the pwm creates too much noise for the programmer or it tries to read it as a signal and gets confused. I’ve added a reset button to the programmer so I can just reset it instead of unplugging it. The microswitch disconnects ground/negative so pressing it acts like a half-press on a flashlight. I made it after getting frustrated with disassembling my edc light and using a makeshift clip to program it every time I wanted to test something.
I have to reset the programmer occasionally, but it works fairly well and allows me to test features a lot more quickly.
Yep. Gotta thank vex_zg for it. He showed me his setup and had relays to spare. It saves a lot of time.
I was starting to get aching hands after all unclipping… well, almost.
The photo is slightly old, I’ve added a little to the setup. I’ve attached a SIOC14 clip to the remaining pins the relays so I can just as easily program the ATtiny24/44/84. Button pushed is the SIOC8 clip, button released is the SIOC14 clip. The other button is just a convenient power button not attached to the relays.
One thing nice about connecting the programmer with that color, 40-wire ribbon is that you have lots of extra wire to fool around with stuff like this.
For now, I added something like that to the INDEX file. It lists each project with a one-line description, pulled from the ‘meta’ files in each project directory. The meta files aren’t all complete though, or reviewed by the owners of the projects they describe.
hex files for me is difficult - there's so much tweaking that needs to be done now, depending on the driver board. Plus I got a zillion mode combos goin on... Wish I had a super batch build job that I could run to generate all possible combos, but might result in dozens . Basically I have to mod the source code for every build - very little direct re-use.
Well my youngest Son is going to Michigan Tech next year for computer engineering maybe I can talk him into helping out. LOL
I actually went to college for computers in 1987 and was learning a little bit of this kind of thing before I dropped out. I was pretty good at math but doing math in hex was something else! Probably don’t have to do that anymore?
Too much partying, chasing girls and that kind of stuff and that was it for me. Went back after leaving the military but not for computers. Still I’ll have to give compiling hex files a shot here in a while. For now I’m just happy to be building some of my own drivers. I should have started last year this time maybe by now I would have something to offer instead of mooching from you guys.
I generally mod the source for each build, tweaking modes and levels and values and so on. I copy the original source file to one named after my light or named after the person I’m building it for, tweak it, build it, and keep the files around for later reference… but I don’t add them to the code repository unless there are significant functional changes.
It’s nice that STAR and guppydrv allow the end user to change the configuration, but the attiny13a is so limited that even those firmwares need to have a few different builds to support different types of lights and drivers. And the majority of the limited space goes to runtime configuration options.
But code which isn’t designed for runtime configurability… will generally need to be recompiled for each light and each person instead of using a pre-built hex file. And if it’s only modified within its intended range, like tweaking the #defines, I don’t find it worthwhile to commit that change to the repository.
Basically, take the default #defines as an example, a suggestion. But you’re usually supposed to change those and rebuild for your personal needs.
- I started out as an EE major in '75 after high school. took my first computer course of Fortran on cards (don't drop the deck!), and later dropped out, then went back to a tech school for programming, then continued CS courses at night. Never got a BS degree but took all the CS courses... in about '81, bought the IBM PC - 1st version, DOS 1.0, etc. for like $3,500, stripped down. Added my own memory chips to get it up to 64KB - the fun began...
That is very cool. Our high school had apple computers in the mid 80’s and I could do the “if and then” statements with the best of them and ended up being the teachers assistant my senior year.
The first time I saw a computer was at my Mother’s job. She worked for a place in Saginaw Mi. that did the payroll for the City and a bunch of other large businesses. I remember going there to see the huge rolls of tape and all of that. I’m sure that was Fortran and probably some of the very earliest commercial use of computers. Time-cards turned into paychecks, I think the place was called Fullerton if I remember correctly.
Funny for me really, considering we are family of farmers. But farming is more and more high tech now. I sold feed for a while and we used a program out of Michigan State for figuring out the optimal feed requirements for dairy cows. We tested all of the feed grown on the farm and then balanced that with the stuff we sold. My Father sold fertilizer and they did the same thing for that. My Grandfather could do the math in his head faster though. LOL
In '78-early 80's, the job market was insane. I had multiple job offers coming out of the tech school - 6 month certificate in computer programming - oh boy... You switched jobs every 6-12 months to get a 10%-20% or greater bump each time. I got 20%+ counter offers just to stay at a couple of jobs.
All that doesn't make me an expert at Atmel/AVR programming though, so the learning never stops... It still blows me away that they can fit so many components/features into 1 tiny chip.
Here is one way to achieve customization of firmware without recompiling and only editing one hex file. The EEPROM can be loaded from a hex file. Configuration data can be put into the EEPROM hex file, edited, and programmed to the MCU. Since the EEPROM hex file is separate from the program hex file, it can be programmed by itself.
This would beneficial to those who have the equipment to program the MCU but not the software programming skills.
. Basically I have to mod the source code for every build - very little direct re-use.
