Yeah, I know I should calibrate but I get lazy when building a bunch of lights and wanted some number that was close in case I didn’t.
Plus honestly a 10c+ swing in temps doesn’t bother me as long as it keeps it from getting dangerously hot.
I lowered the step down time to ~8 seconds and think around 90 as the starting temp threshold seems to work well for a starting point. Although I think I might step the stepdown time down to 5 seconds as it takes awhile to step down from turbo.
Most of the firmwares (including Bistro I think) are using the ADC in 8-bit mode to save on memory space (left-shifting the ADC result and reading only the high byte). When moving up to the 25 or 85 there is no real reason to do this. We can comfortably fit a few 16-bit variables in memory and use the ADC in full 10-bit mode.
In 10-bit mode the ADC reads approximately 1 C per ADC count, with 300 = 25 C (it is kind of a Kelvin scale). With the ADC in 8-bit mode the result is approximately 4 C per count, with 75 = 25 C. Very difficult to achieve any kind of control, PID or otherwise, with the 8-bit mode.
With the bistro setup as I have it now (already had to turn off the better bike strobe, not that I really care) I am at 99.3% or 2034 bytes. So I only have 14 bytes left to play with.
Do you think there is enough room to switch to 16-bit mode? If so, which numbers would I change? That kinda taxes my skill limit with coding. I speak C well enough to stand around people having a conversation and nod my head at the right times but thats about it.
For this stuff reading the datasheet is probably more important than C skills. 14 bytes may be tight, depending on how you do it. One option is to read the ADC into a 16-bit variable and then subtract lets say 200 to get back to a number that will always fit into 8 bits. (Remember to facilitate sub-zero temperatures!)
Below is from my code, but there should be something similar in Bistro.
The ADC needs to be set up to right-adjust:
ADMUX = (1 << REFS1) | (0 << ADLAR) | 0b0001; // 1.1 V reference, not left-adjust, ADC1/PB2
The other modification is to read the 16-bit system register ADC, instead of the 8-bit ACDH, into your new 16-bit variable:
int16_t adcin = ADC;
Right-adjust will affect the cell voltage reading as well, but you could just right-shift ADC by 2 steps to get back to an 8-bit value.
C'mon fellows, are you having trouble because of limitations in internal storage size?
For the Love of God, just 2KB of SRAM and high level language… :FACEPALM:
If I were you I wouldn't hesitate to jump straight on coding in assembler; it can require a deep knowledge of the machine's inner workings, yet you can do wonders this way. I was once somewhat skilled in 8086 and R3000 assembly language back in the days.
Just sayin'…
Cheers ^:)
It will only gain you so much and would make writing firmware a lot longer so that we’d not have most of the firmware we have today. gcc has a few flaws for avr but is generally quite good.
For ASM, been there, done that, as far back as 1979. I still use it from time to time in the embedded projects I work on (for a living), and want no part of it in a hobby. Main reason why I prefer the 85 with it's 8 KB. It's hard to go back to 1KB or 2KB.
For me, there's no way I'd be doing this if all I had was ASM. I've also been working in C since about '82 or so - somewhat comfortable with it 
.
Latest Narsil version, 1.1 is now posted up on my google drive share, here: https://drive.google.com 254585Support.
Improvements/Changes:
Hi, do I need an input capacitor for the Attiny? I dropped the output capacitor and the off-time capacitor already.
Driver output is around 3A max with a single li-ion
Does anyone know?
Not sure what you mean by input capacitor, don't know what exact attiny you are using, or what driver you are referring to - we got dozens.
Never heard the terms "input capacitor" or "output capacitor" used before.
C1, as far as we know, is required. It's connected between Batt- and Batt+. The OTC cap is for clicky switch drivers, and is not needed for e-switch drivers, and doesn't have to be used even for clicky switch drivers.
Not sure which specific driver you are referring to, or which capacitors (there are no ‘input’ / ‘output’ capacitors on these drivers).
Most sub-circuits need a decoupling capacitor, which is simply a kind of near-and-ready voltage source. The MCU should have one, located very close to it. On most drivers this is C1. On many drivers C1 is separated from the MCU by D1. In that case you should add a second capacitor C2 very close to the MCU.
On most drivers C1 is also decoupling the FET/emitter, making it almost useless (actually detrimental) for the MCU. Enter the added low-value resistor R5 to isolate the FET/emitter from C1 and the MCU. (A ferrite bead would actually be a more more appropriate part to use here, but can add complications if not selected correctly). For our purposes you can easily get away without C2 when you have this resistor.
As I'm new here, I'm not sure if I should have stuck this:
https://budgetlightforum.com/t/-/41582
in here instead of making the new thread.
I'm going to suggest discussion there, not here, and just place this post in case it interests people who frequent here, especially since I don't want to interrupt the discussion here of people who know what they are doing. If mods or others think it should merge, that's fine too.
Thank you for the replies! I think now I understand it a little better.
So it is not possible to use the driver like that:
and I should add a capacitor between GND and the VCC pin at the Attiny, right?
At the minimum. That is what the Nanjg 105 drivers look like.
R5 is less important when it is not a FET driver. But I would still put C1 upstream of D1 and add R5.
Has your opinion on C2 changed or is it still worth the board space if R5 is in place?
There really should be a C directly across pins 4 and 8. But we have been getting away with much, much worse before. I would not bother on the 17 mm boards. Stuff like the ADC will see more noise, but I am pretty confident the driver will be stable with R5 in place. On the larger boards by all means put C2.
I have some 0603 ferrite beads on the way. The idea is to try these in the R5 position. Low DC impedance, but 100s of ohms in the MHz range. This should lower the current pulses going through R5-C1 during PWM. C1 can then be relocated to the C2 position, without stressing D1. I still prefer C1 ahead of D1 though, for the sake of more accurate voltage monitoring - no D1 drop to account for (R1/R2 should always tie to C1).
I have a rev01 of one these running and it looks good enough:
No C2, or R4 (or OTC!). Rev02 increases the vias size and shifts the 7135 to get more clearance for the programming clip. Rev02 is untested and may get further revised once I try 0603 parts on rev01 (currently using all 0805).
EDIT: OSHPark link updated to revision 02 - Small change to facilitate stacking a C2 on/beside C1/D1.
Ohhhh - DEL, I like that board! Pin #2 and #3 pads and a big spring pad - nice!! K, so no C2, no R4 -- cool! Are the MCU pins 13A size? Gotta get some 0603 parts though, for sure.
Hi Tom, yes that is an SS package size. So unfortunately 85s will still need some pin-bending to fit.
I also have 20 mm and 22 mm versions. These have all the components and full size MCU pads. But I need to rework them a little first with what I saw on the 17 mm version.
Edit: The board is intended for 0603 parts, but 0805s will fit as well.
Be sure to post if you come up with a better component layout/list. I might be making some changes to the TA drivers anyways if we are able to eliminate R1/R2 and I could update the other changes at the same time.
So far the 17mm boards with C2 in place seem to be working very well. Although if space is an issue for some reason I suppose you could just not install C2, so not sure I would remove it even on the 17mm. The only thing I would really gain is a slightly larger pass through and a tiny bit more space in the center of the board to spread things.