The ATmega128 chip has
the instruction processing rate of 1MIPS/1MHz; thus, on the maximum system clock of 16 MHz,
it can approximately run 16 million instructions per second (MIPS). However, when I monitored
the code efficiency via the software simulator of
, Atmel’s official IDE, I found that the parallel communication with LCD takes extremely long
delays, sometime reached the ten-millisecond level even the hundred-millisecond level, while
most other hardware modules work in microsecond to ten-microsecond levels; therefore, the LCD
occupies most CPU resources.
The long delays taken by LCD data transmission are
caused by the fixed slow LCD clock, which is not able to be accelerated;
thus, the delays are technically not able to be avoided; however, I have
found an alternative method to decline the delays: to add a low-end MCU
controlling the LCD module and communicating with the main processor via
USART; thus, the main processor treats that MCU as a buffer and sends data
for display to it while the low-end MCU takes the responsibility to put those
data on the LCD screen. As a result, the main processer can save considerable
time for data transmission. Yet this sketch raises a new problem that three
MCUs will exist on one small PCB: one is the main processor; one works only
as a USB programmer; one is only for LCD display; therefore, the MCU resources
are wasted, and the expenditure also rises. To solve the predicament, I plan
to combine the USB programmer and the LCD controller into one MCU; nonetheless,
I have to understand the assembly code written by the USBASP provider first.
I will try to apply this scheme in the next version.