Flashlight Firmware Repository

I myself rewriting firmware for the flashlight. Few understand this. Maybe Monday will try to deal better with this new firmware.
On fonarevka.ru I mostly used Tamagotchi
bazaar.launchpad.net/~toykeeper/flashlight-firmware/trunk/view/head:/Tamagotchi/7135x8v2/README
http://bazaar.launchpad.net/~toykeeper/flashlight-firmware/trunk/download/head:/readme-20150406202629-xmo8czit612270ff-1/README

Let’s see…

It’s probably easiest to copy the .h files into the same directory as the .c file, as already mentioned. Or copy the whole repository and add “…” and “…/…” to the include path, wherever AVRstudio sets that option.

You’ll probably want to modify tk-calibration.h with values specific to your driver. This is basically voltage and OTC readings, as measured by the tools in the battcheck/ directory. Once you have the right values for your driver, it’s a good idea to keep a copy of that file somewhere for later use.

You may also want to calculate a new output ramp. The command line for this should be in a comment just above the current ramp, for easy reference.

As for getting everything built in Windows, I really don’t know. I haven’t used Windows since the 1990s. It sounds like others here have already answered a lot of that though.

It’s possible that could be caused by calibration values instead of actual logic bugs. Each person’s drivers seem to need slightly different values. The battcheck/README file should explain how to get the numbers it needs.

The “double check connections” bit is probably correct. That error only happens when the MCU doesn’t respond, meaning that there’s probably a physical connection issue. It could have a pin shorted, could be rotated 180 degrees, could have a pin not making contact, etc. There could even be solder hiding under the MCU where it’s not visible.

Or it could also mean the chips were severely under-clocked at some point and aren’t running fast enough to respond at the expected rate. I did that once, before I knew it would effectively brick the chip. :frowning:

  1. I don’t have anything for AVRstudio unless a project’s author includes those files.
  2. The brightness is controlled by a ramp. IIRC, it’s called RAMP_FET in bistro-mini. Normally this would be a long list of 64 values per channel, but to save space it’s only 7 now.
  3. No.
  4. It doesn’t matter what program made it; it’s using the C99 language standard and avr-gcc tools+libraries.

You could replace each “include” line with the contents of the file it points at, and it would be literally the same as what the compiler does. But it’s usually easier to just copy the header files into the same directory as the C file.

Sorry about that. I normally don’t merge things into trunk until they’re fairly stable, and nobody except me had tested bistro-tripledown last time I touched it. But it can probably merge into trunk now that it has been used by more than just me.

The non-trunk branches are usually for development. Like, branch from trunk to a dev branch, make new features there for as long as it takes, then merge back into trunk after it’s all tested and working. Bistro-tripledown never quite got that final step.

The exception is a few project-specific stable maintenance branches, like blf-a6-final, which is frozen at the time the product released and only receives updates if/when the actual product is updated. Those are basically “stable releases”.

I’ve been leaving those in for reference, but commented out by default. This is because the build script sets that variable, allowing a single source file to compile perfectly on multiple MCUs with no changes. Here are the relevant parts of bin/build.sh:

...
export ATTINY=13
export MCU=attiny$ATTINY
...
export CFLAGS="-Wall -g -Os -mmcu=$MCU -c -std=gnu99 -DATTINY=$ATTINY -I.. -I../.. -I../../.."
...
run $CC $CFLAGS -o $PROGRAM.o -c $PROGRAM.c
...
run avr-size -C --mcu=$MCU $PROGRAM.elf | grep Full

So, if I use “build.sh” it compiles for attiny13, if I use “build-25.sh” it compiles for attiny25, and similar for “build-45.sh” and “build-85.sh” and any other MCUs we end up adding. No need to change the source for each MCU.

It uses the SRAM decay “noinit” trick to measure offtime, since the Convoy drivers have no OTC.

Okay. All pending updates to bistro, bistro-tripledown, and bistro-mini (biscotti) are merged into trunk. And I marked the tiny25 branch as merged (and thus not shown by default) since it’s merged and no longer in active development. Now the only branches visible by default are trunk, sandbox, and three stable releases for specific products.

Hopefully that’ll help make things a bit simpler and easier. :slight_smile:

Of course, there are a bunch of other things to catch up on too…

K, I just compiled/built bistro-tripledown successfully. Prog mem is 1976 bytes, 96.5% used.

Not sure where the source code for the mini version is now? Gone from the old link, not yet in the main trunk? bistro and bistro-tripledown are there though.

Help?

Sorry, I finally renamed it from bistro-mini to biscotti. It should be there, but it’s under bistro/biscotti instead of bistro/mini.

http://bazaar.launchpad.net/~toykeeper/flashlight-firmware/trunk/files/head:/ToyKeeper/bistro/biscotti/

K, see it. thanx!

Edit: Just got biscotti compiled/linked - prog mem is 1022 bytes .


This is a direct link to the bistro tripledown in ATMEL Studio V7, complete solution/project: https://drive.google.com tripledown AS7.zip

Note: it hasn't been run or tested, just compiled/linked!

This is a direct link to the biscotti in ATMEL Studio V7, complete solution/project: https://drive.google.com biscotti AS7.zip

Note: it hasn't been run or tested, just compiled/linked!

Every time I try to get into the repository code it gives me a 404 error?

This works for me: https://code.launchpad.net/~toykeeper/flashlight-firmware/trunk

But "browse the code" is broken. Looks like it's down, inaccessible right now.

Yeah, same thing I am experiencing. I was trying to grab the battcheck hex for the tiny25 so I could calibrate the Avenger drivers for the 22k R1. I tried flashing the one I have but get nothing, the driver works fine with bistro.

You mean bistro-tripledown?

Yeah, bistro-tripledown works fine but the battcheck.hex I have does nothing. I am going to try reflashing it and another driver just to be sure.

Ohhh - battcheck probably expects output pins to be in the normal positions, not like on a triple. This is probably why? Let me check if I have the source local.

Or written for a 13A?

Yeah, I am pretty sure it was written for the 13a but I thought there was a tiny25 version of it as I remember using it on an older tripledown with the same pinout as my TA drivers. I didn’t think to keep track of that file though so not sure where it is now.

I got the source for battcheck.c. It uses pin #6 for LED output, so that would be the 7135 bank. It does have support for both 13A and 25/45/85, but it's done at compile time.

Here's the full source:

/*
* This firmware simply helps calibrate values for voltage readings.
* It is not intended to be used as an actual flashlight.
*
* It will read the voltage, then read out the raw value as a series of
* blinks. It will provide up to three groups of blinks, representing the
* hundreds digit, the tens digit, then the ones. So, for a raw value of 183,
* it would blink once, pause, blink eight times, pause, then blink three times.
* It will then wait longer and re-read the voltage, then repeat.
*
* NANJG 105C Diagram
* ---
* -| |- VCC
* Star 4 -| |- Voltage ADC
* Star 3 -| |- PWM
* GND -| |- Star 2
* ---
*
* CPU speed is 4.8Mhz without the 8x divider when low fuse is 0x75
*
* define F_CPU 4800000 CPU: 4.8MHz PWM: 9.4kHz ####### use low fuse: 0x75 #######
* /8 PWM: 1.176kHz ####### use low fuse: 0x65 #######
* define F_CPU 9600000 CPU: 9.6MHz PWM: 19kHz ####### use low fuse: 0x7a #######
* /8 PWM: 2.4kHz ####### use low fuse: 0x6a #######
*
* Above PWM speeds are for phase-correct PWM. This program uses Fast-PWM,
* which when the CPU is 4.8MHz will be 18.75 kHz
*
* FUSES
* I use these fuse settings
* Low: 0x75
* High: 0xff
*
* STARS (not used)
*
*/
// set some hardware-specific values...
// (while configuring this firmware, skip this section)
#if (ATTINY == 13)
#define F_CPU 4800000UL
#define EEPLEN 64
#define DELAY_TWEAK 950
#elif (ATTINY == 25)
#define F_CPU 8000000UL
#define EEPLEN 128
#define DELAY_TWEAK 2000
#else
Hey, you need to define ATTINY.
#endif


/*
* =========================================================================
* Settings to modify per driver
*/

#define OWN_DELAY // Should we use the built-in delay or our own?

#define BLINK_PWM 10

/*
* =========================================================================
*/

#ifdef OWN_DELAY
#include <util/delay_basic.h>
// Having own _delay_ms() saves some bytes AND adds possibility to use variables as input
static void _delay_ms(uint16_t n)
{
while(n-- > 0)
_delay_loop_2(DELAY_TWEAK);
}
#else
#include <util/delay.h>
#endif

#include <avr/pgmspace.h>
#include <avr/interrupt.h>
#include <avr/wdt.h>
#include <avr/eeprom.h>
#include <avr/sleep.h>

#define STAR2_PIN PB0
#define STAR3_PIN PB4
#define STAR4_PIN PB3
#define PWM_PIN PB1
#define VOLTAGE_PIN PB2
#define ADC_CHANNEL 0x01 // MUX 01 corresponds with PB2
#define ADC_DIDR ADC1D // Digital input disable bit corresponding with PB2
#define ADC_PRSCL 0x06 // clk/64

#define PWM_LVL OCR0B // OCR0B is the output compare register for PB1

inline void ADC_on() {
#if (ATTINY == 13)
ADMUX = (1 << REFS0) | (1 << ADLAR) | ADC_CHANNEL; // 1.1v reference, left-adjust, ADC1/PB2
#elif (ATTINY == 25)
ADMUX = (1 << REFS1) | (1 << ADLAR) | ADC_CHANNEL; // 1.1v reference, left-adjust, ADC1/PB2
#endif
DIDR0 |= (1 << ADC_DIDR); // disable digital input on ADC pin to reduce power consumption
ADCSRA = (1 << ADEN ) | (1 << ADSC ) | ADC_PRSCL; // enable, start, prescale
}

inline void ADC_off() {
ADCSRA &= ~(1<<7); //ADC off
}

uint8_t get_voltage() {
// Start conversion
ADCSRA |= (1 << ADSC);
// Wait for completion
while (ADCSRA & (1 << ADSC));
// See if voltage is lower than what we were looking for
return ADCH;
}

void noblink() {
PWM_LVL = (BLINK_PWM>>2);
_delay_ms(5);
PWM_LVL = 0;
_delay_ms(200);
}

void blink() {
PWM_LVL = BLINK_PWM;
_delay_ms(100);
PWM_LVL = 0;
_delay_ms(200);
}

int main(void)
{
// Set PWM pin to output
DDRB = (1 << PWM_PIN);

// Set timer to do PWM for correct output pin and set prescaler timing
TCCR0A = 0x21; // phase corrected PWM is 0x21 for PB1, fast-PWM is 0x23
TCCR0B = 0x01; // pre-scaler for timer (1 => 1, 2 => 8, 3 => 64...)

// Turn features on or off as needed
ADC_on();
ACSR |= (1<<7); //AC off

// blink once on receiving power
PWM_LVL = 255;
_delay_ms(5);
PWM_LVL = 0;

uint16_t voltage;
uint8_t i;
voltage = get_voltage();

while(1) {
PWM_LVL = 0;

// get an average of several readings
voltage = 0;
for (i=0; i<8; i++) {
voltage += get_voltage();
_delay_ms(50);
}
voltage = voltage >> 3;

// hundreds
while (voltage >= 100) {
voltage -= 100;
blink();
}
_delay_ms(1000);

// tens
if (voltage < 10) {
noblink();
}
while (voltage >= 10) {
voltage -= 10;
blink();
}
_delay_ms(1000);

// ones
if (voltage <= 0) {
noblink();
}
while (voltage > 0) {
voltage -= 1;
blink();
}
_delay_ms(1000);

// ... and wait a bit for next time
_delay_ms(3000);

}
}

Then the one I have should be compiled for the 25 as that is all I have ever used. Odd, I will try it on another driver and see what happens. I generally flash in Linux, maybe my flash command was off as I did it in windows this time, I need to make a batch file for windows flashing to keep everything straight.

Browse the code is now working!

Great, got the 25 version and now it works fine. Not a lot of difference from the 19.1k but enough to need a change.

Ok, just got the voltage calibration for a 22k R1 resistor completed on a Texas Avenger driver. Initial calibration was set with my DPS3012 power supply and I tested it with various batteries at several voltages and everything lined up in the working driver great. So here is the updated 22k R1 calibration file if anyone is interested:

tk-calibration-22k-R1.h

Also here is my latest working revision of Bistro Tripledown, not 100% I am done tweaking it yet but it is pretty close to the end goal I am personally looking for. So far I have found no bugs or issues with it.

I changed the mode groups around some to better fit with the triple channel setup, I also added a 10th mode and removed the fancy flasher in order to allow for a single 7135 and all 7135’s only mode, which I find useful in some lights where the FET is simply not needed. Not sure what other changes there are other then that, kinda forgot at this point lol.

Texas-Avenger-Bistro-Tripledown

Actually I need to edit the C file to add a line for the new 22k calibration file so people can simply comment out one to select what they are using.

Is this calibrated for the otc as well. Or just voltage. Thanks for your work!

The OTC should be the same and appears to work perfectly in my drivers. It is the same 1uf cap that the original calibration was setup for, so I saw no reason to redo it.

The quality of the cap will play a much larger role. For example I find I had to replace all the OTC caps from the A6/X6 drivers as they don’t work right once hot but work fine when replaced with X7R 10% caps.

So the overall answer is yes, it is calibrated for a 1uf OTC cap, just not by me.