Diff between reality and simulation (Attiny85)
I discovered an (at first sight) small difference in a firmware of an Attiny85, which had major impact in a real circuit. The crucial part is how a port pin is changed from an input (no pull up) into an output with high level. The circuit itself is a touch key based on the charge transfer method (https://fieldscale.com/learn-capacitive-sensing/schematic-of-charge-transfer-method/). It changes the port pins PB0 and PB1 from high to low and input to output (and vise versa) to transfer the charge of a smaller capacitor onto a larger capacitor. The smaller capacitor is actually your finger (body).
During a charge of the bigger capacitor the port pin PB0 is an input without a pull up and needs to become an output with high level. There are two options to do that. 1. Set PB0 to high before making the pin an output. This will also turn on the pull up
PORTB |= (1 << PB0); // set to high (also turn on pull up)
DDRB |= (1 << PB0); // make it an output pin2. Make the pin an output first and afterwards set it to high
DDRB |= (1 << PB0); // make it an output pin, the level is still low
PORTB |= (1 << PB0); // set to highThe simulation doesn't care which way to go. The output of PB0 and PB1 is always like shown in the image. But the real circuit doesn't work anymore with the second option. I suppose the reason for it, is the short period between PB0 is set to an output and before it is turned high. The output is low during that time and discharges the capacitor. That discharge is large enough to redo a previous charge and the overall charge of the bigger capacitor will no longer increase.
Could it be, that the simulation doesn't take into account that short period of time when PB0 is low? Even if a put a delay of 30 micro secs between making PB0 an output and setting it to high (hence, there must be a longer period when PB0 is low), there is no discharge of the capacitor.
It's difficult to know what is exactly happening without the complete code.
The first issue is that you should adjust the reactive step (1 us by default) to this use case.
If you use a 30 us delay then the default might work, but I'm not sure.
If you share the circuit and code used in that picture I can try to understand what is happening.
I tried to make a test case, but I'm currently not able to reproduce the behaviour and prove my initial assumption.