Sold/Expired Discussion - Programmable Hotwire Regulated Driver drop-in for D-M@g

[Alan B]

Using voltage to determine remaining capacity doesn't wok AT ALL for Nimh batteries. It is pretty good for LiOn. I don't know how it works for the other chemistries. You might need to rethink this.

You are correct. It works well for Li-Ion. Most folks are using Li-Ion chemistries and would benefit from that. NiMH is another story. Not all options make sense for all configurations.

We could model the energy, and reset on nearly-charged voltage. I don't want to do that right now, save that for later.

At this point I'm putting a few future options into the user configuration GUI but they won't be implemented for some time.

 

[Starlight]

Most folks are using Li-Ion chemistries and would benefit from that.

Most folks may use some of your regulators with Li-on, but I have 3 of your regulators coming. One of the three goes into a Nimh light. I have one of Jimmy's in a LiPo light. I think there are more "other" uses than you think.

 

[Alan B]

OK. But even if 1/3 of folks use NiMH, that doesn't change the problem. Heck, my own hotwires are about 1/2 NiMH though I am changing more toward the Li-Ion side.

I am putting both types of energy gauges on the list - voltage and model based, for possible inclusion in the future. The model based approach will require a lot more information be entered into the software so the model will have some accuracy. Still it probably won't be too precise, but it should be able to discern full from nearly empty.

For this model we will need the battery amphour capacity and bulb current. We cannot readily account for leakage as the controller is not keeping time when the light is off. With the wildly varying leakage rates of NiMH they are not going to be accurate anyway. Not sure we can do much about that. I think if folks want a good battery capacity meter they may have to use Li-Ion. I don't see any way to really do a reasonable job with NiMH.

Any ideas??

 

[LuxLuthor]

Alan, sorry I have been AWOL. My dog's knee surgery is healing nicely after watching him like a hawk. Then I got sidetracked making a bunch of custom battery packs for people.

Later this week I'm gonna get these beauties working and testing out your new features. I have not read all the posts since my last one, but I suspect there may be a new software version?

 

[Alan B]

Yes. When you get ready to program let me know and I'll get you the latest software. At the present time I'm working on getting some regulators out the door, and as I test them I may make some fine adjustments to the software.

I am also working on the next major version of the software. At this stage it is a graphical user interface on the PC that allows the user to select the options for the regulator. It doesn't do anything at this time aside from interact with the user, but when complete it will build the code and load it into the regulator so users will not have to deal with all the current steps. It will also write a custom mini-manual document to go with the options selected. But that is some months away, maybe Christmas.

In the meantime I have added OneLevel mode, so now we have four modes - VariLevel, MultiLevel, OneLevel and Lockout mode. OneLevel is basic on/off normally at the memory level. I may add a momentary mode to that list, but have not done so yet.

You have been missed. Glad to hear things are doing well. I'm just getting back up to speed also after a week on vacation. Nice to be back, but lots of work piled up.

I also am upgrading my product photography setup and will soon have some nice photos to post. I got a pair of 320 watt-second Alien Bee flash units to produce some nice controllable light. 320 kilowatts for a millisecond. Bee fun to put that in a flashlight someday.

 

[LuxLuthor]

Yes. When you get ready to program let me know and I'll get you the latest software. At the present time I'm working on getting some regulators out the door, and as I test them I may make some fine adjustments to the software.

I am also working on the next major version of the software. At this stage it is a graphical user interface on the PC that allows the user to select the options for the regulator. It doesn't do anything at this time aside from interact with the user, but when complete it will build the code and load it into the regulator so users will not have to deal with all the current steps. It will also write a custom mini-manual document to go with the options selected. But that is some months away, maybe Christmas.

In the meantime I have added OneLevel mode, so now we have four modes - VariLevel, MultiLevel, OneLevel and Lockout mode. OneLevel is basic on/off normally at the memory level. I may add a momentary mode to that list, but have not done so yet.

You have been missed. Glad to hear things are doing well. I'm just getting back up to speed also after a week on vacation. Nice to be back, but lots of work piled up.

I also am upgrading my product photography setup and will soon have some nice photos to post. I got a pair of 320 watt-second Alien Bee flash units to produce some nice controllable light. 320 kilowatts for a millisecond. Bee fun to put that in a flashlight someday.

I saw those shots of the custom software project. Just a cool thing to have running on the side burner.

Believe it or not, I never got around to installing the studio software on my Netbook yet, even though I'm using it way more than I thought....especially with that external DVD burner. Anyway, do you still have a need for me to add to Petrev's document and take screenshots, etc. of all the initial install and update to latest version, etc.? I'll be doing it this weekend.

About all those other blinking voltage feedback suggestions, I think there should always be a KISS version for most users. The more complex setup and details might scare away too many.

 

[Alan B]

I saw those shots of the custom software project. Just a cool thing to have running on the side burner.

Believe it or not, I never got around to installing the studio software on my Netbook yet, even though I'm using it way more than I thought....especially with that external DVD burner. Anyway, do you still have a need for me to add to Petrev's document and take screenshots, etc. of all the initial install and update to latest version, etc.? I'll be doing it this weekend.

About all those other blinking voltage feedback suggestions, I think there should always be a KISS version for most users. The more complex setup and details might scare away too many.

I would not worry about documenting the install, hopefully we have enough already. When the newer system works it will be a lot easier and most of those steps will go away.

One thing about the way I'm doing options is that everything can be turned off and then the code is not in the regulator so it can't get stuck in some unwanted mode. If you want simple, that's what gets loaded into the regulator.

 

[Alan B]

...

About all those other blinking voltage feedback suggestions, I think there should always be a KISS version for most users. The more complex setup and details might scare away too many.

By your request, I have added an "Interface Level" control to the PhdConfig program. It will select between Minimum, Intermediate and Advanced User Interfaces. Changing this control causes the GUI to "cloak" all the unwanted controls, and it resizes accordingly on the spot. It is rather entertaining to watch.

Some progress has been made on the PHD Config GUI. I tossed out all the prototype code and restarted the project in Object Oriented style, and now the code is 1/3 of the original size and has more features. The interface to the compiler is working, as is the above mentioned UI Level. There is a bit more to do, including the interface to the actual chip programmers, and then a number of changes need to be propagated into the flashlight code itself (including getting rid of a lot of stuff that has been moved into the GUI).

I am using this project as a "filler", working on it when time is available that I can't do something higher priority, or when I need a break from other work. It is a fun little project.

 

[LuxLuthor]

I was just using the program today, getting it all ready to flash from the Acer. I'll email you.

 

[Alan B]

I was just using the program today, getting it all ready to flash from the Acer. I'll email you.

Today I experimented with using a batch file to do the compile as I have done in the past. It works fine. I think that AVR Studio won't be required and most of the steps go away with this batch file. This is much easier for most folks than the AVR Studio program.

Basically you edit the C file and select the options you want (using notepad or your favorite program editor), save the file, and double click on the compile batch file. If there are no errors you double click on the programmer batch file and it programs the sled. Two batch files plus the C file.

Different programmers can easily be accomodated with this setup. Some of them are much less costly than the avrisp2 that we are using now, like $20 instead of $35.

 

[LuxLuthor]

That's awsome! I don't think the $15 difference between the two programmers as a significant cost variable. If someone is in for one of these and/or Jimmy's and/or wquiles M6-R, it is a reasonable investment.

A batch file compile would be easier for people who have never done any of this kind of work. Less intimidating. Petrev's PDF makes it clear, but for people who are used to a drop-in and flick the switch, anything that can be done to make it easier would be a nice option. The only wrinkle I'm not sure about is if it would also map over to Jimmy's/wquiles projects. I have the two saved as separate profiles I load in AVR Studio which is pretty easy once it is setup.

 

[JimmyM]

That's awsome! I don't think the $15 difference between the two programmers as a significant cost variable. If someone is in for one of these and/or Jimmy's and/or wquiles M6-R, it is a reasonable investment.

A batch file compile would be easier for people who have never done any of this kind of work. Less intimidating. Petrev's PDF makes it clear, but for people who are used to a drop-in and flick the switch, anything that can be done to make it easier would be a nice option. The only wrinkle I'm not sure about is if it would also map over to Jimmy's/wquiles projects. I have the two saved as separate profiles I load in AVR Studio which is pretty easy once it is setup.

Yes. It will work just fine with both mine and Will's. There may be a couple of things different between the versions depending on things like fuses (programming fuses, not overcurrent protection). But the idea can be adapted pretty easily.

 

[Alan B]

That's awsome! I don't think the $15 difference between the two programmers as a significant cost variable. If someone is in for one of these and/or Jimmy's and/or wquiles M6-R, it is a reasonable investment.

A batch file compile would be easier for people who have never done any of this kind of work. Less intimidating. Petrev's PDF makes it clear, but for people who are used to a drop-in and flick the switch, anything that can be done to make it easier would be a nice option. The only wrinkle I'm not sure about is if it would also map over to Jimmy's/wquiles projects. I have the two saved as separate profiles I load in AVR Studio which is pretty easy once it is setup.

It takes a couple of parameter changes in the programming batch file, one for hex filename and one for chip type. Each project should be in a separate directory with sourcefile and two batch files. One for compiling and one for programming. These batch files can be provided along with the software. Later on with my new GUI the batch files will not be required and there will be a pushbutton programming interface in the GUI.

I tested it last night and ran into one snag with the AVRISP2. There are conflicting USB drivers for this programmer. One in AVR Studio and one in WinAVR. The one in AVR Studio is used by the IDE. The one in WinAVR is needed by AVRDUDE which is the batch file programmer. Only one USB driver can be loaded and if the wrong one is loaded things don't work and the errors are not very clear.

This may be why Lux's earlier effort failed. If you can, Lux, try AVRDUDE and see if it finds your AVRISP2 on your other system that didn't work:

batch file:
avrdude -c avrisp2 -p t45 -P usb:xx -v
@pause

The above batchfile won't program anything but it will try to find the AVRISP2 and communicate with it and the messages should be clear enough to see if it succeeded.

I'll have to work out the procedure to unload/reload USB drivers and do more testing. If AVR Studio is not ever installed the conflict won't occur. If AVR Studio is used you either have to program with batch files or with Studio's pushbutton launched GUI, not both unless you switch drivers. I have used Studio with AVRDUDE batch files instead of using Studio's programming pushbutton and it worked nicely.

I rarely use the features of AVR Studio, and it wastes most of the screen with features I'm not using. For most users this added complexity has little value. Setting these users up with batch files using WinAVR only may be a better choice. AVRDUDE is included in WinAVR so they would have one software to load.

 

[LuxLuthor]

Alan, I uninstalled both AVR Studio and WinAVR. Not sure if that uninstall removed USB drivers. Step One: Re-installed WinAVR and ran file:

C:\WinAVR-20090313\bin>avrdude -c avrisp2 -p t45 -P usb:xx -v

avrdude: Version 5.6, compiled on Mar  5 2009 at 09:59:30
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/

         System wide configuration file is "C:\WinAVR-20090313\bin\avrdude.conf"


         Using Port                    : usb:xx
         Using Programmer              : avrisp2
avrdude: usbdev_open(): did not find any (matching) USB device "usb:xx"

C:\WinAVR-20090313\bin>@pause

Now I will install AVR Studio and do it again

Edit: Done, and same result. Also running that on computer that AVR Studio runs on gives same result.

 

[Alan B]

I believe I have it figured out. Have switched between AVR Studio and
AVRDUDE several times. And no, uninstalling AVR Studio and WinAVR does not,
as I understand it, affect the USB Drivers that are the issue here.

Also note that changing drivers is a lot quicker and easier than changing
the software packages.

USB Driver loading for AVRDUDE and Atmel AVR Studio with the AVRISP mkII  

AVR Studio and AVRDUDE require different drivers for the Atmel AVRISPmkII 
programmer.  Only one of these drivers can be installed at a time. 
The information below allowed me to change drivers back and forth under 
windows XP.
  
 ====================
  
 Switching Driver Process:
  
 plug in the AVRISPmkII programmer
 in device manager find the device (locations shown below)
 right click and select "update driver"
 select "not this time" for windows update
 select "don't search, I will choose the driver to install"
 then click "have disk" and navigate to the dir shown below and install the 
  driver from there
  
 =====================
  
 for AVRDUDE compatibility
 install driver from: WinAVR<version> / utils / libusb / bin
 shows up in device manager at: libUSB-Win32 Devices / AVRISP mkII
  
 in this case trying to access from AVRDUDE with:
 [FONT=monospace]avrdude -c avrisp2 -P usb -v -p t45[/FONT]
 results in a whole bunch of info about the AVRISP
  
 =====================
  
 for Atmel AVR Studio compatibility
 install driver from: Program Files  / Atmel / usb
 then it shows up in device manager at: Jungo / AVRISP mkII
  
 in this case trying to access from AVRDUDE with:
 [FONT=monospace]avrdude -c avrisp2 -P usb -v -p t45[/FONT]
 produces: usbdev_open(): did not find any USB device: "usb"

 

[LuxLuthor]

Just confirmed the original problem of trying to start AVR Studio program, and clicking on it there is again no response on this PC. I don't know if the USB issue prevents program from opening. WinAVR opens on this PC. Anyway, uninstalling these programs again on this PC.

 

[Alan B]

Just confirmed the original problem of trying to start AVR Studio program, and clicking on it there is again no response on this PC.

Sorry, Lux. That is a different issue. The programmer is not called by AVR Studio that early. Some dll conflict perhaps.

In any case, you don't need AVR Studio to make code for the regulators. Only WinAVR is required, and a pair of batch files.

In this case the program file is called HotwireRegulator.c

to compile (compile.bat)

avr-gcc.exe -mmcu=attiny45 -Wall -gdwarf-2 -std=gnu99 -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT HotwireRegulator.o -c HotwireRegulator.c
avr-gcc.exe -mmcu=attiny45 -Wl,-Map=HotwireRegulator.map HotwireRegulator.o -lm -o HotwireRegulator.elf
avr-objcopy -O ihex -R .eeprom  HotwireRegulator.elf HotwireRegulator.hex
avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" --change-section-lma .eeprom=0 --no-change-warnings -O ihex HotwireRegulator.elf HotwireRegulator.eep || exit 0

@pause

to program the regulator (avrisp2.bat)

avrdude -c avrisp2 -P usb -p t45 -U flash:w:HotwireRegulator.hex -U eeprom:w:HotwireRegulator.eep
@pause

 

[Alan B]

OK, Success. Programmed Don's regulator with the above batch files. Note that I edited them so if you grabbed them earlier they may be changed slightly.

For a program editor I used Vim. Not that it matters. Notepad works fine too.

Compile the software by double clicking on the compile.bat file above. Then review the compiler output. I have a bunch of informational warnings coming out that tell about how things are configured. Make sure there are no real errors or non-informational warnings. Then close the compile window.

Then double click on the avrisp2.bat file. This loads the chip. Review the output in the window before closing it to see if there are any problems.

So edit the file, click six times, measure the output, enter it into the program, click six more times, done.

 

[LuxLuthor]

Alan, just so I have this straight....can you run through the programs that must be installed, and the folder these files must be in (including the HotwireRegulator.c file) when bat is launched?

I converted these to actual bat files and uploaded to my box.net locations:

• compile.bat

• avrisp2.bat

Please confirm these steps:

1) Edit the HotwireRegulator.c file you sent me, & save file.

2) Run the compile.bat

3) Plug in the AVRISP2 device via programming stick to my battery powered up Maglite with AlanB Sled. LED lights up.

4) Plug AVRISP2 USB connection to PC, other LED lights up.

5) Run the avrisp2.bat

6) Have fun with new light.
​

 

[Alan B]

Alan, just so I have this straight....can you run through the programs that must be installed, and the folder these files must be in (including the HotwireRegulator.c file) when bat is launched?

I converted these to actual bat files and uploaded to my box.net locations:

• compile.bat

• avrisp2.bat

Please confirm these steps:

1) Edit the HotwireRegulator.c file you sent me, & save file.

2) Run the compile.bat

3) Plug in the AVRISP2 device via programming stick to my battery powered up Maglite with AlanB Sled. LED lights up.

4) Plug AVRISP2 USB connection to PC, other LED lights up.

5) Run the avrisp2.bat

6) Have fun with new light.
​

1) The only thing that needs to be installed for this to work is WinAVR, as I understand it. This installs to the default location and is added to the execution path so it will work properly. (Note that I have not tested without AVR Studio installed.)

2) The two batch files and the program file xxx.c should be in the same directory.

3) The USB driver for the AVRISPmkII needs to be the one provided in WinAVR, as discussed above.

That's it.