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.
From what I gather; Crescendos Firmware with ramping will work with a tailcap clicky switch, correct?
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.
Yes, and personally I’ve had better luck using it on reverse clicky rather than forward clicky tailswitches.
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.
@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.
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
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)
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.
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.
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.
ah-haaa, i shall give it go, thank you.
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 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
the .h file was from here (hwdef-FET_7135.h)
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 8| VCC
* OTC |2 7| Voltage ADC
* Star 3 |3 6| PWM (FET)
* GND |4 5| PWM (1x7135)
* ——
*/
#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 0x03 // 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, 1x7135 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 0x01 // MUX 01 corresponds with PB2
#define ADC_DIDR ADC1D // Digital input disable bit corresponding with PB2
#define ADC_PRSCL 0x06 // 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
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.
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.