# Simulating a 7-segment 4 digit display in Proteus using Atmega16

I have an issue about simulating a 7 segment display in Proteus.

So basically, I am using an ATmega16 microcontroller along with a ULN2803 transistor array. I connect the 7 segments + decimal point to PORT A of the microcontroller using 10K resistors in between.

The digits go over the ULN2803 and into the upper part of PORT B of the controller. At first the ULN wasn't working properly and not turning on the digits but I solved that with adding a pull up resistor network between the display and the ULN.

The real problem is the fact that it seems that Proteus can't handle the fast frequency of displaying the digits. Because of how the display works, you can't turn on all the digits at once but you turn on one by one really fast so you perceive the digits as being turned on all at the same time.

I think that is what's making my simulations look completely wrong.

This is a simple code for a stopwatch programmed using the inbuilt timer of the ATmega.

#define F_CPU 7372800UL

#include <avr/io.h>
#include <avr/interrupt.h>
#include <util/delay.h>

static uint16_t time = 0;
static uint8_t data[4];
static uint8_t dotOn = 0;

void time2data(uint16_t time, uint8_t data[]) {
uint8_t i;
for (i = 0; i < 4; i++) {
data[3 - i] = time % 10;
time /= 10;
}
}

ISR(TIMER1_COMPA_vect) {
time = (time >= 10000) ? 0 : time + 1;
dotOn = !(time % 50) ? ~dotOn : dotOn;

time2data(time, data);
}

int main() {
DDRA = 0xff;
DDRB = 0xf0;

uint8_t values[] = {0x3f, 0x06, 0x5b, 0x4f, 0x66, 0x6d, 0x7d, 0x07, 0x7f, 0x6f};
uint8_t i;

TCCR1A = 0;
TCCR1B = _BV(WGM12) | _BV(CS11);
OCR1A = 9216;

TIMSK = _BV(OCIE1A);
sei();

while (1) {
for (i = 0; i < 4; i++) {
PORTA = values[data[i]];

if (i == 1 && dotOn) {
PORTA |= _BV(7);
}

PORTB = _BV(4 + i);
_delay_ms(1);
}
}
}


This is the Proteus scheme I am using.

So is there any way to circumvent this issue or is it just an simulation anomaly that can't be avoided? Is there anything I can do?

• What does Proteus support say about it? – Leon Heller Jan 19 at 17:08
• Haven't really contacted them, hoped it could be solved with some clever adjustments to the schematic maybe or a switch in the programming logic. – Machi Jan 19 at 17:25
• Try to adjust the "Minimum Trigger Time" property of the display component. – user930473 Jan 19 at 18:21
• Hmm, not sure what it does but it is already set to 1ms. Changing it does nothing really, the only thing that makes any difference is changing the _delay_ms at the end of the for loop. – Machi Jan 19 at 18:40