Welcome JonnyC. Good to have you here, I hope you enjoy your stay.
Aloha and welcome to BLF JonnyC!
I received a bunch of 101-AKs last Tuesday, all were equipped with ATtinys. Ordered on December 26.12., received on 10.1. KD really seem to have streamlined their delivery process.
If anybody's interested in news from the PIC port, I have given up on the open source tool-chain. SDCC just isn't anywhere near GCC when it comes to code quality or features. I switched to Microchip's Hi-Tech compiler, which also sucks hard enough to pull golf balls through a garden hose, but at least it produces working machine code.
So far I managed to implement timer-interrupt based PWM and something analog to the watchdog-timer ISR I used in the AVR version. It looks like I can use the same basic architecture as in the original BLF-VLD. Today I wanted to test the PWM, so I copied some mode functions over from the AVR version and they just worked without any changes. I'm almost tempted to try keeping a common code base between AVR and PIC...
That sounds very good (given my growing collection of PIC based drivers).
But Hi-Tech compilers did not used to come cheap! (I have used Hi-Tech C compiler in the past so I know that Aussee compagny, there were also some bugs....., but the firm was always responsive and fresh to do corrections).
How much would the new expences be to cover the PIC development (lightest set-up)?
Happy to see that you keep up your enthusiasm despite job-hunting and perhaps little interrest from the forum - not so many with MCU programming experience, I think.
Hi-Tech's "Light" version is free, but the produced code size is atrocious. I couldn't get the driver to fit into the program area, even with just a single mode function compiled in. Using the "Demo" version, I still got 15% free space, and that is with all available mode functions added. So it seems like I won't be allowed to distribute compiled hex-files. Maybe we can find somebody with a Pro license to build these for us, so they can be distributed legally.
Some good news. Today I felt a bit daring and just copied the missing parts of code over from the AVR source. After adding some functions for compatibility (mostly EEPROM stuff) and changing register names, I managed to compile the driver and it just worked. So far, all the mode functions and switching between standard and extended mode groups are working. Only mode programming is broken, but that shouldn't be too hard to figure out. I'm really surprised at how easy it was to port this thing.
Now I have to find a way to flash the program into a real driver PCB. So far, I only tested it on my breadboard model. None of my PIC-based driver PCBs will allow me to use the debugging clip, as the MCU is always obstructed by other components. I think I'll have to glue something together from two connecting plugs with 1.27mm pitch.
Thanks for that report!
That confirms my worries; I guess I'll not go that way and stick to AVR instead. Fortunately AVR drivers are still available.
sixty545: I edited my post; It now has a working link.
So, what we have now for KD SKU S009742 is:
delivery date, version
nov.22 105 ATtiny13A sixty545
dec.16 105 Attiny13
dec.27 105A PIC sixty545
dec.28 105A PIC for the 5-pack
jan.03 105A PIC pipopopo
jan.14 105 ATtiny13 DrJones
jan.27 105C ATtiny13A Nautic
mar.1 105C ATtiny13A sixty545
mar.4 105C ATtiny13A Buwuve
maybe not a lottery any more...
[edited]: added input from DrJones. Could be that the 105A only was delivered in a time window dec.27 - jan.03 
[edited jan.27]: added Nautic, looks like PIC is ended, but new type 105C (for the moment), dare to order, now let's see...
[edited mar.1]: added sixty545, got them eventually, was 105C fortunately.
[edited mar.4]: added Buwuve 105C
That is true for 7135 based drivers, but there is only one AVR controlled boost driver I know of, the NANJG-112A. Unfortunately, this one is nowhere to be found anymore.
sixty545: Add these:
delivery date
dec.16 105 Attiny13
dec.28 105A PIC for the 5-pack (doh...)
@Tido: I'm more into 18650 lights anyway.
I wonder how difficult it is to build a reasonably good 3A buck driver (for XM-L on 2*18650) with a µC though...
So, what we have now on KD SKU S009742 is…
My 5-pack delivered last week was with PICs. Ordered them early this year.
Too bad, I’d much prefer atmels too.
The picture of the 5-pack SKU: S009835 at KD is in fact showing the 105A with PIC !
The picture of SKU S009742 shows 105 with ATtiny13.
I can tell because I have both and the numbers are printed at different spots.
[Edit:] And welcome, boffid !
A very good point. By looking closely at the pictures they are indeed different! One seems to have an empty place for a resistor (besides the mcu) while the other looks like having a cap and no place for resistor.
Time to order some singles perhaps…
Good news, everyone. Although I still haven't managed to teach the toaster to feel love, I made some good headway on the BLF-VLD-PIC front. I've flashed a NJG-18 with the driver code and the result was better than expected. The PWM frequency is high enough not to result in any visible flicker (somewhere between 500Hz and 1kHzh) and mode programming actually works. The lowest low isn't anywhere near of what can be achieved with the Atmel's hardware PWM, but maybe I can find a way to work around that.
On a side note, did you ever notice that short blink some flashlights make when the mode memory kicks in? I used to think this was a deliberate feature, but it actually is a result of the missing hardware PWM. Interrupts have to be disabled during EEPROM writes, so the interrupt driven PWM gets suspended.
Good news indeed.
Yes I saw the memory blink using the AK-47C. But the NANJG 105A also have memory snap-in after 2 sec. but don't blink!
Can anyone suggest why the Mr.Lite J4 driver will only strobe on 14500 (This is the same driver as the BLF AA-Y4E but starts on high. It works fine with NiMH, but not with 14500 where all it'll do is strobe. I'm probably going to replace the driver anyway since I accidentally dedomed the XR-E in it and swapped in a reflector and an XM-L but if a quick spot of solder somewhere can sort out the existing driver, it would be useful to know. I can't make it strobe with an NiMH.
I don't see any voltage monitoring circuitry on the board, so it's unlikely that the driver software detects an overvoltage situation. From the software's point of view, everything is fine as long as the MCU gets enough power to run. Maybe the boost circuit is broken and shuts down when it detects a too high input voltage, then starts up again, shuts down... and so on.
But this is just idle speculation, I'd need to prod around the PCB with some measuring equipment before I could say anything definitive.
That sounds like a lot of work.
If you want it for interest, I can send it to you once I've done a driver swap in the light.
Thanks for the offer, but it would probably just end up in a drawer and get thrown away in the end, when they ship me of to a retirement home. Forty years from now...
I received my driver from Shining Beam (which he ran out of stock of as it's no longer on his site). It's a NANJG 101-AK with 4x7135's and an Atmel ATtiny13A.
I have been having a hard time keeping up with all of the information here as I'm really starting out from scratch on any of this stuff. So before I even dive into the programming I need to understand how the circuit is setup. There is one capacitor (brown SMD at C1) and two resistors (R1 10k, R2 3k), along with a diode. Referencing this diagram from a similar driver, found in the first post of this thread http://www.candlepowerforums.com/vb/showthread.php?t=192206&page=1, it seems as though the capacitor isn't used to condition any signals but to possibly maintain power to the MCU if the battery disconnects for a slight second (it's not very big, so I don't know how long it could power it.
PB1 (pin 6) is used with PWM to switch on the 7135's to drive the LED.
PB2 (pin 7) is connected to R1 (which connects to Vcc) and R2 (which connects to ground). Is this used for low-voltage monitoring? If so, how exactly does this work? I can't quite understand how the resistors are hooked up and what effect they would have.
PB4 came soldered to GND I assume to pull the pin to low triggering the MCU to keep us in a 3-mode group. After removing the solder, the light had more modes, although I couldn't quite figure out what the sequence was (although I assume there are 3 to 4 groups of modes or something with the ability to switch in between).
So I guess my last questions are, what capabilities does this board have without modifying it? Can that capacitor actually be used to determine short clicks vs. long clicks? Can PB2 be used to determine voltage levels, I assume through ADC? And if so, how do I even know to look for on PB2?
Tido, by the way, I downloaded your code and I must say I am really impressed. I'm just learning C and bitwise stuff, so I can mostly understand it, but it is really well organized and commented. I think this would be a huge hit over on CPF.
- Jon
The diode provides polarity protection for the MCU, the capacitor is there to filter out noise on the power supply line. Its job is to stabilise the supply voltage in case of very short (< 1ms) voltage sags. It won't be able to keep the MCU powered for more than a few milliseconds, especially if it also gets drained by the voltage divider, which is what the resistors are doing.
Yes, the two resistors form a voltage divider. It is used to bring down the supply voltage into the 0V - 1.1V range, so it can be measured by the MCU's analog-to-digital converter. If you are interested in how this works, please take a look at the README, where I tried to explain things in more detail.
I would guess that the drivers from shiningbeam use either a custom firmware or the firmware found in the AK-47s. The famous stars are just connected to I/O pins and the MCU basically checks which pins are pulled to ground on start-up. The mode group is then selected on this data. You could try soldering other I/O pins to ground and see if the mode group set-up is changing.
The capacitor is much too small for that and besides, it would need very good fine tuning of the components used to get mode switching via brown out detection working. I gave it a try some time ago and got nowhere. If you want the short/long power off distinction, the only reliable way is to use the resistor-diode-capacitor circuit we have discussed earlier in this thread. Take a look at this post on how to do it in an incredibly beautiful way.
Thanks for your praise. Personally, I think it has way too much #ifdef'ed code blocks, but it is the only way to cram this much configurable functionality into the tiny program space. The comments are as much for my own sake as they are for others. This was my first AVR based project and it really helps to "mumble along" to yourself in this form, while trying to figure out how to do things on a new system.
As for the CPF, the guys over there are free to use the code, as is everybody else. It's open source, after all. But I'm really put off by the general sentiment and rampant pack mentality over there, not to mention the petty power-crazy moderators.