Oh. It’s not supposed to go down so far it shuts off the LED. That probably means the ramp isn’t calculated correctly for your hardware.
So… step 1: re-calculate the ramp with a higher floor.
Then step 2: make it stop at the bottom. It should work pretty much the same as the “STOP_AT_TOP” thing. You could probably copy/paste the code for that. Or use the method you already worked out, which should be fine if the floor isn’t underwater.
Thanks for pointers TK,
I reconfigured #define RAMP_CH1 so it would start with level 5 and that did the thing. :+1:
Next to do:
when ramped up all the way to max, if you do short tap it will try to ramp up again and nothing will happen because it is already at max (it will blink after every short tap if the blink_on_top is enabled). I will try to change this to: if you are at max already and you do 1 short tap it will change ramp direction to –1 and start ramping down. I believe this can be done in the function that defines single tap action.
During ramping one tap will stop ramping procedure and the next tap will proceed with ramping (if you ramp up and if you ramped down then this short tap will reverse ramping direction and go up again, for proceeding with ramping down double tap is neaded) this is unchanged behaviour from what you made.
Second thing I will try to change: when at min level (5,) after ramping down, first proceeding tap will jump it to max level then next tap will bring it down to undefined “low” level that is not same as min but it is close and then third single tap will make it ramp up again. I will try to eliminate this jumping to max and then to low, if it is at min level first proceeding single tap should start ramping up again.
This is probably located somewhere in main() function.
Getting the ramp direction correct at either end should be relatively simple… can probably just insert something saying “if already at max: ramp_dir = –1; if already at min: ramp_dir = 1;” before it does the actual ramp. That way it would go in a useful direction regardless of whether you tapped once or twice.
Anyway, it sounds like things are making more sense in general and you’re making progress?
Wondering if I'm mis-understanding, or messing something up. The latest headers I think are here:
http://bazaar.launchpad.net/~toykeeper/flashlight-firmware/trunk/files/head:/ToyKeeper/
In it, are the tk-attiny.h and tk-delay.h files, and for the ATtiny25, BOGOMIPS is set to 8000000/3200, which is 2500.
I'm using this value for NarsilTriple and finding my delays are about 25% too slow. I'm thinking BOGOMIPS for a 25 or 85 running at 8 Mhz should be 2000, not 2500. I've been using 2000 in Narsil and timing delays are dead-on accurate, while in NarsilTriple, they are 25% slow.
Does this make any sense? Am I using these settings incorrectly somehow, or maybe these are the wrong files to use?
The 2500 values should work for 6.4 Mhz, not 8 Mhz, I think?
Well, 8 MHz / 6.4 MHz is 1.25, and 2500 / 2000 is 1.25, so if it’s running 25% too slow it could maybe be running at 6.4 MHz instead of 8 MHz?
Of course, BOGOMIPS is intended as a tweakable value. The “BOGO” part means “bogus”, a carryover from Linux kernel code. It’s a made-up number used for the purposes of fudged timing loops. So if the timing is off, it should in theory be fixable by just changing the bogomips value.
IIRC, the way Linux does it is to run a counter loop for exactly one realtime-clock second at boot (or maybe periodically afterward), so it gets the right value automatically. But on attiny, it kinda needs to be hard-coded at compile time.
If you have Linux, try ‘grep bogo /proc/cpuinfo’ sometime to find out how many bogomips you have.
Oh, um, and on attiny, the CPU speed can be measured with some multimeters:
In that example, 16.78 kHz PWM would mean the CPU was running at 4.29 MHz (16.78 * 256 / 1000). Or if it was using phase-correct PWM at 8.4 kHz, that’d be 8.4 * 512 / 1000.
You are losing me. The CPU is set to 8 Mhz because of the fuses, it's been this way always, since we first started 25/45/85 development as far as I know. I know what the speed is because I trust the fuse settings.
Ok, I thought BOGOMIPS in the tk-attiny.h was set up long ago for 8 Mhz for the ATtiny25 setting. Am I wrong here?
Are you just fool'n with me? 
If the timing is off, change the bogomips value. That’s what it’s for.
If it’s off by exactly 25%, well, that’s a little suspicious. I’d measure the clock speed on mine, but it’s back home on my space rock. I was in a hurry and didn’t bring much with me. You sure you didn’t lower the clock speed at some point to reduce standby power?
No big deal. I can only assume that value for BOGOMIPS in the master tk-attiny.h file was set for 6.4 10 Mhz, and not 8 Mhz.
I corrected it now in NarsilTriple, just that it's been wrong all along.
#if (ATTINY == 13)
#define F_CPU 4800000UL
#define EEPSIZE 64
#define V_REF REFS0
#define BOGOMIPS 950
#elif (ATTINY == 25)
// TODO: Use 6.4 MHz instead of 8 MHz?
#define F_CPU 8000000UL
#define EEPSIZE 128
#define V_REF REFS1
#define BOGOMIPS (F_CPU/3200) --> (F_CPU/4000)
#else
Hey, you need to define ATTINY.
#endifCorrection marked in RED above. This works for me.
It used to be correct - I found it correctly defined in the history. The 2016-09-09 rev changed it from set to 2000:
http://bazaar.launchpad.net/~toykeeper/flashlight-firmware/trunk/revision/170
Edit/Update: Ooops, since it's running slower by 25% with a higher delay value, it seems like it was set up for a higher CPU clock, maybe 10 Mhz.
Thanks! Good catch!
I wonder why I changed that…
In any case, I gave it the correct value and updated trunk.
Phew, thought I was using/doing something wrong at first. Stumbled across it simply because I could notice some lights blinking slower than others.
Still have more testing to do, but looks like I was able to combine Narsil (2 channels) with NarsilTriple (3 channels) into one driver code base.There's a header file called setups.h where you configure all the settings for the driver and compile time options (set OUT_CHANNELS to 1, 2 or 3). I also added a few other header files to manage the multitude of register settings, ramping tables, and mode sets.
Also added a channels.h file that has the channel specific functions in it. I normally don't like having functions in headers, but it's simpler to do this way, otherwise it requires more infrastructure to share variables, etc.
The good thing is that new features are combined now, so both versions benefit - they drifted apart more recently.
I'm calling the project "NarsilM" for multi channel support. I haven't fully added 1 channel support yet, but there's a place holder for it through out.
I’m trying to run battcheck.py but I honestly don’t know what that means. Can someone lead me through running battcheck.py?
I can get the min max arc values for the .volts file. I created a folder called readings in the same directory as the battcheck.py file. I tried starting the py file in cmd but it just opened up the windows “open file with” window. With notepad the only option. I’m probably way off as this shows my ignorance. :person_facepalming:
Anyone with Windows know how to run python scripts?
You might have to install python.
I don’t know how. But I downloaded python and somehow just got it to work. Thanks tk!
You need python installed to run the script. If you read up on how to run python scripts that should explain it.
I'm getting nowhere with this on Windows 7. I have Python 3.6.1 64 bit installed.
I can't figure out how to make a .volts file without my machine turning it into an Adobe file.
When I double click on the battcheck.py Python file a command window pops up for a split second and goes away and nothing happens.
As far as Python goes I've gotten as far as hello world.
"Run battcheck.py mydriver.volts" outputs 'battcheck.py mydriver.volts'. :FACEPALM:
How do I make it work?
Hi RotorHead64,
I’m trying to help you with this, but I’m not an expert.
(0. Install python)
4.1.1. click file->Save as:
filename: mydriver.volt
save as type: all files
4.2 Create a new .txt-file, like this
4.2.1. click file->Save as:
filename: run_battcheck.bat
save as type: all files
your folder should look like this now:
Now, to run battcheck.py, simply double-click the .bat-file.
I edit the mydriver.volts file every time for a new driver by right-clicking it, open with, notepad… Once this is done, you can simply open and edit it with a double-click.
I’m sure there are easier ways, that’s just how I do it and it works for me.
Cheers.
Hey that worked great! :partying_face: Thanks chouster! And a big thanks to Texas_Ace, I wouldn’t have made it this far without his help. 
You’re welcome, I’m glad I could help.
I noticed a minor inefficiency in the levels that level_calc.py outputs:
Let’s say that there are 2 channels, 1*7135 and 3*7135.
This setup can have optimal effciency in 3 points: with 1, 3 or 4 7135s running w/out PWM.
But the script can find the middle one; given 1050 mA target level it would run channel 1 at 100% and add a PWMed channel 2.
Also, what’s the point of pwm_min? Why can’t it always be 1?
A have a few drivers built on 380mA 7135s that don’t show any light until PWM value is 8 or something. What’s the point of having 1 to 7 if there is no light?