I do appreciate the explanation of how the code is structured and how to add a mode, that will come in handy when I get that far...
My immediate problem was just getting the unmodified driver.c to compile, and here I must apologize. The driver.c code I was having trouble building is the code from sixty545, not from Tido. I just realized this during a sanity check, but after I posted above . I have been able to build Tido's driver.c successfully. Output looks like this: (and it flashes too)
(Although I'm not sure how to make the 'simple', 'fixed' and 'programmable' builds. But we'll save that for later...)
Its when I try to build sixty545's driver.c that I get the following warning and errors:
Warning 1 #warning "F_CPU not defined for <util/delay.h>" c:\program files (x86)\atmel\avr studio 5.0\avr toolchain\bin\../lib/gcc/avr/4.5.1/../../../../avr/include/util/delay.h 89 3 8mode
Error 2 'MODE_SOFTBEACON' undeclared here (not in a function) C:\Users\Bob\Documents\AVRStudio\8mode\8mode\8mode.c 299 5 8mode
Error 3 'MODE_SOS' undeclared here (not in a function) C:\Users\Bob\Documents\AVRStudio\8mode\8mode\8mode.c 300 5 8mode
This is how I got to the point where I did the changes shown in post#368 above.
All of the supplied .hex and .eep files from Tido and sixty545 have worked, I'm just having trouble building the one from sixty545.
I'm currently comparing the two side by side to see where a difference may lie. I'm going to take some time and if I'm still can't figure it out then I'll put together a better phrased question.
It looks like AVR Studio doesn't define F_CPU, so the delay routines don't work. If your MCU is running at 1.2MHz, just add a "#define F_CPU 1200000UL" to the code, or "-DF_CPU=1200000UL" to the compiler flags. If your MCU is running at 4.8MHz, use 4800000UL instead.
You must have somehow removed or renamed the function start_wdt() or moved it below the point where it is called. I can't really say anything more specific without reviewing the whole source code.
All these screen shots have gotten me much closer to getting my dream light program working.Thanks guys for unwittingly helping me along with my project.
This is the absolute best thread ever read and I'm glad that it is in BLF and not in CPF. It really opens new perspectives, new "playgroung" for a rookie modder like me. I would have never imagine that it was possible.
Warm thank you to you Tido for your "sharing mind" ("sharing spirit", "sharing attitude" (don't know the appropriate translation for this))...and to all of you.
EDIT:
I finally received the USBasp key with 10 wires ribbon, the black SOIC8 clip without ribbon, the bleu Romonia SOIC8 clip with 8 wires ribbon.
I tried to attach the blue clip first but i had an error message: "error: could not find USB device "USBasp" with vid=0x16c0 pid=0x5dc" so I tried to find a driver for the USBasp key (I installed WINAVR before this step but it seems that it didn't install the required driver).
First I donwloaded this one: "vusb-20100715.zip" but the windows installer could not find the driver in the folder pointed in the README file.
Then I downloaded another one: "libusb-win32-bin-1.2.5.0.zip". I'm not a computer guru but the "inf-wizard.exe" that is in the "bin" folder installed it fine by double clicking the ".exe" and choose "USBasp" in the list.
I tested the connection as it is recommanded in the wiki but I got the error message described for a bad connection. As I read that the blue clip could make bad connection I switched to the black clip that worked immediately so I was able to backup files from a NANJG 105C, NANJG AK-47 and NANJG AK-47A.
I tried to read the files and codes that came with BLF-VFD but I'm lost. My bad english doesn't help.
I know that it is just a beginning and what I done is a piece of cake for most of you but I just would like to report to other newbies some details to solve some problems I encountered.
AVR Studio 4 has been my nightmare. I am in the same boat as you I can backup the files, but I am unable to write to the chips so hopefully someday I will figure it out.
It looks like you are not executing avrdude in the directory the target files are located in. Either cd into the directory holding the target files or give a full path on the command line.
Probably yes. The last batch I ordered about three months ago was still equipped with ATtiny13s.
Yes. Well, not truly constant 50/500mA, but a PWM level that averages out to this values.
No. This would require one write cycle to the EEPROM for every light level passed during the ramping. Since the EEPROM ist rated for "only" 100,000 write cycles, this would probably wear it out in less than 1000 ramping operations.
Yes. Put it in the extended mode group, but not the main one.
It would be nice if someone makes a frontend for all that load of apps with dropboxes to quick select custom driver options and autocompile the choices in a flash ready format.
It can be done but someone must really sweat that one app. Willing to donate a few bucks for the martyr who would like to try such project and i bet i'm not the only one willing to contribute.
I really do not like the idea of learning some C++ or what is this based on (at least is not plain assembler).
Not me. I've even given up on keeping all possible driver configurations within a single source file. It's much easier and less error prone to just paste together a new driver from a library of standard functions and then add some glue code to make it all work together. At least if you know some basic C programming.
Actually the only reason i don't have the hardware yet is i never fully understood the rewiring of the soic clip to the usb programmer interface as from what i gathered have to be fiddled with.