luxdrv - custom modes driver firmware with ramping

Thanks again for the reply...so hardware wise all I need to do is swap those resistors for the voltage sense circuit as you suggested and it'll work without any software modifications? As for the temperature circuit I'll leave the functionality out of this driver and simply use the inbuilt sensor of the Tiny25. I'll still have to implement it for the other circuit of course.

Now I do want to learn stuff here, so I've read through the code and I'm trying to determine how the overtemp function works. It appears to function in exactly the same way as the battery voltage sensing as well.

From what I can tell you have defined 2 variables called BATTMON and TEMPMON and assigned them each a set number - 125 and 87 respectively. Further on you also call bytes 'lowbattcounter' and 'overtempcounter' and set these to zero. Where do these variables come from? Are they fixed bytes in the Tiny25 eeprom (or whatever it is called)?

There is then a loop that is responsible for dropping the drive PWM based on either the battery level or the temperature sensed by the Tiny25. You then read the adc value. If this adc value is lower than the predefined threshold (125) and the low battery counter is greater than 8 (why 8 btw? Is this 8 measurements per second?) it turns the PWM down. If it's not lower it resets the lowbattcounter to zero. The temperature sensing appears to work identically except that it uses the tempread byte instead of the adc result.

Have I understood this correctly, even if my terminology is out?

Quick note - when you reset the lowbattcounter variable, you do so with lowbattcounter=0. When you reset the overtempcounter you did it with overtempcounter==0. Too many equal signs, or was the '==' intentional?

Thanks again. Might try and compile this before I hit the sack for the evening.

- Matt


EDIT:

I had to had 'const' to the start of the 'PROGMEM byte' line. Also you used a close parentheses instead of a close braces in the tempread line of the if loop we were talking about above. I also had to correct the == I was asking about above as the debug was telling me the line had no effect.

It compiles fine now. When I get time I will load it onto my Tiny25 driver and see if it runs :)

I wonder if it will work if I just remove the voltage sense resistors just to test the code works?

EDIT 2:

Fuses! I still have not tried loading the firmware, but what fuses should I use/how do I determine what fuses I should use? Actually - what do the fuses do lol!?

The == was a typo.. I did the modifications in a simple text editor on my tablet and didn't attempt to compile. Same for the parentheses instead of curly brace.. Sorry about that, but glad you got it sorted..

Fuses.. ah fuses.. That actually reminds me.. The Tiny13A runs at 4.8 or 9.6Mhz while the Tiny25 runs at 8Mhz. That might screw up the timing of stuff.. Don't have time to look into the code right at this moment to see what's time dependent - probably the Watchdog..

Just to get it running, your current resistors will be fine - It will never detect low voltage is all..

Fuses:

SELFPRGEN Uncheck.
RSTDISBL Uncheck
DWEN Uncheck
WDTON Uncheck
EESAVE Uncheck
BODLEVEL 1.8V
CKDIV8 Uncheck
CKOUT Uncheck
SUT_CKSEL Int. RC Osc, 8Mhz, 6CK/14CK+4ms

pilot!!! you are right!!! this is the reason!!!
thanks a lot man!!! :wink:

Hi, er, does anyone know of any software for Linux which could be used to flash DrJones drivers onto torches? I don’t have a Windows box to run WinAVR, and I’m not sure whether it would work under WINE or an emulator.

It looks like the tools are basically just a wrapped/configured copy of GCC with some extras, so I suspect it should be portable… but after compiling I’m not so sure I’d be able to flash anything.

Actually, watchdog should be fine timing wise - it runs off a different oscillator. Just change this line

#define F_CPU 4800000 //CPU: 4.8MHz PWM: 9.4kHz ####### use low fuse: 0x75 #######

to

#define F_CPU 8000000 //CPU: 8.0MHz PWM: 15.625kHz ####### use low fuse: 0xD2 #######


Will that PWM Rate be too fast for the AMC7135s? Maybe.. Shitty part, however, is that the next speed is 1.95Khz

Avrdude.

http://www.ladyada.net/learn/avr/setup-unix.html

My pleasure. Glad you can at least define the behavior now rather than it being a bug.

I'll forgive you for the typos Wink

In regards to the fuses, this may come off as a stupid question but I have to ask, are those fuse settings you list above set during compile in AVR Studio? Or can you flash the TinyAVR from within AVR Studio, and thus set them in the GUI when doing that?

I ask because up until now I've used AVR Dude to actually flash the TinyAVR, and and such have been setting the fuses manually from the command line. I looked at your list above and thought "How the $#&* do I apply that in AVR Dude" lol.

So PWM frequency is locked to the CPU frequency then? I guess you can't just underclock the CPU...

Actually I have noticed that DrJones has another firmware version called 'Nlite' that runs it's PWM frequency at 18kHz, and this is again designed for the NANJG series drivers, so provided he has tested this, 15kHz shouldn't be a problem.

- Matt

Something in the 15-18 kHz range is a practical limit for PWMing AMC7135 chips. And at that rate the smallest PWM value that will produce light is around 4 or 5. Smaller values just produce glitches on the output.

You can flash the ATTINY From Within AVR Studio and set them in the GUI. I like AVRDude and the LIN/UNIX Operating Systems in general, but this is one of those cases where ease of use goes to AVR Studio under windows...

It's locked to a small group of dividers of cpu frequency.... CPU_FREQ / (DIVIDER * 512) = PWM Frequency

For the Tiny25, DIVIDER can be 1, 8, 64, 256 or 1024.

You can 'underclock' the CPU if you use an external crystal. you can run it at 4.257487957 Mhz or any other arbitrary value.. The internal oscillator only runs at 8Mhz or 1Mhz, however.

I know you hate datasheets.. But they really do have all of these answers. None of this is mysterious once you've read the datasheet..

PPtk

Put the timer-counter in FAST PWM mode, and it’s PWM_FREQ = CPU_FREQ / (DIVIDER*256)

True.. Then you can get 3.9Khz or 31.25Khz. Not sure that helps or hurts.. 3.9Khz is plenty fast for dimming, in my opinion.. But some people swear they can 'see' it.. Just like they can hear the difference between 14Ga speaker wires and 14Ga, Oxygen Free, Unidirectional, Unicorn Infused Tellurium Copper Speaker Wires...

PPtk

I work with linux all day everyday and certianly like it more than Windows. If I didn't enjoy the odd video game or use Adobe products so much I wouldn't even have a windows box at home...but it's good to know AVR Studio can do it from within the GUI. I will have to try this the next chance I get.

I don't hate data sheets lol. I just either forget to read them (which is inexcusable) or am too dumb to understand what I'm reading half the time. Then again reading them may actually improve my knowledge, so I really should start. Shame on me Frown

I also agree with you on the frequency. I honestly believe some people convince themselves they can see it when they genuinly can't. Each to their own though. They can't complain about 15kHz so that will have to do!!!

Note: I can't get the quote tool to work properly at all!!!


Anyway...so I'm trying to use my USBASP V2.0 ISP programmer from within AVR Studio. I have done plenty of research and the best I can find is that people are adding the USBASP programmer as an external tool from within AVR Studio. Looking at the add external tools wizard, it appears to ask you everything from where the avrdude executable is, what arguments to pass it and so forth. So to me it looks like it's just mimicking a command line interface and thus I am usnure if it still allows for GUI based fuse settings or not, so some guidance would be appreciated.

Here is a screen shot of what I've got so far:

I'm just not sure exactly what I should put in the arguments line. I have done a fair bit of reading and from bits and peices scattered all over the interweb I have cobbled this together:

-P usb -p t25 -c usbasp -u -Uflash:w:"$(ProjectDir)Debug\$(ItemFileName).hex":i

Where:

-P usb: Tells AVR Studio to use the usb port (thought I have several so um...)

And the actual location of the hex file is dynamically assigned based on what project I have open when I run the external tool. I saved the tool, ran it and got the following output:

avrdude.exe: warning: cannot set sck period. please check for usbasp firmware update.

avrdude.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude.exe: Device signature = 0x1e9108

avrdude.exe: NOTE: FLASH memory has been specified, an erase cycle will be performed

To disable this feature, specify the -D option.

avrdude.exe: erasing chip

avrdude.exe: warning: cannot set sck period. please check for usbasp firmware update.

avrdude.exe: reading input file "C:\Users\Mattaus\Desktop\PICcolo ATMEL Project\Tiny25_luxdrv\Tiny25_luxdrv\Debug\Tiny25_luxdrv.hex"

avrdude.exe: writing flash (898 bytes):

Writing | ################################################## | 100% 0.63s

avrdude.exe: 898 bytes of flash written

avrdude.exe: verifying flash memory against C:\Users\Mattaus\Desktop\PICcolo ATMEL Project\Tiny25_luxdrv\Tiny25_luxdrv\Debug\Tiny25_luxdrv.hex:

avrdude.exe: load data flash data from input file C:\Users\Mattaus\Desktop\PICcolo ATMEL Project\Tiny25_luxdrv\Tiny25_luxdrv\Debug\Tiny25_luxdrv.hex:

avrdude.exe: input file C:\Users\Mattaus\Desktop\PICcolo ATMEL Project\Tiny25_luxdrv\Tiny25_luxdrv\Debug\Tiny25_luxdrv.hex contains 898 bytes

avrdude.exe: reading on-chip flash data:

Reading | ################################################## | 100% 0.49s

avrdude.exe: verifying ...

avrdude.exe: 898 bytes of flash verified

avrdude.exe done. Thank you.


So it looks like it worked, but as I worried about about above no fuses were set, so I have to manually pass them to the programmer.

Any ideas? I'm hoping SOMEONE is using USBASP within AVR Studio...

- Matt

So I have awoken fresh today and found this frankly excellent page: http://www.engbedded.com/fusecalc/

Also a nice page full of information for newbies like me: http://www.ladyada.net/learn/avr/fuses.html

I entered all the details as per Pilot's suggestions and got the following avrdude arguments required to set the fuses:

-U lfuse:w:0xd2:m -U hfuse:w:0xde:m -U efuse:w:0xff:m

I have to go out now but I will try these later today hopefully. It still doesn't solve the fact AVR Studio is just passing arguments to avrdude manually, but at least I don't have to manually type everything out every time I want to program a Tiny25!

- Matt

Dear PilotPTK,

Would you please teach me how to set the temperature threshold for luxdrv03c. Suppose, I want to set the temperature threshold at 55C. Thanks,

Sorry that I have confused that the luxdrv03c was wretten by Texaspyro yesterday.

Change the TEMPMON variable at the start of the code. No idea what to though :)

There is no temperature monitoring code in any of the LUXDRV versions that I have (up to ver 030)

Pilot made a few changes and posted it as 0.3c up the page a bit. I have fixed a few typos on it and can post a link to it (otherwise the forum interprets a few sequences as emoticons) if need be?

I can’t add much to the discussion (still reading and trying to understand), but from a practical point of view I dislike low PWM frequency as I can hear it. My eyes are complete junk but I have excellent hearing and can hear high frequencies better than most, which unfortunately also ties in with my OCD as disliking high frequency whine :slight_smile: So the lupodrv equipped light running at 18 or 19kHz PWM is blissfully silent, whereas the JonnyC programmed one (standard Nanjg PWM freq I believe) is unpleasant to use on medium or low unless I’m in a noisy environment, such as riding off road.