As I am running the board off of a +5V USB input, I can take advantage of the full clock speed of the ATtiny824 and run off of the 20 MHz internal oscillator without a prescaling the output to CLK_PER. I decided to do this as it lets me run the ADC at an effective 10 MHz (CLK_PER/2), reducing the amount of time it takes to perform an ADC read. Why?
On the schematic, an ADC read circuit using discrete transistors is used to prevent the battery from powering the ATtiny824 through its GPIO pin ESD protection diodes. To properly bias PMOS transistor Q1, a 100K ohm resistor (R2) is placed between its source and gate. The gate of Q1 is connected to the drain NMOS transistor Q2; when Q2 is activated by the MCU, current will flow from R2 to ground through Q2 and Q1 will conduct.
Note that the battery is directly connected to Q1's source and so current will flow through R2 whenever an ADC read is performed. This reduces the efficiency of the charge circuit, as current is diverted to this biasing resistor during ADC reads. The solution in the current implementation is to simply reduce the amount of time this circuit is active. This is accomplished by achieving faster ADC reads through speeding up the MCU.
Of course, I had to increase the ADC sampling duration to account for the fact that the transistor pair Q1/Q2 takes time to activate. Using a short sampling duration doesn't give the MCU enough time to wait for the battery voltage to appear and results in oddities when a battery is removed mid-charge, such as a "medium" charge being present. The idea is that removing a battery mid-charge should result in the 3.2V charge voltage abruptly appearing at the empty battery terminal, which tells the MCU that a "fully-charged" battery is present and to shut off the regulator. This would result in 0V appearing at the terminal and the user being informed that no battery is inserted.
I also noticed that the INTFLAGS register was never cleared for the TCB0 capture interrupt in the old code, which means that the ISR would fire off too often. Oops!
Zachary Murtishi
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.