Flashlight Firmware Repository

[LightRider]

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

It’s under the tiny25 directory. Kind of confusing

[Texas_Ace]

@pilotdog68

Btw, where is bistro TripleDown? Didn’t see it in the bistro folder?

It is confusing getting around in that repo, it is in the tiny25 section: http://bazaar.launchpad.net/~toykeeper/flashlight-firmware/tiny25/files/head:/ToyKeeper/bistro/

EDIT: LR beat me to it.

[Serp]

LightRider, Tom E thanks. I will try to find the necessary files. But for me it is very unclear done this Page Flashlight Firmware Repository in Launchpad
Can I ask you to make an archive of the project for AVR Studio 4, or 5, or any other. With the right file …

PS Is this what I need? http://bazaar.launchpad.net/~toykeeper/flashlight-firmware/convoy/files/219/ToyKeeper

[LightRider]

After everything… All I needed was a computer restart. As a longtime windows user I should have known better. :person_facepalming:

serp: I’m not very knowledgeable with this stuff so I cant give you a step by step. how far have you gotten. have you ever flashed custom firmware prior to this?

the bistro mini .c file should be ready to go as is except you need to alter the directory of the files called for in all of the “include” commands that use “example file”. the include commands that use < and > do not need to be addressed.

I’m not confident with this stuff but maybe it will help some?

[Tom_E]

Only Studio 7 - that's all I have/use. I try to keep current with the latest version on it. I find it confusing as well.

Well, what I should do is make a working/tested bistro and bistro-mini Studio 7 solution, so two complete working ones (I believe I have the bistro done already).

I looked at the "mini" source quickly this morn and wasn't sure bout the bistro-mini.c and tk-attiny.h combination, because the mini source has the #define for "ATTINY 13" commented out, so looks like F_CPU never gets set. Ultimate test though is to compile/link and see if it works. Looks like guys have already built it successfully, so it must work, I would think.

Also not sure of her technique on detecting long/short presses, without an OTC, but maybe she doesn't detect that? Not sure how the UI works again.... My fault... Not sure if the mini version uses ON time memory or OFF time memory...

[Serp]

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

[ToyKeeper]

@pilotdog68

Alright guys, I need some help. Talk to me like I’m a total noob.

I am still using 13a’s, but I have found a few bugs in my version of blf-a6 that was adapted for Triple channel. So I figure now is as good a time as any to try bistro on a 25. I haev not even used the new system of config files or whatever they are called, I just alter the c file for every build and have a library of the ones I have used in other lights.

So, step by step, how do I configure bistro and flash to a 25, assuming I am already setup to flash hex files to 13’s?

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.

@pilotdog68

I just noticed LVP is nonfunctional on the modified version of blf-a6

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.

@LightRider

I am getting error message: program enable: target doesn’t answer. 1 Initialization failed, rc=–1 Double check connections and try again, or use -F to override this check.

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.

@Serp

1. Do you have Bistro-mini project for AVR Studio?
2. What a piece of code responsible for the brightness in the Moonlight and the low mode?
3. Will LED glow in the Moonlight if we take the driver for 1050 & 1400 mA?
4. I tried to open your C-file in AVR Studio but received entirely errors at compile time. In what program it is made?

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.

@pilotdog68

Luddite question: if I don’t want to use the .h file, can I just add all the “defines” back into the main bistro .c ?

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.

@Texas_Ace

It is confusing getting around in that repo, it is in the tiny25 section

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”.

@Tom E

the mini source has the #define for “ATTINY 13” commented out, so looks like F_CPU never gets set

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.

@Tom E

Also not sure of her technique on detecting long/short presses, without an OTC, but maybe she doesn’t detect that? Not sure how the UI works again…. My fault… Not sure if the mini version uses ON time memory or OFF time memory…

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

[ToyKeeper]

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.

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

[Tom_E]

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?

[ToyKeeper]

@Tom E

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.

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/

[Tom_E]

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!

[Texas_Ace]

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

[Tom_E]

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.

[Texas_Ace]

@Tom E

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.

[Tom_E]

You mean bistro-tripledown?

[Texas_Ace]

@Tom E

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.

[Tom_E]

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?

[Texas_Ace]

@Tom E

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.

[Tom_E]

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);

}
}

[Texas_Ace]

@Tom E

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.

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.