Emisar D4S review

I should probably add it to the diagram somewhere, but there isn’t a good place to put it… and it’s only relevant to some of the supported hosts. So it remains sort of hidden.

Those guesses are good enough to keep my scavenging to a minimum…

assuming bare male jumper pins are too big?

Thanks!

Have you verified that these DuPont pins will fit in the programming holes of the D4S? Because all of my DuPont connector pins are too fat for the holes drilled in the D4S board, and I had to build a programming harness with some solderless bread board jumpers that did fit.

I was originally going to use some jumper pins, but I couldn’t find any in my parts bins. So I used some random wire I found instead.

Hopefully Lexel’s flashing connector will become pretty standard soon, but for now things are a bit more ad-hoc. I refer to the pinouts in flashlightwiki whenever I flash the D4S. This is fine for one-time or occasional flashing, but inconvenient during development. So I still do most of my development on a decapitated Emisar D4 with its brains hanging out. It works fine as long as I don’t need to do thermal testing or hardware-specific stuff.

Igor, bring me some fresh brains for my experiments! :confounded:

The command: avrdude -p t13 -c usbasp -u -e will erase the contents of the chip so that it can be re-written to. Finally, flash the driver with the new firmware: (change the star.hex part to whatever you named your .hex file) avrdude -p t13 -c usbasp -u -Uflash:w:star.hex:a -Ulfuse:w:0x75:m -Uhfuse:w:0xFF:m Be mindful of the value of the fuses; they may change from firmware to firmware. In the above example, the “low fuse” is 0×75 and the “high fuse” is 0xff. Generally all firmwares will state the proper fuse values in the .c file.

Are fuse considerations/command for flashing the D4S?

or just the "avrdude.exe -p attiny85 -c usbasp -Uflash:w:anduril.2018-08-22.EMISAR_D4S.hex:a" command as is?

thanks!

Don’t do that. It’s unnecessary and it risks bricking the MCU. Hoop should really remove that part of the tutorial.

Also, don’t use “-p t13” on a tiny85. It can also cause problems.

I recommend using bin/flash-85.sh, or copying the command in that script and replacing the filename.

Some firmwares specify fuses within, and sometimes what they specify isn’t correct. I’ve tried to include a flash.sh script inside any project with non-default settings, and otherwise it’s probably best to use one of the bin/flash*.sh scripts matching the MCU type.

I should probably go through the entire repository sometime to check that the comments at the top of each file are actually correct, because some of them aren’t. In some cases, it’s just copy/pasted from another project and was never updated.

In any case, there is no need to erase the ROM before writing new data. At best, it’s redundant. And at worst, a couple people reported that the chip wouldn’t respond any more afterward.

Thanks for the caution.

The problem for me is I’ve read all the flashing posts, and have yet to find a succinct step by step foolproof process for a particular light that didn’t also include general flashing info—that might be useful to someone who knows what they are doing—or what all the specific flags and commands mean. I know zero about this and just hope to find the simplest way to flash my DS4 (as it has easy access to the driver and anduril is so alluring).

Just ordered the ribbon cable and the usbisp and hope to try it soon!

Thank you!

Mine always performs the erase command before flashing and I’ve yet to brick an MCU, which probably means the next one I flash will jam up big time! I’ve only built a few hundred drivers though, so I’m still pretty new to all this.

Since the code formatting changed I don’t make any adjustments at all. I used to change power levels and such in the A6 firmware, but somewhere along the way the code started looking like an instruction manual for flying Alien spacecraft so I leave it strictly alone now.

This is about as short as possible, for someone who hasn’t done it before. I wouldn’t call it foolproof though:

  1. Get a usbasp device, a ribbon cable, and some solid-core wire or jumper pins which fit into the D4S flashing holes. Hardware links are available at the Link in my signature.
  2. Install avrdude.
  3. Download a pre-compiled .hex file for the D4S. Whatever is most recent here.
  4. Connect the usbasp to the D4S driver using the ribbon cable and pins, according to the pinouts listed in the wiki.
  5. Run “bin/flash-85.sh anduril.DATE.EMISAR_D4S.hex” or, in Windows, copy the command inside of flash-85.sh, replace the filename, and run it.

If avrdude reports success, you’re done! Pull the pins out and use the light.

For other lights, the instructions are similar except they involve a SOIC8 clip instead of jumper pins, and they often involve un-soldering things in order to make the driver accessible.

With Lexel’s flashing key, it replaces the jumper pins and eliminates the need to look up pinouts. Acquiring a key might be tricky, but it makes flashing very quick and easy.

Sorry about that.

I noticed things were getting pretty messy too, so I tried to clean it up by locking the spaghetti in a box. Here’s an example of how it looks afterward… an implementation of the UI from Olight’s Baton series:

http://toykeeper.net/torches/fsm/baton.c

Of course, Anduril is more complicated… but even with that, I’ve tried to make it relatively easy to customize by commenting out lines at the top which enable or disable features.

Wow…thanks!

I get the mechanics…putting pins in things, plugging in cables…good at running windows programs…
Hardware ordered…links to what I bought (no clip for now…will scrounge up some solid-core wire):

https://www.amazon.com/gp/product/B077X7MKHN/ref=oh_aui_detailpage_o00_s00?ie=UTF8&psc=1

https://www.amazon.com/gp/product/B00AX4WQ00/ref=oh_aui_detailpage_o00_s00?ie=UTF8&psc=1

(assuming the usbisp will not need new firmware or any jumper changes)

I must admit: Run “bin/flash-85.sh anduril.DATE.EMISAR_D4S.hex“ or, in Windows, copy the command inside of flash-85.sh, replace the filename, and run it.

confuses me.

I know to replace the file name with “anduril.2018-08-22.EMISAR_D4S.hex”

But the “run” command (in a command prompt window?) and the “flash-85.sh” (thats in a avrdude windows program)?
Perhaps it will make more sense when I actually have the items in hand and can play around with the hardware/avrdude.

Appreciate all the specific help!

Thanks!

That part is different depending on which OS you use. I’m using a Linux-based OS, so I’ve been using shell scripts for a lot of things. I run “flash-85.sh anduril.hex” and it works. The current contents of “flash-85.sh” are:

#/bin/sh
FIRMWARE=$1
avrdude -c usbasp -p t85 -u -U lfuse:w:0xe2:m -U hfuse:w:0xdf:m -U efuse:w:0xff:m -Uflash:w:$FIRMWARE

So on Windows, instead of “flash85.sh anduril.hex”, it would be more like this: avrdude -c usbasp -p t85 -u -U lfuse:w:0xe2:m -U hfuse:w:0xdf:m -U efuse:w:0xff:m -Uflash:w:anduril.hex

This happens at a command prompt. Alternately, you could find a GUI wrapper for avrdude, and use the mouse. Or convert the shell script into a Windows .BAT batch file.

Great info!

I’m gonna try eXtreme Burner- AVR (GUI)

Thanks for that information. I wonder where would the XM-L2 (or XM-L) fit in terms of lumens/power (though they’re not XP-sized…)?

The side indicator LED of the BLF Q8, when installed with Anduril, can be configured to have breathing effect (On-Off-On-Off) = is that also costly in terms of power consumption?

XM-L2 would be a little lower than the XP-L HD. Same/similar forward voltage, and therefore same current, but the XPL HD is, I believe, available in high flux bins than the XM-L2

The breathing effect is costly in terms of power regardless of whether it’s on a button or front-facing LEDs. However, Anduril does not have a breathing mode. The closest it has is a blinking mode, and that doesn’t really cost any extra power.

What is the breathing effect?

Not toykeeper, but this command is enough to flash the D4S. You still need to have avrdude installed