The normal SIR800 FET will just fit on a 16mm star but it will also interfere with the reflector and centering ring, needing mods to the reflector and a custom ring.
I wounder if a smaller lfpak33 FET would handle 5-10W of heat dissipation on the mcpcb?
What about two of them?
That is actually a good idea. The load would not be evenly spread between them but it should at least help.
Although if doing that then hopefully something even smaller then the lfpak33 could be used. The max I see a single LED using in practical use would be ~15-20A and ~8-10W of dissipation to the mcpcb (so we could get away with a bit over official max ratings). That is really not all that bad, I bet something fairly small could be found. Oh and a voltage range of 3-18V ideally.
Hmm, something to look into when I get back to a computer full time. Just get a few mins int he morning each day right now.
Kinda looks like it, I haven’t actually looked them up myself yet due to limited time.
Although it looks to have way too many pins and cost too much. The pics MikeC showed of them were a lot smaller and I think they only had 12 pins.
It was an atmel MCU, just a newer generation then the ones we are using now (latest?). The code is similar with some register changes or something, like I said, have not had time to look into it at all. Apparently he has a few drivers running them and they are working great for him, take up a fraction of the space and offer way more features and pins to play with.
No. You want the 841 MU with the QFN 20 package: Search results for: ATTINY841-MU 8-bit Microcontrollers - MCU – Mouser
Same package as the 84A MU I used in this driver: What did you mod today? - #2576 by Mike_C
I was hoping you would chime in Mike. It is nice to see that the price is the same as the tiny25/85. Didn’t you say there was an even smaller version of it? What do you give up for the smaller size? 3x3mm sounds so very sweet.
It was loneoceans that used the smaller 3x3mm package for the 84A in his boost driver. The 841 comes in the 3x3mm package too, but I haven’t used it, I only have the 4x4mm (MU) version and it’s small enough for me. The 3x3 version of the 841 is called MMH.
My first attempt with the MU was a failure because I used the standard downloadable footprint from Farnell UK which has fat borders around the pin pads which overlapped so there was no purple solder resist (or what ever it’s called) between the pins. The solder paste so easily jumped and shorted pins. I had to uncheck the “stop” checkbox for each pad and make my own custom stop pads exactly the same size as the actual pads. Note that I applied the paste by hand, I have not made stencils for these boards yet.
I think working by hand with the 3x3 would be a little too tight for me, but loneoceans seems to be doing fine so I recommend checking first with him before designing any boards with the 3x3mm pad.
Missed this question.. The OTSM build on the attiny25 is presently 1825 (OTC is almost 100 bytes less). Over 200 bytes to spare. We were kind of depressed that a regulation curve would take 150 bytes. Well 150 is ok. I think it's even possible to get a generic regulation for all modes in that much space. I started to make a bunch of curves for current and brightness vs Vcc reading by rearranging djozz's data.
Right now even a 4 channel eswitch build is only 1918 bytes. There's room to play with even on attiny25s.
What to use for P7 on the 15mm one
And how to add LVP to Narsil triple?
Wow, ok, that's the 841, an ATtiny84 more advanced variant. I'm really, really lik'n it, specially at $1.14 each. You do have to add in the thru holes to the overall real estate to support programming it, but probably easier to squeeze in here and there.
I released a new version of NarsilTriple - v1.4, find it here: drive.google - NarsilTriple V1.4. Not much changed.
Summary of changes:
Sorry, still no LVP for 2S LDO.
So TA I'd like to write up a >1S build for this OTSM. For now what do you think, could this diode I'm using fit on R7? Why wouldn't that work? Your LT3009 looks promising but I don't think it fits on v1 right?
By the way, LEXEL P7 is an 8.4V LED right? So yeah, this what I'd be thinking be about. It's probably not surprising to hear, but I'd never build another OTC board unless there was something special that just couldn't be hacked into OTSM. This is just clearly better, in real use.
At TOM sounds good. I'm surprised /2 to >>1 saves bytes. I thought this was a pretty basic compiler optimization. Anyway, good to force it.
Funny, I watched closely the resulting byte size before/after /2 to >>1, and the differences were all over the place, from 0 bytes saved, to 4 bytes saved, to 8 or 12 bytes. It's gotta be related to the context somehow, or maybe whether the variable is declared volatile, local or module level maybe? I didn't check that.
volatile is a memory killer - I've reduced the #'s of uses, but gotten burned before when not using it. With e-switch using the Watchdog ISR so heavily, you can get burned.
Years ago, I'd swear many optimizing embedded compilers were smarter than they are today. Lot of it went offshore, not so well tested, QC'ed etc. as they used to be, but also depends how mature and maintained they are.
I don't tend to feel I agree with the philosophies of the compiler folks much. It all seems about defending their academic concept of an "abstract" machine and not much about making real machines work. I had a memory overwrite, the zero byte of an array got copied past the end of eeprom. I didn't care about the 0 element (but still shouldn't have done it and probably didn't mean to) but it all worked fine, except on one configuration where the compiler decided that, since it was undefined behaviour, it would just remove the whole write loop entirely. Then of course things didn't work right. Whatever I guess. My mistake. Wouldn't you think a warning at least "your code is broken so we're removing it." or error "your code is broken, not compiling this" have been more appropriate?
Theres a page on atmel guide somewhere about
a=do_something_hard();
cli();
PORTB=a
sei();
And I'm messing this example up but basically the conclusion was, no amount memory barriers will make it work right; you're going to have interrupts disabled longer than you meant to. Of course gcc developers don't consider that to be an "observable" aspect of the code. Ok, I'm just getting started, but I should stop and take a breath.
Yep, this is totally the way forward IMHO. With that much space, pins and OTSM I think that reflashing drivers will become a thing of the past anyways. We should be able to make 1 single firmware that will handle over 95% of possible uses without the need for any code changes, just menu options.
The space savings on the pcb is also massive and vastly improves what we can do.
I am not totally sure I understand what you are asking? R7 is for the FET right? Why would you want a diode there?
Also what is your goal, I don’t understand what you are trying to do?
Oh, I thought R7 is a 0-ohm from the LDO to C2. The goal is to squeeze a low leakage diode into it. I don't think the new LDO's will fit and the mics are certainly not low leakage. You can't get OTSM if the cap voltage leaks through the diode/ldo.
Sure looks likes R7 feeds C2/Vcc.
The Attiny841 still is limited for program space with 8 KB. With NarsilTriple, I'm darn close to limiting out, and no where near complete functionality and configuration support, though Flintrock accomplished a lot in under 2 KB - he and TK got me on code optimization for sure, though the config UI and indicator LED support takes a lot of code space.
Oh, I didn’t realize which pcb you were talking about. Yeah, R7 is just a jumper after the LDO. You said you wanted a 1S setup so I assumed you were using a normal driver without an LDO. I also didn’t think there was an R7 in the normal ones, hence my confusion lol.
An SOD-323 diode should fit on the 0603 pads if placed by hand. I have done it before.