I use the Pomona SOIC clip - works fine, again, still worked well with Nanjg's. Have you ever tried programming a completely loose MCU? It clips up fine and continuity checks out all the way back to the dongle.
The MCUs I find that work are marked "ATMEL 1324" and the ones that don't work are marked "ATMEL 1222" or "ATMEL 1121". I'm trying to find out the meaning of the #'s but no luck so far -- looking thru the ATTiny13A datasheet now...
I've done lots of BLF DD boards before and programmed them fine. Not sure though - might be getting into a new batch of MCU's - this is why I'm sort of doubting the MCU now...
Update #1: They are all marked "SSU", so I believe that's the right type.
They program fine bare. I have only experienced the opposite problem. Nanjg 105c’s from FT often don’t want to flash for me until I remove the chip from the PCB. Fresh ATtiny13A-SSU units from Mouser flash fine whether bare or mounted on a PCB. At least I think they do, I don’t keep super close track. I know I definitely flashed one of those A17DD-SO8 drivers with the MCU onboard. The PCB was w/ FET, diode, voltage divider resistors, & both caps: no problem.
I’ve been using the Pomona clip along with an USBasp I’ve had for a while, I forget the source. I’ve ordered a new USBasp from FT to see if I might get a “stronger” one. (If I do I plan to leave my current one hooked up to my ZIF socket where it always works.)
Please post the full top markings of one which is giving you trouble.
I’ve got to go to bed, but here’s a real hackjob I’ve been working on this evening. It compiles, but I don’t have time to flash it and assemble a driver before bed. There may be serious oversights.
This is intended as a proof-of-concept for a VaraPower style driver (rotary potentiometer chooses brightness) which includes low-voltage-warning and low-voltage-shutdown.
Here is what I did [thankfully not written in the order I did it]:
used “STAR_1.1.c” as a base
stripped out everything that I don’t think this style of driver needs, modes, turbo, etc
replaced the main loop with the two-way ADC loop from the Nov 4, 2014 [1263cd98f9] version of MTN_momentary_temp.c
changed the way the ADC loop switches ADC channel so that it toggles Vref back and forth as well - I think/hope? Bitwise operations are difficult for me.
replaced the temperature stuff with a command to just patch that ADC value to PWM_level. Maybe ideally there would be a rolling average here, but that can come later.
hacked up the LVP flashing to go full brightness during flashes
hacked up the LVP to semi-function without modes. Ideally it should flash quickly 3 times every ~3 seconds until we hit critical, then flash 10 times and shutdown.
copied and pasted a couple of variable initializations
* There are certainly some power savings tricks missing.
* I actually don’t see why we couldn’t add the potentiometer as a third ADC input and keep the temp monitoring.
* Come to think of it, now I can imagine how to include “stepdown” in a way that makes sense. After the 3 quick flashes, implement a ceiling value. Progressively half it or whatever is reasonable. Potentiometer throw remains the same, but the actual PWM value produced is capped @ whatever whenever it is set.
As far as hooking it up… I think PB2 (eg just like normal) should be voltage monitoring and PB3 [Pin 2, Star 4] should be for the pot. You hookup the pot between Vcc and GND with the sweeper hooked up to PB3.
When I get a chance I need to look at my code again. I built a custom one for police lights I was doing, and it functioned just as you describe. It also had the option to gradually ramp down over x number of seconds, instead of step down on the timeout. I thought I put that in the main program as a compile option, but if not I'll add it.
At the time, he sold in batch's of qty 10, so I bought 2 batch's for a total of $13 shipped (qty 20 total) back on June 23rd. This evening, I want to go back thru these pieces and see if any will program, and verify that all my non-working boards did come from that batch. I'm thinking this makes a lot of sense.
Anyone know if it's possible that legit Tiny13A's may not be programmable (locked) when purchased? They sure look legit and not counterfeit, but maybe there is a version that can't be programmed via the standard SOIC-8 method?
Yes, it’s possible. If certain fuse bits are set during programming this can happen. At that point only “high voltage” programming can be used, the ISP type we normally use will not work. In this thread in posts #52-61 we discuss the issue a little and I link to a “rescue programmer” project.
I don’t know if it’s done at Atmel or elsewhere, but I’m told that pre-programmed AVRs can be purchased. They’d be reeled and everything, ready for pick-and-place. Maybe what you received are excess pre-programmed ones with the situation I described above?
Just a thought: use an old (clean) toothbrush and some rubbing alcohol and scrub the pins well. You can flash while still wet. Sometimes I can't get chips to program that must have flux and/or oxide buildup and this works miracles.
Ok, but I did continuity tests on all 6 pins clipped from the chip to the USB dongle and it worked. I posted the question to the vendor about not being able to program them, and asked if they were possibly pre-programmed.
I'm going to put in an order for a bunch of Tiny13A's with DigiKey this weekend - need time to figure all the parts I'll be needing - might as well be sure I'm stocked up. Might order another good clip just to have a good spare.
Thanks wight for that thread tip - read it, interesting...
You didn’t include it as a compile time option as far as I know, but you did include full instructions in your thread over here: First use of lathe - P60 pill for L2T - the instructions are spread across several posts in that (short) thread.
Everything is there, I know because I built a dropin with that code in the past week. I mentioned it in the OP here. It functioned just like you described, although I have not had time yet to properly sink the P60 and the OG XM-L I used starts at 9A so I’ve only run it for a few sec at a time and verified that it functions. I set mine up as medium and turbo w/ rampdown and that’s it.
Beginners may need a hand, but they might not. There are really very few code changes required! I’ve been thinking that as a room clearing light I’d like to add a 15s+ of solid turbo before the smooth rampdown. Should be straightforward to add, but that dropin is already together and unlikely to be rebuilt. I like the concept, so I’m sure I’ll have another chance to make that change and post the code.
You’re welcome. HV doesn’t have to be for rescue, nicer programmers can actually load a program using HV programming. I think you’re looking at a $30-60 programmer to get that feature though? I guess it still might be worthwhile in the very long term if you can save $0.30/ea or so per ATtiny13A… after about 100-200 chips you break even? Of course that’s assuming that these aren’t total fakes! They could be mislabeled/etc.
When I get a chance I need to look at my code again. I built a custom one for police lights I was doing, and it functioned just as you describe. It also had the option to gradually ramp down over x number of seconds, instead of step down on the timeout. I thought I put that in the main program as a compile option, but if not I’ll add it.
[/quote]
I for one would be very interested in the smooth ramp down. Thanks again for all the help. Wish I had something more to contribute developmentally.
I'll gladly eat the $13 spent on the bad parts rather than investing into the tool - agreed . Thought the AVRDUDE error msg was the same as when it's mounted wrong or missing - not sure, @work now... DigiKey all the way now... Actually, I bought Tiny13A's from BangGood originally and they worked out well, even though they were individually wrapped - weird.
Wow, you know my posts better than I do! I still haven't done *%# with those builds. And wow, that looks like a great driver you built. I haven't even dabbled into the FET arena, I simply cannot keep up with all of the posts on the subject! If I ever want something other than a NAJNG, I'll just order it pre-built from Richard :)
I'll work on getting the "immediate turbo ramp" feature in the main code hopefully today. Then I need to start the port to the ATtiny25.
Speaking of FETs, I wasn’t happy with the moon level on mine… so I added a feature to let me fine-tune the output of moon. Using fast PWM=0 I was getting like 0.05 lm. But fast PWM=1 gave me about 11 lm. And phase-correct PWM=1 gave me like 6 lm or so. I wanted something closer to 0.3 lm.
So, I added PFM to moon mode, and only to moon mode. This means, instead of doing fast PWM=0/255, I can adjust the brightness gradually. I settled on 0/40 for this particular light, where a lower denominator makes the output brighter. I might go further, to 0/30, for an even brighter moon.
This also means that moon mode pulses a lot faster. In the case of 0/40, it pulses at about 120 kHz.
I should mention that the output is still highly voltage-sensitive, especially on PWM=0, so it will still get extremely dim as the cell gets low. The battery and FET just can’t get up to full power in the ten-millionth of a second the pulse lasts, and that’s especially true when the cell isn’t full. The highest mode may drop to half its original output on a low cell, but moon will drop pretty much all the way to zero.
But at least moon is a nice comfy level for the first half of each charge cycle.
That aspect just doesn’t sit well with me. (A mode which potentially does not generate light.)
If I was working on low moonlight + high turbo I think I’d try to bring the voltage monitoring into the picture. In other words I’d scale my moonlight PFM freq down as battery voltage dropped. Even doing it very linearly seems better than not doing it at all. At least it would light up with a partially discharged cell! Am I missing something important?
Interesting stuff with the PFM. I don’t really understand the mechanism, there’s a lot to parse just staring at the few lines you use in the code vs the plethora of info in the datasheet. I do understand what’s happening though, thanks to your relatively clear code & comments (both here and in the code). I guess You’re making use of “TOP”?
I can rarely make heads or tails of registers. I suck at number system conversions, addresses, and notation. I can plug 0x08 into a HEX>BINARY converter and get 0000 0000 0000 1000, and I take it that the 4th bit (bit 3) has been set to 1. Actually pairing that up with the stuff from the datasheet…. I assume I should be looking at page 73, but again - I can’t understand the notation. The struck text is true, but I think I’ve got it now. I was missing that both bit 3 and bit 0 got set. So we are in “Mode 5” where we update OCRB at TOP and TOP is OCRA (all using Phase Correct). I know it’s pitiful, but I feel accomplished having finally gotten that worked out.
Thanks for doing the heavy lifting on this, it seems like a good advancement to me!
EDIT: For others trying to get a handle on this, I referred to sections 11.2.2 of the ATtiny13A datasheet (on page 60) as well as the chart at the top of page 73 and the little control register diagram in the middle of that page (so the top of section 11.9.2).
Instead of having a predefined mode to step down to, you define a MODE_TURBO_LOW PWM level. You can still have it the same as MODE_HIGH if you'd like, or just skip the high mode altogether. I got rid of the whole MODE_HIGH_W_TURBO thing while I was at it. Because the WDT was set to 500 ms previously, and because the turbo ramps down only 1 PWM level per "tick" (WDT timeout), going from 255 to 140 would take almost a minute. Instead of stepping down by 1 output level you could step down by 2. But I added another compile time option of TICKS_250MS, which will change the WDT ticks to 250 ms, so the turbo ramp down described above will take 30 seconds. Obviously tweak it however you want, but also realize that the "tick" timing affects the mode storage in the STAR program.
This addition was not applied to STAR_momentary and STAR_dual_switch. I would need to devote some time to making and testing the changes, so it might be a while until I get around to that (maybe when I actually get around to building a light with those UI's, because I've never used them).
EDIT: And please, as always, if you notice any bugs while attempting to use these let me know!
I’m not terribly happy about it either, but my choices were either voltage-sensitive moon or no moon at all. I did end up bumping up the level a bit though (0/30), so it now ramps from about 3.3 lumens at 4.22V down to somewhere around 0.05 lumens at 3.6V (will have to measure that when I get my battery drained though).
In-between, it spends most of its time in the 0.2 lm to 1.5 lm range, as far as I can tell, which will have to be good enough for now. But I did at least omit moon mode from the low-voltage step-down, since at that point it’s basically the same as “off”.
I considered making it change based on voltage, but the curves are rather non-linear, doing the math on the MCU consumes a lot of space, a table would also consume a lot of space, and it’s not even terribly effective near the bottom end of the voltage range… it still gets extremely dim even with the ceiling set just barely above the floor.
Maybe I could use a small table if I free up some bytes elsewhere, but I’m not sure it matters to me that much.
Yes, I’m using the TOP mechanism. I called it a ceiling. However, I’m not using phase-correct PWM here, it’s fast PWM. The “TOP” thing works in either mode, but phase-correct turns off entirely with PWM=0 and at 1 it’s too bright. I agree that the documentation is particularly convoluted about all this.
FWIW, the cypreus.c firmware got updated quite a bit today. Also, my Ferrero_Rocher/Ramping_UI_table.c firmware makes use of PFM for smoother ramping on the lowest modes, if you’re curious to see another use of PFM.
It’s an interesting concept, but it seems to have very limited usefulness in a flashlight driver.
. Thought the AVRDUDE error msg was the same as when it's mounted wrong or missing - not sure, @work now... DigiKey all the way now... Actually, I bought Tiny13A's from BangGood originally and they worked out well, even though they were individually wrapped - weird.