Tom, you're older than I thought. I pictured you in your 40s, but almost 60? That surprised me. You are doing a good job keeping your mind active.
I'm a '57, not Chevy - more a Dodge guy
Ok, this ol man () just posted the updated Narsil manual. The google docs share is updated, link here:
Google Docs share - 254585Support
Not much changed in the manual - updated brief descriptions on ramping, updated the mode set 9->12 changes (dropped mode #11, added a new mode #8).
Still kept the manual at 3 pages.
The google docs share thing is a little bit a PIA. You can change the view to a regular filename listing vs. icon's by clicking on "List View" in the upper right. There you will see full file names. I've copied old versions into the folder "Old Versions" and shared it, in case you need them.
If you only can, or prefer, to use the HEX file for downloading, dnld the file: Narsil HEXv1-12.zip. It contains only the AVRDude commands and the HEX/EEP files. All files can be copied directly into your AVRDude folder, and run from there.
I want some help if possible . It’s not about attiny25 etc but a lot of people see this thread.
What firmware could i use , for attiny13a with the ability to have only 3 or 4 modes , fast strobe , high , medium(optional) , low ?
without memory .
One suitable is theStar , but i can’t get it to properly work . Is there any other option ?
Driver is a “fet only” , without 7135 with wight boards
Mid way between fifty five and sixty is a lot younger than nearly sixty.
Don't think Star has strobe support. I use my own flavor of luxdrv with enhancements for doing something like that - strobe and other special modes.
I added strobe back in 2014. I think that I shared it somewhere...sometime. Take a look through the STAR firmware thread.
I’m using TheStar from the which has a “tactical” mode , which makes it a 3 mode strobe-turbo-low but i can’t get it right …
I’m now trying luxdrv but i can’t compile it . As said , i want only Strobe , high , medium , low . (with lvp)
This is my modified code of luxdrv : //// LuxDrv 0.30b DrJones 2011++//// 808 bytes with ramping//// Lic - Pastebin.com
I get a lot of errors . Can someone help me ? I would really appreciate it … Thanks
You should post the errors.
Did the code compile without your changes?
I fixed the pastebin link in my previous post .
Errors :
Error : variable ‘modes’ must be const in order to be put into read-only section by means of ‘attribute((progmem))’ Line 51
Warning unused variable ‘i’ [-Wunused-variable] Line 174
No , it doesn’t compile without changes
Well, then make it const:
PROGMEM const byte modes[]={ MODES };
The warning is only a warning, ignore it. Probably there because you commented out defines.
Well, then make it const:
PROGMEM const byte modes={ MODES };The warning is only a warning, ignore it. Probably there because you commented out defines.
That’s what i just tried . I will flash it and report back .
This is my luxdrv version: Google Drive luxdrv base for 13A. Think all you have to do is comment out call to getmode(), and set the mode table accordingly, to how you want it. There's lots of examples of mode sets in it, commented.
Mine is:
const PROGMEM byte modes[]={ MODES };
Ok, this ol man () just posted the updated Narsil manual. The google docs share is updated, link here:
Google Docs share - 254585Support
Not much changed in the manual - updated brief descriptions on ramping, updated the mode set 9->12 changes (dropped mode #11, added a new mode #8).
Still kept the manual at 3 pages.
The google docs share thing is a little bit a PIA. You can change the view to a regular filename listing vs. icon’s by clicking on “List View” in the upper right. There you will see full file names. I’ve copied old versions into the folder “Old Versions” and shared it, in case you need them.
If you only can, or prefer, to use the HEX file for downloading, dnld the file: Narsil HEXv1-12.zip. It contains only the AVRDude commands and the HEX/EEP files. All files can be copied directly into your AVRDude folder, and run from there.
I’m trying to imagine one of my parents using some of these words… Or even if I used them, what would they say…
HEX file… “Son, watch your language in this house!”
Google… “OK, I suppose baby talk is better than cussing.”
AVRDude… “I know you think you’re cool with your surfer language, but you’re not!”
Icon’s… “Nobody beats the Beatles!”
List View… “OK… Just a minute, I’ll go get a pen and paper.”
PIA… “Are you talking about those secret codes for that Book of Faces on the web thingy?”
Downloading… “Ahhh man! Your phone is broken too?”
Tom, you’re a few steps ahead! :+1: :sunglasses:
Ahh, yes all true. Just fyi though, I’m fast switching power on/off 100’s of time to get it to happen once – but it’s still bad when it happens for sure…
Dr Jones doesn't use the voltage divider resistors on his new drivers, so we know it's do-able, but of course, no published details (or source code) on doing so.
Actually we could go even higher on the voltage divider resistors as another option - that's been done also, and I bought the higher value resistors to experiment with
It's done by setting the reference to vcc then measuring the 1.1v bandgap. I brought it up at post 725
Posted code for tiny25/45/85.
I actually have / had some example code. I'm looking for it. ~ edit ~ long readVcc() { ADMUX = _BV(MUX3) | _BV(MUX2); // Set reference to Vcc and measurement to internal 1.1V bandgap delay(2); // Wait for Vref to settle ADCSRA |= _BV(ADSC); // Start conversion while (bit_is_set(ADCSRA,ADSC)); // measuring uint8_t low = ADCL; // must read ADCL first, it then locks ADCH uint8_t high = ADCH; // unlocks both long result = (high<<8) | low; //Note: might need to discard first result re…
I actually have / had some example code. I’m looking for it.
~ edit ~
long readVcc() { ADMUX = _BV(MUX3) | _BV(MUX2); // Set reference to Vcc and measurement to internal 1.1V bandgap
delay(2); // Wait for Vref to settle
ADCSRA |= _BV(ADSC); // Start conversion
while (bit_is_set(ADCSRA,ADSC)); // measuringuint8_t low = ADCL; // must read ADCL first, it then locks ADCH
uint8_t high = ADCH; // unlocks bothlong result = (high<<8) | low;
//Note: might need to discard first result
result = 1125300L / result; // Calculate Vcc in millivolts; 1125300 = 1.110231000
return result;
}
Note that it must be turned off before putting the attiny to sleep. https://budgetlightforum.com/t/-/34900/767
And here is where DrJones mentioned using the internal VCC measurement all the time and getting about 0.3 µA standby current https://budgetlightforum.com/t/-/34900/765
Ahh, thanks Halo! I recall you mentioning it, just didn't know exactly how to code it. I'll look all this over. It's kind of/sort of a big project to integrate it in, since I blink out the votlage levels, so need a whole table of values from 2.0 to 4.5V or so. It would help eliminating the voltage dividers altogether, and reduce the drain even more, specially since there apparently is no disabling of BOD solution, and now we know we need BOD enabled for powerup problems that occur. I need to email ATMEL support to see if they can provide any insight. I'm signed up on AVRFreaks and got an old thread resurrected. Couple guys posting, and so far no one has the BOD disabling working.
Hi friends! I have a question about values of r1 and r2 when using attinys other than the 13a. I’ve seen it mentioned a number of times to use values for r1&r2 10x or so when using other than the 13a. Does this only make a difference on Eswitch lights or also with clicky lights with for instance the Bistro firmware?
I’ve had the parts for a while, but I’m just diving into building my own drivers. I have a couple of all the attiny’s and I’ve been working on how and when to use each one. Anyway, the first question that I can’t seem to answer is that of the values of r1&r2 for these larger mcu’s. Thanks for any help!
R1/R2 values have nothing to do with differences between the 13A and 25/45/85's. Cranking up the R1/R2 values is only if you want to reduce parasitic drain, least that's why I use them. Parasitic drain is only an issue I know of with e-switch lights. If you have dual switch firmware, where the e-switch is only used to change modes, and a power switch is still used to turn ON/OFF the light, then it should not matter.
So if you have pure e-switch firmware and care about parasitic drain, on either a 13A or above, then the high values make sense. Of course the method Halo describes above is even better - no parasitic drain from R1/R2 because they can be eliminated, but it requires a firmware change. It also frees up board space, reduced part count, etc.
I'm using 10X because the resistors of those values are commonly available and require no firmware change at all.
Ok. I see.
I’ll look more into what “Halo describes”and see if it is something I can understand. For now, I know that with clicky switch only it doesn’t matter. Thanks!