DU Microprocessor Requirements
Flash: 32KB (20KB Flash max for fonts (3 fonts x 3 styles each – 4x4, 15x15, 40x40 average size), 12KB Flash max for code)
SRAM: 1.6KB SRAM for 320x40 framebuffer or 1KB for 320x25 (based on max font size)
Frequency: 2.2MHz minimum (assuming to update 3 times/sec, 320x240 pixels, 2 controller instr/pixel)
Voltage: 5V or 3.3V, lower the better due to power consumption
Peripherals: SPI (2 SPIs would be ideal since must communicate with EIU micro and LCD), ATD not needed, is an oscillator needed?
Footprint: Low pin count for ease of wiring
Price: As cheap as possible.
Current: Icc should be very low when in idle state, low when active (this is hard to compare b/w chips though)
Microcontroller Recommendations. (In order of preference)
NOTE: The ATtimy84, PIC16F916, and ATMEGA162 are too small (first two have 4-8Kb Flash, 512B EEPROM (512B SRAM), last has 16KB Flash, 0.5KB EEPROM, 1KB SRAM).
Flash / EEPROM / SRAM / Max IOPins / MHz @ 3V / Vcc / Icc act @ 3V / Icc idle @ 3V / Peripherals
PIC18LF45J10**
28 pins, 8-bit
VERY CHEAP / 32KB / 0KB / 1KB / 32 / 40* / 2.7-3.6 V
all 40MHz / NA / NA / 2 MSSPs, PWM, ADC, AC, USART
MC9S08GT32A***
44/48 pins, 8 bit / 32KB / 0KB / 2KB / 39 / 20 / 1.8 – 3.6 V / NA / NA / 2 SCI, 1 SPI, PWM, ADC, AC, Osc.
PIC18LF2510
28 pins, 8-bit / 32KB / 0KB / 1.5KB / 25 / 4-40* / 2.0 – 5.5 V
(4-40Mhz) / 1.3/3 mA
(typ/max,
4 MHz*) / 900 uA
(max @
4 MHz*) / MSSP, PWM, ADC, AC, USART, Oscillator
ATMEGA32L
40 pins, 8-bit / 32KB / 1KB / 2KB / 32 / 8 / 2.7 – 5.5 V (8 MHz) / 5 mA
(max,
4 MHz) / 0.35 mA
(typ. @
1 MHz) / Timers, PWM, ADC, SPI, AC, USART, Oscillator
MC9S08RG32
39 pins, 8-bit / 32KB / 0KB / 1KB / 39 / 8 / 1.8 – 3.6 V / NA / NA / SCI, SPI, PWM, ADC, AC, Osc.
ATMEGA64
64 pins, 8-bit / 64KB / 2KB / 4KB / 54 / 8 / 2.7 – 5.5 V (8 MHz) / 5 mA
(max,
4 MHz) / 2 mA
(max @
4 MHz) / Timers, PWM, ADC, SPI, AC, USART, Oscillator
ODS: On-chip Debug System, AC: Analog Comparator, USI: Universal Serial Interface, SPI: Serial Peripheral Interface,
MSSP: Master Synchronous Serial Port module (includes SPI, I2C), SCI: Serial Communications Interface module
*Divide PIC freq by 4 since 40 MHz <-> 10 MIPS
** No on-chip oscillator – is this a problem?
*** Check SCI vs SPI?
Other Issues
I. Framebuffer in Flash?
“[Flash] must be erased a ‘block’ at a time. Starting with a freshly erased block, any byte within that block can be programmed. However, once a byte has been programmed, it cannot be changed again until the entire block is erased. In other words, flash memory (specifically NOR flash) offers random-access read and programming operations, but cannot offer random-access rewrite or erase operations. … A further limitation is the fact that flash memory has a finite number of erase-write cycles.” Wikipedia, http://en.wikipedia.org/wiki/Flash_memory
“Flash erase cycles are long - really long - it can take several seconds to erase a Flash sector. Also as the number of guaranteed erase / re-write cycles is usually limited (typically around 10,000 or up to 100,000), we cannot afford to erase an entire sector just because one variable changed.” Using Flash Memory in Embedded Applications, http://www.esacademy.com/faq/docs/flash/variables.htm
This presents a problem, since the low-power microcontrollers we were interested in for the DU generally don't have much on-chip SRAM (the ATMEGA64, which is one of the largest chips we are considering, only has 4KB). So, there are a few alternatives:
(1) Render 1/3 of the screen at a time in 4KB SRAM in somewhat of a circular buffer implementation so that we always render ahead of what is being sent to the LCD. The potential problem with this is that we may not be able to keep up with the send to the LCD, making screen refreshes appear half-rendered.
(2) Store the framebuffer in the plentiful external RAM of the EIU, but this breaks down our EIU-DU distinction.
(3) Get a microcontroller with enough SRAM but which is way too powerful, or get an external SRAM; these are probably equally bad ideas.
(4) If the LCD controller supports it (which is quite possible), render a line at a time into the on-chip DU SRAM then send this to the LCD controller. Many controllers have two framebuffers, one only visible at a time, to alleviate jaggedness during screen updates.
II. Font Memory Calculations
There are 95 viewable characters in ASCII (0x20-0x7F, limiting to primarily English but allows two characters/byte). Maximum size of a normal font is 8x8; for a monochrome display this takes up 64 bits or two bytes. Hence, one fixed font face will take up 190 bytes (512 bytes max if a graphic is specified per character). A full-screen graphic (e.g. bootup screen) will take 320x240/32 = 2400 bytes. Line/vector graphics will be drawn procedurally, requiring only memory for code. An average large font character may take 40x40 while a medium character around 15x15 (see the second image). If we support bold and italics, this is in essence three additional fonts. So, total, to support 95 characters, three font sizes, and three font types/size, a bitmap fonts will require (3 styles)(95 chars)((64 bits/char) + 225 + 1600)/32/1024 = 16.43 KB. This is probably more of an upper limit. Also, the maximum memory required for fonts is dependent on the amount of on-chip SRAM (if a line is rendered at a time).