Emulator of Original Dell Charger Using ATTINY85(github.com)
github.com
Emulator of Original Dell Charger Using ATTINY85
https://github.com/KivApple/dell-charger-emulator
10 comments
The ATtiny85 is nice, with 8kB flash, 512 bytes RAM & EEPROM, 5-6 GPIO pins, they are just enough to do something interesting. But I don't use the ATtiny85 as much as I want to, because flashing requires a separate programmer hardware. It's enough friction to get in the way of rapid software iteration. I once made the mistake of inserting the ATtiny85 upside down into the programmer, and it promptly cooked it dead. Lesson learned.
The Digispark[1] and its clones use the ATTINY85 and offer flashing over USB via the Micronucleus bootloader[2] using V-USB[3]. It comes at the cost of a significant chunk of flash storage, but the convenience is excellent. Plus, V-USB support means you can emulate all sorts of USB devices. I've used it to build a DIY NES controller adapter, but it's commonly used as a cheap Rubber Ducky[4]. For projects where USB interfacing makes sense, it can be a good fit.
1: http://digistump.com/products/1
2: https://github.com/micronucleus/micronucleus
3: https://www.obdev.at/products/vusb/index.html
4: https://shop.hak5.org/products/usb-rubber-ducky-deluxe
1: http://digistump.com/products/1
2: https://github.com/micronucleus/micronucleus
3: https://www.obdev.at/products/vusb/index.html
4: https://shop.hak5.org/products/usb-rubber-ducky-deluxe
In circuit programming is just such a huge step forward. You still need separate programming hardware, but you don't need to pop the chip out.
Beyond that, a few hundred bytes is usually enough for a simple bootloader. That tends to accelerate things even more. And writing bootloaders tends to be fun. I've done a tinyusb bootloader on an attiny45 with the user program sharing the v-usb stack in the bootloader and also a CEC bootloader. The CEC one of course took several minutes.
Beyond that, a few hundred bytes is usually enough for a simple bootloader. That tends to accelerate things even more. And writing bootloaders tends to be fun. I've done a tinyusb bootloader on an attiny45 with the user program sharing the v-usb stack in the bootloader and also a CEC bootloader. The CEC one of course took several minutes.
All micros require separate hardware to flash it, no? Some is cheap (stlink), some are a few hundred dollars, but still.
Unless you have a USB bootloader programmed on the chip, but you still need the adapter to flash the bootloader in the first place.
Unless you have a USB bootloader programmed on the chip, but you still need the adapter to flash the bootloader in the first place.
Not at all! Many devices can be flashed over USB, for example. Many STM32 devices come with a bootloader factory programmed in a read only area that implement USB DFU.
Many user-provided software bootloaders can do the same on many other devices. Including the attiny85 using bit banging!
And of course with wireless enabled microcontrollers one can update over the air. Nordic NRF5x over Bluetooth for example, or ESP32 over WiFi.
And of course with wireless enabled microcontrollers one can update over the air. Nordic NRF5x over Bluetooth for example, or ESP32 over WiFi.
I think what the parent is getting at is that, because the ATtiny85 has so few pins, programming it usually requires it to be removed from the target circuit.
An MCU is a chip in a package that just cannot interface with anything your consumer PC or notebook comes with. You'll need an adapter in any case.
That said, lots of current MCUs come with UART, I2C and/or USB bootloaders allowing to erase/program (if not disabled). This bootloader is typically included in factory ROM, not to be programmed by you or a third party.
That said, lots of current MCUs come with UART, I2C and/or USB bootloaders allowing to erase/program (if not disabled). This bootloader is typically included in factory ROM, not to be programmed by you or a third party.
What? Why couldn't an MCU interface with my computer? It's not like it has special electrons or something in it. I regularly program atmega chips with a cable I made that plugs into the parallel port on the back of any computer that has one. If you have a couple GPIO pins on a motherboard, you can probably program almost any MCU with with it.
The only exception is if the motherboard GPIO was say 3.3v and you had a 1.8v only MCU, but level shifters aren't exactly expensive.
The only exception is if the motherboard GPIO was say 3.3v and you had a 1.8v only MCU, but level shifters aren't exactly expensive.
So do you jam the chip into the parallel port? Or do you...use an adapter?
I don't see the difference if it's just a parallel cable. Do you jam an STM32 into a USB port?
> Do you jam an STM32 into a USB port?
I unplug my phone for a moment, or use one of several identical cables I have lying around. If this thing needs a dedicated cable then that seems just as annoying in practice as needing a dedicated "programmer" box.
I unplug my phone for a moment, or use one of several identical cables I have lying around. If this thing needs a dedicated cable then that seems just as annoying in practice as needing a dedicated "programmer" box.
Another exception is the esp32-c3, which includes a jtag debugger inside the chip (not on board, inside the same die)
You can use Attiny412 with a simple USB-UART adapter for programming. Half the flash/SRAM but much more modern peripherals. $0.50 a piece, and unlike many other uCs recently tends to be in stock.
The old Dell barrel jack power supplies use 1wire communication to identify the power supply's capabilities. It would likely be cheaper to purchase a compatible 1wire memory module.
Here is an article on reverse engineering the memory module. https://hclxing.wordpress.com/2014/02/06/hacking-the-dell-la...
Here is an article on reverse engineering the memory module. https://hclxing.wordpress.com/2014/02/06/hacking-the-dell-la...
> and the battery will not charge (the picture is from internet but it has almost identical information)
Yikes! I used a no-name charger on my Dell Latitude for quite a while, and it never stopped me from charging. Just annoyed me about it (press F1 to continue on boot) whenever I took the battery out (wiping the CMOS) and didn't turn off the AC warnings in the BIOS. The one I was using didn't have a serial chip in it, so the laptop flagged it as unknown.
Yikes! I used a no-name charger on my Dell Latitude for quite a while, and it never stopped me from charging. Just annoyed me about it (press F1 to continue on boot) whenever I took the battery out (wiping the CMOS) and didn't turn off the AC warnings in the BIOS. The one I was using didn't have a serial chip in it, so the laptop flagged it as unknown.
It goes further than warnings though - at least circa 2012 using an unofficial charger (or official charger where this fragile extra wire is broken) would underclock the cpu dramatically. It happened silently, such that I didn’t realize what was happening and why my laptop was so
slow until stumbling upon a random forum post about it. I was pretty sour on Dell after that experience.
Really? I have a 2013 Latitude and I haven't experienced that yet (or never noticed). I still have the no-name adapter here, so I'll have to check (I only just got a proper 130W).
If that is the case, part of me wants to play Devil's advocate and say that Dell have erred on the side of caution: these no-name adapters really are quite terrifying with thermals, which makes me wonder what wattage they're actually rated for. I was frequently in WTF mode because the adapter block was too hot to keep my hand on. I didn't really have a choice either, as my battery was at like 38% capacity. This official 130W is barely warm under load.
Aside: one thing that really eek'd me out about that no-name adapter is that it has a green LED inside it. The only thing is, you can only (just barely) see it through the slits on the sides because the plastic isn't clipped together properly. The manufacturing quality is atrocious.
If that is the case, part of me wants to play Devil's advocate and say that Dell have erred on the side of caution: these no-name adapters really are quite terrifying with thermals, which makes me wonder what wattage they're actually rated for. I was frequently in WTF mode because the adapter block was too hot to keep my hand on. I didn't really have a choice either, as my battery was at like 38% capacity. This official 130W is barely warm under load.
Aside: one thing that really eek'd me out about that no-name adapter is that it has a green LED inside it. The only thing is, you can only (just barely) see it through the slits on the sides because the plastic isn't clipped together properly. The manufacturing quality is atrocious.
Update: looks like you were right[0], although it doesn't affect my 2013 Latitude, if Linux's cpufreq diagnostics are anything to go by.
# Running on battery power.
cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_max_freq
3500000
3500000
3500000
3500000
# No-name charger inserted.
cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_max_freq
3500000
3500000
3500000
3500000
# Genuine charger inserted.
cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_max_freq
3500000
3500000
3500000
3500000
Try applying load to the CPU and see what cpuinfo_cur_freq reports. If I boot my ThinkPad W530 (workstation laptop with a large power envelope) with no / dead battery, it will say full speed is available, but it will remain at the minimum speed until the battery is partially charged and I reboot.
This happens even on new Dell machines, even if the PSU is detected but a lower wattage than the shipped PSU. I have wondered if it affects Linux more than windows though
A quick way to check would be to `cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq` while you're on battery, then do it again after you've plugged in the PSU. I checked mine[0] and it apparently doesn't affect this model (the adapter I tested with does not communicate with the laptop at all).
[0]: https://news.ycombinator.com/item?id=30458632 (god I really suck with the links today, lol)
[0]: https://news.ycombinator.com/item?id=30458632 (god I really suck with the links today, lol)
The original source linked from that article has unfortunately disappeared, but the archive still remembers:
http://web.archive.org/web/20100329110047/http://www.laptop-...
An explanation of (one of) the design flaws:
http://web.archive.org/web/20100412160453/http://www.laptop-...
Not only is it clearly hostile to the aftermarket, but putting a chip that has 12V absolute maximum ratings in an environment where it could easily be shorted to the 19-20V output of the PSU seems almost like "engineered unreliability" to me.
On the other hand, when IBM/Lenovo had to solve the problem of identifying the wattage available, they used a simple and robust solution of a single resistor:
https://www.thinkwiki.org/wiki/Power_Connector#Signal_Pin
https://www.thinkwiki.org/wiki/Power_Connector#Signal_Pin_2
The only improvement I could make upon that scheme would be to make the correspondence between resistance and wattage monotonic, but otherwise it's an example of non-overengineering and aftermarket-friendly solution.
http://web.archive.org/web/20100329110047/http://www.laptop-...
An explanation of (one of) the design flaws:
http://web.archive.org/web/20100412160453/http://www.laptop-...
Not only is it clearly hostile to the aftermarket, but putting a chip that has 12V absolute maximum ratings in an environment where it could easily be shorted to the 19-20V output of the PSU seems almost like "engineered unreliability" to me.
On the other hand, when IBM/Lenovo had to solve the problem of identifying the wattage available, they used a simple and robust solution of a single resistor:
https://www.thinkwiki.org/wiki/Power_Connector#Signal_Pin
https://www.thinkwiki.org/wiki/Power_Connector#Signal_Pin_2
The only improvement I could make upon that scheme would be to make the correspondence between resistance and wattage monotonic, but otherwise it's an example of non-overengineering and aftermarket-friendly solution.
I have a strip of ATTINY85's at hand for misc electronic projects and they've been really great for beginner-level circuits and learning embedded programming. I'm a dev by trade but have a bit of electronics knowledge and these are cheap enough to not worry about frying them and still get the job done.
They're such a nice starting place for embedded dev! I'd messed around with Arduino things for a long time, and recently started messing with the chip itself without the abstraction. The ATTINY series is powerful enough for many things while having a relatively small and easy to work with footprint (from a physical and register standpoint). It's actually possible to go through the entire datasheet and understand it, then poke all the right registers. It's also satisfying to be able to plop it onto a breadboard!
I'm excited for the Rust + AVR world to move forward a bit so I can keep playing with it without the currently required hacks :)
I'm excited for the Rust + AVR world to move forward a bit so I can keep playing with it without the currently required hacks :)
In case you're interested, there's a new project underway that aims to make running Nim on AVR (and eventually other micros through BSPs) as easy (but leaner and more performant) as Arduino: ratel.peterme.net
Nim can already run on most MCUs (I've experimented with samd21 and rp2040), it just requires a few compiler flags or linking steps that are not super well documented. Ratel aims to automate that and provide some high level interfaces for hardware access (gpios, etc).
Nim can already run on most MCUs (I've experimented with samd21 and rp2040), it just requires a few compiler flags or linking steps that are not super well documented. Ratel aims to automate that and provide some high level interfaces for hardware access (gpios, etc).
Nice work! I've been trying to stand up nesper/nephyr, the Nim overlays for ESP32 and Zephyr, but had quite a few issues (not all of which are those library's fault, the ESP-IDF toolchain is horrid in a lot of ways). I wonder how difficult it would be to extend Ratel over to ESP32 if I have a working toolchain already. I might have a crack at it, we're big on Nim at work and are trying to get away from C++ for our firmware development wherever possible.
To be clear: Ratel isn't my project, just something I'm following due to interest.
In the interest of shameless self promotion :), my own experimentations are :
https://github.com/EmbeddedNim/svd2nim
https://github.com/auxym/nim-on-samd21
And I've used and contributed to picostdlib (https://github.com/beef331/picostdlib), the rp2040 support library.
All just as a hobby, but it's interesting to learn that some companies are actually looking into Nim for firmware! Embedded seems like such a slow moving industry. I believe the author of Nesper and Nephyr also developed them for professional work.
In the interest of shameless self promotion :), my own experimentations are :
https://github.com/EmbeddedNim/svd2nim
https://github.com/auxym/nim-on-samd21
And I've used and contributed to picostdlib (https://github.com/beef331/picostdlib), the rp2040 support library.
All just as a hobby, but it's interesting to learn that some companies are actually looking into Nim for firmware! Embedded seems like such a slow moving industry. I believe the author of Nesper and Nephyr also developed them for professional work.
As an update, after ditching the project/build tooling setup that Nesper required, I got Nim working wonderfully (with Nesper's library itself as a dependency) within PlatformIO and ESP-IDF on an ESP32 :)
I even have hardware UART support and have a working SIM7000 modem connection going (though only with AT commands, not PPPoS yet, though I'm planning on that next).
Nim is the future of firmware development, of that I am sure.
I even have hardware UART support and have a working SIM7000 modem connection going (though only with AT commands, not PPPoS yet, though I'm planning on that next).
Nim is the future of firmware development, of that I am sure.
Incredibly slow moving, buggy and badly documented! Embedded is a fun challenge but rough.
Nim I believe is an answer to it though, and embedded being slow moving with a C target is perfect for it!
Nim I believe is an answer to it though, and embedded being slow moving with a C target is perfect for it!
I just learned this week that my old Dell Venue 11 Pro's will happily accept 19/20V if given, without any sideband communication. The laptop has a custom Dell charger, and usb-micro input, which could negotiate via a custom protocol to a higher power level.
But folks are reporting that if you make a 20V USB-micro, they'll charge. Sweet. Riskier than this links careful negotiation over 1-wire, but so convenient. I'll probably rip apart one of my usb-c to 20v barrel jacks & make a cable, in case I want to go back to these units. The need for a custom charger has been a huge barrier to ever wanting to use them again, very nice that these old systems will just work, when given power.
But folks are reporting that if you make a 20V USB-micro, they'll charge. Sweet. Riskier than this links careful negotiation over 1-wire, but so convenient. I'll probably rip apart one of my usb-c to 20v barrel jacks & make a cable, in case I want to go back to these units. The need for a custom charger has been a huge barrier to ever wanting to use them again, very nice that these old systems will just work, when given power.
I assume the purpose of this would be to build a Dell compatible charger but this repo doesn't appear to provide much information on how to actually do that. I get that the microcontroller provides the signalling the laptop needs to identify the charger, but assuming you built this circuit, how would you actually use it to charge a laptop ?
In schematic.png you can see on the left there are 3 pins and the right there are 2 pins. The 3 pins on the left represent the laptop and the two pins on the right represent the power supply. The chip in the middle attaches to the ID pin on the laptop and reports the charger to the laptop.
Yes, I was confused because my Dell laptop power input doesn't have 3 wires (unless there's somehow a third wire buried in the barrel connector), so I was assuming that the ID signal is somehow just combined with the actual input voltage.
I believe the old Dell chargers simply have a data pin, which I presume would carry the data generated by this project
I guess it would also be helpful to know what range of laptops this is for. I was assuming it was for relatively recent models. I have an Inspiron that's about 5 years old and it has a barrel connector for power. It's not obvious that it contains a third pin. I have at times had problems with the laptop refusing to recognize various power adapters though.
It's a bit over my head, but the schematic in the readme seems to have a shared ground, with one pin going to the attiny microcontroller, and the other going to a generic power source. With a big warning that your power source needs to be up to spec.
If the connector on the left represents the output of a generic power supply then I still don't see how you would connect this on the laptop side.
EDIT: On further thought I think that connector must be intended to represent the laptop input and Vcc is the output of a generic power supply (with sufficient voltage and current capacity). It was not clear to me because my Dell laptop doesn't appear to have a 3-pin power connector so maybe this only applies to certain models.
EDIT: On further thought I think that connector must be intended to represent the laptop input and Vcc is the output of a generic power supply (with sufficient voltage and current capacity). It was not clear to me because my Dell laptop doesn't appear to have a 3-pin power connector so maybe this only applies to certain models.
Looks like you connect the data pin of the ATTiny to the data pin of the charger jack. The schematic only has two components, the ATTiny and a power regulator for it, then the input is charger power and the output is charger power + data.
See also the from-scratch Thinkpad battery with an ATTiny85: https://github.com/iam4722202468/ThinkpadBattery
I don't understand why people use the attiny85... The Atmega328 based boards have far wider software support in the arduino ecosystem, so you will typically be able to prototype a project in minutes instead of hours, and the dev boards cost the same, but the 328 ones have more of pretty much everything.
The only benefit of the attiny seems to be that you can save a few millimeters of board space, but if that's your concern there are plenty of far smaller, cheaper and more capable microcontrollers in BGA packages.
The only benefit of the attiny seems to be that you can save a few millimeters of board space, but if that's your concern there are plenty of far smaller, cheaper and more capable microcontrollers in BGA packages.
I wanted to gain experience in embedded programming at a lower level than Arduino (i.e. pure C & bitbanging). They're dirt cheap and also simple enough that I can read through the whole datasheet and pretty much understand everything.
It's also kind of a fun challenge working within the limitations on both the HW and SW side.
It's also kind of a fun challenge working within the limitations on both the HW and SW side.
I was intrigued by "dirt cheap" and went to buy a few tens, but they're apparently $2.5 or so each! I can get an ESP8266 for that amount, which has tons more processing power, RAM, space, and has WiFi. I really can't see why I'd use an ATTiny over that, unless the former cost $0.20 or so.
The obvious answer would probably be the size and the dip formfactor. Sure you can get more capable BGA packaged chips, but how many hobbyists have the ability to properly solder in a BGA?
The 328 is also available in dip...
Awesome work. I just dove into the world of AVR programming and bought a bunch of ATTINY85's. Super easy to work with, extremely versatile, and low power consumption.
Do you use a USB programmer, or did you buy ones that have a USB programmer built in?
The ATtiny85 is a rather small 8-bit microcontroller, and controllers in that size range generally don't have peripherals on the complexity level of USB. So no, there are no 85s with USB programming support built in.
Truth be told, the 85:s are a bit old now, it was released around 2005. But even the more modern "[012]-series" [1] don't support USB, it is kind of the point. The linked Wikipedia page says:
ATtiny microcontrollers specifically excludes various common features, such as: USB peripheral, DMA controller, crypto engine, or an external memory bus.
[1]: https://en.wikipedia.org/wiki/ATtiny_microcontroller_compari...
Truth be told, the 85:s are a bit old now, it was released around 2005. But even the more modern "[012]-series" [1] don't support USB, it is kind of the point. The linked Wikipedia page says:
ATtiny microcontrollers specifically excludes various common features, such as: USB peripheral, DMA controller, crypto engine, or an external memory bus.
[1]: https://en.wikipedia.org/wiki/ATtiny_microcontroller_compari...
Ok, thanks. (I meant a USB programmer integrated onto a board with the ATTiny85 soldered on). To answer my own question, there are these[1] USB boards that you can pop the ATTiny85 in to program it. I wrote an AVR emulator back in the day, and yeah, they definitely don't have USB :-)
[1] https://www.mouser.com/ProductDetail/SparkFun/PGM-11801?qs=W...
[1] https://www.mouser.com/ProductDetail/SparkFun/PGM-11801?qs=W...
There are AVRs with USB, in XMEGA series. But that's probably dead market segment, if you want something more complex than ATtiny/mega you usually go to ARM Cortex-M nowadays.
I flashed the Arduino bootloader on mine by using my Arduino Uno as a programmer
Is this safe though? (Aren't chargers the way they are for a reason?)
> If you connect an unoriginal adapter, the laptop refuses to charge the battery.
I'm generally against capital punishment, but for whatever exec pushed this through - I think we could make an exception.
I'm generally against capital punishment, but for whatever exec pushed this through - I think we could make an exception.