Crescendo clicky firmware by TK

92 posts / 0 new
Last post
Maiden666
Offline
Last seen: 2 months 3 days ago
Joined: 10/18/2014 - 18:15
Posts: 186
Location: Spain

Hi.

I‘ve flashed a Nanjg105D (Crescendo firmware), but I cant access to the memory activation I have push the indicated times in the instructions and also more times. I cant access.
Does anyone know what problem is? (Fuses are correct).

Thank you very much.

SeniorXJ
Offline
Last seen: 3 months 2 days ago
Joined: 09/23/2018 - 02:27
Posts: 103
Location: United States

From what I gather; Crescendos Firmware with ramping will work with a tailcap clicky switch, correct?

pc_light
pc_light's picture
Offline
Last seen: 19 hours 39 min ago
Joined: 03/24/2017 - 16:19
Posts: 297
Location: United States

Maiden666 wrote:
Hi.

I‘ve flashed a Nanjg105D (Crescendo firmware), but I cant access to the memory activation I have push the indicated times in the instructions and also more times. I cant access.
Does anyone know what problem is? (Fuses are correct).

Thank you very much.

Did your flash of Crescendo involve a port/edit of the standard Crescendo code? It is possible that mode memory is one of those additional features that was removed in order to fit the standard Crescendo code into the smaller memory space of the ATTiny13a MCU used on the Nanjg105D driver.

Move towards the light.

pc_light
pc_light's picture
Offline
Last seen: 19 hours 39 min ago
Joined: 03/24/2017 - 16:19
Posts: 297
Location: United States

SeniorXJ wrote:
From what I gather; Crescendos Firmware with ramping will work with a tailcap clicky switch, correct?
Yes, and personally I’ve had better luck using it on reverse clicky rather than forward clicky tailswitches.

Move towards the light.

Maiden666
Offline
Last seen: 2 months 3 days ago
Joined: 10/18/2014 - 18:15
Posts: 186
Location: Spain

Thanks SeniorXJ and PC_Light.

Do you have knowledge of where I can download the firmware crescendo for the ATTiny, being able to choose which additional features has been removed?.

I can do without strobo and other things, but memory is important for me.

Thank you.

pc_light
pc_light's picture
Offline
Last seen: 19 hours 39 min ago
Joined: 03/24/2017 - 16:19
Posts: 297
Location: United States

@Maiden666. the small amount of memory in the ATtiny13 MCU limits the code that can fit. I had a similar experience when I first tried Crescendo13 on a BLF A6 driver which like the Nanjg105D uses the ATtiny13a.

In order to get Crescendo to fit the ATtiny13, Toykeeper had to pare the original file down to fit, which necessitated elimination of Config and some other special modes.

I am NOT a coder and have never used C but FWIW, working slowly through TK’s excellent commented source Crescendo.C file. I was able to (hack) my way through the code to retain Memory by sacrificing the smoothness of the Ramping. It was the only place I could squeeze out enough space to restore the Config and other features. So now I have Crescendo with Memory working on the ATtiny13 but ramping is a little choppy compared to the original smooth version.

I am reluctant to share my .hex for two reasons (1) our two driver boards are different, and (2) I’m unsure of how properly share altered versions of TK’s code. But hopefully this will give you an idea that might work for you.

You may also want to consider gChart’s ramping_ui which was actually written for the Nanjg driver.

Move towards the light.

carpmon43
Offline
Last seen: 3 months 2 weeks ago
Joined: 01/20/2019 - 18:40
Posts: 115
Location: uk

is this the crescendo?

crescendo?

pc_light
pc_light's picture
Offline
Last seen: 19 hours 39 min ago
Joined: 03/24/2017 - 16:19
Posts: 297
Location: United States

carpmon43 wrote:
is this the crescendo?

Yes.

The crescendo.c is the source C code file. The Crescendo.hex and Crescendo25.hex (for ATtiny25 based driver) are two compiled version. These can be customized and re-compiled/built following the instructions in crescendo.c file for driver specific differences of various driver.

Move towards the light.

carpmon43
Offline
Last seen: 3 months 2 weeks ago
Joined: 01/20/2019 - 18:40
Posts: 115
Location: uk

pc_light wrote:
carpmon43 wrote:
is this the crescendo?

Yes.

The crescendo.c is the source C code file. The Crescendo.hex and Crescendo25.hex (for ATtiny25 based driver) are two compiled version. These can be customized and re-compiled/built following the instructions in crescendo.c file for driver specific differences of various driver.

thank you.

been trying to get the C file to build..hmmm

carpmon43
Offline
Last seen: 3 months 2 weeks ago
Joined: 01/20/2019 - 18:40
Posts: 115
Location: uk

ok, it’s time to ask,

i keep getting

tk-attiny.h: No such file or directory
recipe for target ‘main.o’ failed

and after ferkin with this and that (like i have a clue lol)

the calibration library/directory then gets listed in the failed build as no such file or directory.
(i’ve added the directory/library files that come with the cresendo into the library folder in Atmel studio as advised on youtube by various peoples, right click library file, browse to the folder, select the directory files and ok, they then appear in the solutions part in the library folder). The furthest i’ve got with this is to get all the directory files mentioned as no such file or directory in a failed build.

i’m using Atmel studio 7, and get the same results in Atmel studio 6.2. the torch is a Convoy C8 with the red driver board that it came with . (i think i saw the BLF guy on you tube call it the driver the NanJG type but..erghh.)

i notice in the comments it said ‘’// Also, assign I/O pins in this file’‘, what do i define as what? and where?

and i don’t see any cpu frequency setting, do i need to add that too?

also there’s a line above the ramp setting ‘’ ../../bin/level_calc.py 1 64 7135 4 0.25 1000’‘ i assume this is paired with the ramp line #define RAMP_CH1 4,4,4,4,4,5,5,5…… after it, as in uncomment the line?
….just to get more fun out of it, ermm i see more than one ramp channel? ermmm? need i give up lol..

(bare in mind i’ve just got the blinky code working on a free standing 13A chip..)

basically i’m looking for ramping, no flash modes and memory,and moonlight, can any body help or point me to some proper reading?
where’s the error code list and explanations for Atmel studio? and there must be a good C language dictionary some where, the one’s i found all say things like ‘char… chars it in alien talk by folding nonigomo’bi directional oddey ferkums to the’ … and so on. I found some ramp/float code that looked like it was simple for ramping, can i find it on a google again, neeeee-ope.

(google really isnt your friend lol! it’s more like a Pinokio episode at some fun park, eee-ore..eeee-ore)

pc_light
pc_light's picture
Offline
Last seen: 19 hours 39 min ago
Joined: 03/24/2017 - 16:19
Posts: 297
Location: United States

Carpmom43, I’m not a coder but I’m glad to share what I know and/or have figured out over time, lots of time.

The error is referring to a needed “include” file which in this case is “tk-attiny.h”. The compiler needs to know where that and any other support files are located. Many of the programs support files have their Paths declared as a part of the Amtel Studio’s configuration options. Others, particularly files unique to a user’s *.c files must be provided.

I personally place a copy of the referenced *.h includes (tk-attiny.h, tk-calibration.h… – located in TK’s main repository directory) in the same location as the main/crescendo.c file to make my life easier.

Some of the other parameters such as CPU frequeny, Pin assignments etc. are configured in the other referenced Include files based on the HW configuration that you declare such as “#define ATTINY 13” and “#define NANJG_LAYOUT”.

Earlier I recall some of the *.c files containing path prefixes with “..\..\” these simply point to directories two parent directories up; again, just change as needed to point to the actual locations on your computer.

I believe the red convoy driver is single channel so you will need to pick one ramp, which ramp will depend on smoothness, capability of the driver to light on lower levels, etc. and I don’t believe the …calc file is needed when using the suggested ramp levels.

I hope that helps a little.

————————-
Also, I think it’s been referenced before but it is certainly worth repeating. gChart’s compiled ramping_UI.hex for the Attiny13 is a simpler ramping without all the features but has worked for me straight out of the box.

Move towards the light.

carpmon43
Offline
Last seen: 3 months 2 weeks ago
Joined: 01/20/2019 - 18:40
Posts: 115
Location: uk

pc_light wrote:
Carpmom43, I’m not a coder but I’m glad to share what I know and/or have figured out over time, lots of time.

The error is referring to a needed “include” file which in this case is “tk-attiny.h”. The compiler needs to know where that and any other support files are located. Many of the programs support files have their Paths declared as a part of the Amtel Studio’s configuration options. Others, particularly files unique to a user’s *.c files must be provided.

I personally place a copy of the referenced *.h includes (tk-attiny.h, tk-calibration.h… – located in TK’s main repository directory) in the same location as the main/crescendo.c file to make my life easier.

Some of the other parameters such as CPU frequeny, Pin assignments etc. are configured in the other referenced Include files based on the HW configuration that you declare such as “#define ATTINY 13” and “#define NANJG_LAYOUT”.

Earlier I recall some of the *.c files containing path prefixes with “..\..\” these simply point to directories two parent directories up; again, just change as needed to point to the actual locations on your computer.

I believe the red convoy driver is single channel so you will need to pick one ramp, which ramp will depend on smoothness, capability of the driver to light on lower levels, etc. and I don’t believe the …calc file is needed when using the suggested ramp levels.

I hope that helps a little.

————————-
Also, I think it’s been referenced before but it is certainly worth repeating. gChart’s compiled ramping_UI.hex for the Attiny13 is a simpler ramping without all the features but has worked for me straight out of the box.

yes that does help, thank you.

carpmon43
Offline
Last seen: 3 months 2 weeks ago
Joined: 01/20/2019 - 18:40
Posts: 115
Location: uk

think i’ll admit defeat on this one, still cant get any .h files to ‘register’…must be summut i’m missing for all files to be unrecognised. ahhh well back to google punishment.

EasyB
Offline
Last seen: 1 month 2 weeks ago
Joined: 03/09/2016 - 15:24
Posts: 1679
Location: Ohio

carpmon43 wrote:
think i’ll admit defeat on this one, still cant get any .h files to ‘register’…must be summut i’m missing for all files to be unrecognised. ahhh well back to google punishment.

I’m starting flashing again after a long break so I’m refiguring this stuff out. When I was compiling crescendo today I had similar errors. In my case atmel was creating a folder within the main directory. The various .h files had to be in that folder in order for them to be found.
Mike C
Mike C's picture
Offline
Last seen: 1 day 5 hours ago
Joined: 01/22/2014 - 08:03
Posts: 2317
Location: Sweden

I don’t get why all this stuff with .h header files. Don’t people use simple one C file solutions? I do, it makes all this stuff so much easier to manage.

Anyhow, try this… found out where string.h is in your avr studio folder (if you are using avr studio) and copy all tk-*.h files to that folder. I use AVR Studio 7, and in my case the folder is:
C:\Program Files\AVRStudio7\7.0\toolchain\avr8\avr8-gnu-toolchain\avr\include\

This is the default include folder, all “default” header files that are included are refering to this folder. Includes that have avr\ in front are in the avr sub-folder. If you have previously complied firmware which uses included files (such as eeprom.h) successfully, this should work.

carpmon43
Offline
Last seen: 3 months 2 weeks ago
Joined: 01/20/2019 - 18:40
Posts: 115
Location: uk

ah-haaa, i shall give it go, thank you.

pc_light
pc_light's picture
Offline
Last seen: 19 hours 39 min ago
Joined: 03/24/2017 - 16:19
Posts: 297
Location: United States

Speaking only for myself, this C stuff is Greek to me, last time I tried to compile a program was in Assembly on a machine running CP/M, which was was before DOS was even a thing :-0

@Mike C, any chance we’ll get a try a version of your “UI #3 off switch ramping” for Attiny13 based drivers? Looks dandy.

Move towards the light.

carpmon43
Offline
Last seen: 3 months 2 weeks ago
Joined: 01/20/2019 - 18:40
Posts: 115
Location: uk

i had to find and add a .h file to the folder mike.c specified (nice one tyty)

next question, i can either have memory mode or battery check, for a

battcheck, Program Memory Usage : 812 bytes 79.3 % Full Data Memory Usage : 10 bytes 15.6 % Full

or memery mode Program Memory Usage : 842 bytes 82.2 % Full Data Memory Usage : 12 bytes 18.8 % Full

the question being, how much memory needs to be ‘free’? i know from the 3D printer boards/quadcopter boards and atmel chips they need up to 50% free memory or they start to choke a bit.

by enabling/disabling here for a compile that succeeds.(memory 250 and battcheck 251)

// 255 is the default eeprom state, don’t use
// (actually, no longer applies… using a different algorithm now)
// (previously tried to store mode type plus ramp level in a single byte
// for mode memory purposes, but it was a bad idea)
#define DONOTUSE 255
// Modes start at 255 and count down
#define TURBO 254
#define RAMP 253
#define STEADY 252
//#define BATTCHECK 251
#define MEMORY 250
//#define MEMTOGGLE 249 // Extra mode to (en/dis)able memory (requires MEMORY)
//#define TEMP_CAL_MODE 248 FIXME: NOT IMPLEMENTED YET
//#define BIKING_MODE 247 // steady on with pulses at 1Hz

carpmon43
Offline
Last seen: 3 months 2 weeks ago
Joined: 01/20/2019 - 18:40
Posts: 115
Location: uk

the .h file was from here (hwdef-FET_7135.h)

.h file

and just in case the web page vanish’s as they quite often do. (copy and past, save as whatever file and change the file exstention to .h.)

/* FET + 7135 driver layout * —— * Reset |1 Flat Stare VCC * OTC |2 7| Voltage ADC * Star 3 |3 6| PWM (FET) * GND |4 5| PWM (1×7135) * —— */

#define STAR2_PIN PB0 // If this pin isn’t used for ALT_PWM
#define STAR3_PIN PB4 // pin 3

#define CAP_PIN PB3 // pin 2, OTC
#define CAP_CHANNEL 0×03 // MUX 03 corresponds with PB3 (Star 4)
#define CAP_DIDR ADC3D // Digital input disable bit corresponding with PB3

#define PWM_PIN PB1 // pin 6, FET PWM
#define PWM_LVL OCR0B // OCR0B is the output compare register for PB1
#define ALT_PWM_PIN PB0 // pin 5, 1×7135 PWM
#define ALT_PWM_LVL OCR0A // OCR0A is the output compare register for PB0

#define VOLTAGE_PIN PB2 // pin 7, voltage ADC
#define ADC_CHANNEL 0×01 // MUX 01 corresponds with PB2
#define ADC_DIDR ADC1D // Digital input disable bit corresponding with PB2
#define ADC_PRSCL 0×06 // clk/64

//#define TEMP_DIDR ADC4D
#define TEMP_CHANNEL 0b00001111

#define FAST 0xA3 // fast PWM both channels
#define PHASE 0xA1 // phase-correct PWM both channels

Mike C
Mike C's picture
Offline
Last seen: 1 day 5 hours ago
Joined: 01/22/2014 - 08:03
Posts: 2317
Location: Sweden

pc_light wrote:
@Mike C, any chance we’ll get a try a version of your “UI #3 off switch ramping” for Attiny13 based drivers? Looks dandy.

Sorry, I can’t go back to doing anything in the 13a. I don’t have any around so I can’t even test, and with 16kb I’ve written everything freely. To fit anything on the 13a I would have to do some serious byte hunting. I won’t touch the 85 anymore either, I have too many projects in line to dust off any code that has to do with them.

carpmon43 wrote:
how much memory needs to be ‘free’?

I don’t know anything about 3D printer and quadcopter boards, but with our flashlight firmware the program memory doesn’t need anything free. Data memory usage is a different matter, I guess it depends on programming, but program memory (which is actual firmware size) can be filled all the way up.
carpmon43
Offline
Last seen: 3 months 2 weeks ago
Joined: 01/20/2019 - 18:40
Posts: 115
Location: uk

Mike C wrote:
pc_light wrote:
@Mike C, any chance we’ll get a try a version of your “UI #3 off switch ramping” for Attiny13 based drivers? Looks dandy.

Sorry, I can’t go back to doing anything in the 13a. I don’t have any around so I can’t even test, and with 16kb I’ve written everything freely. To fit anything on the 13a I would have to do some serious byte hunting. I won’t touch the 85 anymore either, I have too many projects in line to dust off any code that has to do with them.
carpmon43 wrote:
how much memory needs to be ‘free’?
I don’t know anything about 3D printer and quadcopter boards, but with our flashlight firmware the program memory doesn’t need anything free. Data memory usage is a different matter, I guess it depends on programming, but program memory (which is actual firmware size) can be filled all the way up.

thank you, with the printers n quads I think its as you’ve said the data usage, theyre using quite a bit more processing than the flashlight ui’s. In the case of the flight controllers, they have 4 motors continualy updating in 16bit hundred of times a second, a gyro, accelerometer etc etc all doing the same thing hundreds of times a second and all cordinating.

nar i have to sort the de soldering of the pill to get to the C8 driver out lol..yes i tried it in situe, as yu do just incase.
Hopefully the attiny chip will just accept the program …dum dum dummmm..drum roll lol.

if i may ask what chips are you up too?

carpmon43
Offline
Last seen: 3 months 2 weeks ago
Joined: 01/20/2019 - 18:40
Posts: 115
Location: uk

pc_light wrote:
Speaking only for myself, this C stuff is Greek to me, last time I tried to compile a program was in Assembly on a machine running CP/M, which was was before DOS was even a thing :-0

@Mike C, any chance we’ll get a try a version of your “UI #3 off switch ramping” for Attiny13 based drivers? Looks dandy.

i second that.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 4 hours 8 min ago
Joined: 01/12/2013 - 14:40
Posts: 9734
Location: (469219) 2016 HO3

I didn’t see this thread until today, but some people have reported that, instead of using AVR Studio, it’s easier to get things working using the Linux subsystem for Windows 10. I’m not sure exactly what one must do to install that, but once it’s there, it becomes a lot easier to make things “just work” by typing in a few short commands.

This probably isn’t very helpful, but a few people have found it easier than converting projects to Atmel’s build system so it might be worth a look.

carpmon43
Offline
Last seen: 3 months 2 weeks ago
Joined: 01/20/2019 - 18:40
Posts: 115
Location: uk

ToyKeeper wrote:
I didn’t see this thread until today, but some people have reported that, instead of using AVR Studio, it’s easier to get things working using the Linux subsystem for Windows 10. I’m not sure exactly what one must do to install that, but once it’s there, it becomes a lot easier to make things “just work” by typing in a few short commands.

This probably isn’t very helpful, but a few people have found it easier than converting projects to Atmel’s build system so it might be worth a look.

most things on the the net are linux based, and ‘C skinned’ for windows, probably why more things are easier to do, alas, it’s only second hand knowledge.

i dont supose you could knock up a dimmer only with memory/memory off and lvp?… (with little crawlies and pleasums..lol)

i’m newb, but i found some C command’s for ramping that i cant find now, was only a few lines but on par with the old printf 1-100 unless interupted..do you think its posable a simple ramp up or down could be implomented easily for clickies? may reduce the size of the UI enough to get the lvp etc to fit onto the attiny 13’s. just a thought.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 4 hours 8 min ago
Joined: 01/12/2013 - 14:40
Posts: 9734
Location: (469219) 2016 HO3
Mike C wrote:
I don’t get why all this stuff with .h header files. Don’t people use simple one C file solutions?

For individual projects, yes. When multiple projects share the same code though, including a shared file is generally easier than keeping multiple in-line copies in sync.

Normally I’d have a set of .c/.h files for each logical group of functions, all compiled separately into .o files and then linked together into a single binary. That complicates the build system though, and for such small projects I doubt it’s really necessary.

I’ve used a similar approach in FSM though, just without the linker step, because the whole point of that project is to abstract out the hardware implementation details so the main program can be written with simpler more intuitive language. For example, this is a working clone of the Olight Baton UI, using FSM. It’s 5810 bytes of source code and includes basically everything except the self-timer mode. And for comparison, this is another Baton clone written using a single-file model. It’s 18211 bytes, includes significantly fewer features, has more bugs, and is harder to read.

That’s only one small data point in a sea of code… but it still demonstrates fairly common patterns which often result from different approaches to code organization.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 4 hours 8 min ago
Joined: 01/12/2013 - 14:40
Posts: 9734
Location: (469219) 2016 HO3
carpmon43 wrote:
do you think its posable a simple ramp up or down could be implomented easily for clickies? may reduce the size of the UI enough to get the lvp etc to fit onto the attiny 13’s. just a thought.

I already did… it’s called Crescendo. It fits onto attiny13 when the optional blinky modes are disabled at compile time.

carpmon43
Offline
Last seen: 3 months 2 weeks ago
Joined: 01/20/2019 - 18:40
Posts: 115
Location: uk
ToyKeeper wrote:
carpmon43 wrote:
do you think its posable a simple ramp up or down could be implomented easily for clickies? may reduce the size of the UI enough to get the lvp etc to fit onto the attiny 13’s. just a thought.

I already did… it’s called Crescendo. It fits onto attiny13 when the optional blinky modes are disabled at compile time.

ahhh, i see. ty ty.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 4 hours 8 min ago
Joined: 01/12/2013 - 14:40
Posts: 9734
Location: (469219) 2016 HO3

It’s also worth taking gChart’s ramping UI for a test drive. It has some improvements, especially on tiny13.

carpmon43
Offline
Last seen: 3 months 2 weeks ago
Joined: 01/20/2019 - 18:40
Posts: 115
Location: uk
ToyKeeper wrote:
It’s also worth taking gChart’s ramping UI for a test drive. It has some improvements, especially on tiny13.

i’ll take a look, again ty.

Mike C
Mike C's picture
Offline
Last seen: 1 day 5 hours ago
Joined: 01/22/2014 - 08:03
Posts: 2317
Location: Sweden

carpmon43 wrote:
if i may ask what chips are you up too?

ATtiny1634.

ToyKeeper wrote:
When multiple projects share the same code though, including a shared file is generally easier than keeping multiple in-line copies in sync.

I certainly agree that with complex projects it makes sense, but for flashlight firmware I would just use copy and paste if I had multiple firmware files. I don’t have multiple files myself, I have them all in one and decide which one to compile with #defines. Makes backup real easy… a single file… One file to rule them all.

Pages