The driver code that I have is not compatible with the Nanjg style drivers and would not be of much use… I plan on doing some Nanjg compatible code… someday, hopefully soon.
Have a look from post #155 on in the luxdrv thread: https://budgetlightforum.com/t/-/4672?page=3#comment-406170
There is some discussion there regarding the use of the luxdrv firmware on a Tiny25. I am busy working on code that will work with the Tiny25, but again it is based on the luxdrv firmware. I'm also VERY new to this so it'll take me days, whereas people like PilotPTK, texaspyro, DrJones, Tido etc could probably smash something out in 5minutes.
Note the code PilotPTK posted in post #157 has a few typos and 1 or 2 bugs in it. These are pointed out later on in the thread.
No problem, I will patiently wait for your good news.
Microa use a service to share code, don’t paste it into comments.
pastebin
ideone
gist.github.com
etc.
But don’t worry it seems you’re not the only one who can’t share code online. I guess this is normal outside programming places… but it’s horrible.
Mattaus: Fuses, Fuses calculator, and the rest just try to google or search on atmel and atmel/avr forums/programming related places
Fuses are settings of the chip. And no you can’t probably just take settings from one type of chip to another. Maybe they would work when the only difference is just the speed etc. But you gotta make settings for each chip you program for. Or at least be damn sure they are the same between those chips. And refer, see the chip’s documentation for the settings. There is something online, sure but it may be outdated. And I think you can even render your chip useless, brick it by wrong fuses so be careful what you set the fuses to.
great constructive comments yet again Jack, thanks. I found scanning through the code very useful and I’m more more inclined to read through it here than go to another site, open it in another program and then probably forget where it is or what it’s called. This is a fun and friendly place so quit being such a snobby ass.
Thanks Jack - I actually stumbled across those fuse calc pages in my own Googling :) I posted my progress and links in the luxdrv thread and have successfully flashed my Tiny25 circuits several times now - if only I could get the hardware to behave as expected now lol!
Thanks for the suggestion on Microa. I normally do use that or pastebin in other forums, but the mood around here is so relaxed that most people really don't seem to care...that being said however using a service like those two prevents emoticons from popping up in code directly pasted into the forums haha.
- Matt
Sorry for my impolite to post the codes here. I thought that the codes are originally wretten by Tido which is better to put them in the same place.
I'm a complete idiot with all this so far, I have managed to read & write to the drivers and can get the various VLD programs loaded and working (via copy-paste from the wiki page into the command line avrdude, just so you know any suggestion to 'change these two fuses and edit this line' will be something I'm not up to yet) but cannot for the life of me figure out how to lock in a group in the 'programmable' version. Tap sequence has me completely lost. I can get it into the extended mode, but cannot get it to stick there. 'Tap' is a half-press turning the light off, or on? AAAARGH
I think posting code here is the best approach. Links go bad over time. Code will be easier to access and preserve here.
The code you paste here may contain parts that are not allowed or convert into formatting on the forum.
You do not get syntax highlighting and you can’t save it to use it without selecting and copying, making a new file, pasting it, saving it…
It’s a good practice to not post code directly. If anything at least use CODE or NOPARSE BBcodes if this forum supports them or make HTML pretty code print.
Also you are likely to reach post length limit if you paste code into your post.
Plus some people prefer not to scroll over several pages of code when expecting comments.
Editing flashlight wiki AVR Drivers so it’s more up to date.
Will try to add the fuses info links there later.
Though somebody should update the BLF-VLD page.
If you guys are using BLF-VLD and modifying it, put some info there for others. So others don’t have to read hundreds of comments in this thread to find anything about BLF-VLD but can easily find it on wiki.
New stuff on wiki, maybe somebody will find it handy.
*the pictures is updated and the traces under ATtiny13A are correct now
Excelent stuff, thanks JackCY, I was just getting ready to dismantle a Nanjg 105c because I need it to be in square shape 
I found one side but not the other till now
Ah, cool, I may do that with one of mine as well and then update the traces but I could do it earlier with this picture
The traces are a guess under the ATtiny13A.
I need it somehow on a computer so I can figure out where to put another SOIC8, I think it’s PowerPAK SO-8, an Sir424DP. Hopefully get it sideways instead of Q1 & Q2 and heavily modify the traces or add my own small piece of board and hope I did not cut down too much of the battery compartment space. Might still have 3mm spare, might.
How did you take off all the components?
Just soldering iron or do you have a heat gun?
It’s kind of a bother to get these multiple pins components off.
Any guides on how to program these AVRs?
As I see everybody codes it a little differently and it’s a bit messy to read the codes available. They are not bad and are commented, which is nice but still, there is too MANY codenames (short meaningless names) and random numbers inserted all over the code 
And I need to write a custom driver anyway.
That’s not my picture, found it here on BLF but I have no idea in which thread.
As per component removal, you can do it with ordinary 3$ butane torch but you have to practice a bit so you won’t roast them
P.S. about the programing: I am preparing myself for that step a month or so but but can’t force myself to do it already so I could say that you are asking right question but the wrong guy :bigsmile:
Yeah yeah I was waiting for a long time and putting it off too 
I’ve found something around so I will read, watch it, just need to know what I can use = already found a list of the libraries and functions I think. Plus need to know how to setup things, no problem to probably decode the numbers and such, just what to call and what to use how.
I hope this thread is still followed…
I finally got a connection with ATTiny13A based chip and still didn’t flash anything on it… I’m trying to figure out the difference in command lines… AVR Wiki is using Tido’s files to flash finished firmware onto ATTiny13A and it’s using EEPROM file in command line…
The command line for flashing Dr.Jones’s NLITE firmware onto 105c skips eeprom.eep line completely… what is eeprom for ??? In Wiki for reading from chip, after comand line is executed, four files are created with .hex extension… flash is for flashing, fuses are probably fuses, just copy hex values into command line but what to do with fourth file, eeprom.hex?
All this stuff is brand new to me but I want to get as much knowledge as I can about programming these drivers…
Like… is it possible to read from driver (if it’s not protected) and then “clone” that firmware onto same driver later on? In case those four .hex files are to be used, what would be a command line for flashing be?
Thanks in advance…
I can only answer for this:
yes it is possible to read from the microprocessor (you are only accessing to MCU) but most of the commercially available drivers have some kind of protection.
There are 2 types of protection:
- protection from reading (if you try to read from MCU you will get unusable data, but you can still write your own firmware or upload nlite.hex or one of Tido’s firmwares, if you do that then there is no turning back, old firmware is gone for good)
- protection from writing (which means that you are stuck with firmware that is uploaded to MCU by manufacturer (or third party), there is probably reading protection also).
Drivers like Nanjg 105C or Qlite have reading protection and you can not backup that firmware, you can only upload your own firmware.
same as for Tido’s firmware but with different file names, somethink like this:
low: 0x75, high: 0xFF. this fuses are recomended by DrJones…
…and now I realise that you are talking about four *.hex files, what foru hex files, there is only one hex file in each of Tido’s sugested firmwares and that is BLF-VLD.hex but there are also BLF-VLD.eep, BLF-VLD.elf, BLF-VLD.Iss and BLF-VLD.map I think this other files are created by (RAD tool like AVR Studio) and they are something like reports about project building and compiling process! eep file might be for determining and structuring the data table in eeprom memory! but this file is not always necessary.
Well, that far I understand… protection and what can and cannot be read/written… I believe lot will be self-explained once I flash NANJG 105c driver and play around with it… but I can’t at the moment as I’m modding my LX2 - long postponed project to replace TIR and XRE with reflector and XPG2…
Anyway… as you guessed for those extra files, that would be also self-explained if we get around the error we’re getting when trying to build Dr.Jones luxdrv030 firmware in AVR Studio 4… Did you have any success going around that error you posted ??? It’s the same error I’m getting…
Let’s hope more knowledgeable members can jump in and shed some light of what’s what here… if EEPROM file is important at all or not (Tido is using one, Dr.Jones doesn’t for NLITE)… and the if fuse values that get read during read from drivers can be simply used in command line as they are written in that .hex file that extracts from source driver…
The thing is… besides the fact that I’d like to make my own firmware for ATTiny13A, I also have two older drivers, completely the same but different modes installed… One I really like, the other one is crap… chip on them is ATTiny85V and I hope I’d be able to clone a good one onto crappy one and have two identical drivers… That would be a huge step forward for me with all this (just like getting a connection with driver, even with soldering each leg, is)…
NLITE is the first program where I haven't had to flash the .eep file. That file is the initial EEPROM data that records the mode selection, how many times in a row you've cycled the light, etc. NLITE doesn't need the initial EEPROM data, it will just build it and store it the first time the light is powered up.
The only other file you need to flash is the .hex, which is the program code.
I don't have my script in front of me, but this is what I normally do...
- avrdude -p t13 -c usbasp (just test the connection, as my clip sometimes requires some fiddling)
- avrdude -p t13 -c usbasp -e (force an erase, as on some chips the auto-erase didn't work and it failed verification as nothing was programmed)
- the command to change the fuses
- the command to flash the hex and eep
I know the above can be combined, but I just like to do them separately.
Yes I did, but we are talking about the same thing in many different threads so I posted my answer to this question in luxdrv thread (just to keep things clean) where I started talking about this problem.