Project Papydoo - Part 2

This is a follow up to Project Papydoo - Part 1

In Part 1 I've covered the hardware. Part 2 is about the firmware. There is also an introduction to the ZDS Studio II development environment, because its not as well known as the usual suspects (Atmel AVR, Microchip PIC, etc).


7. The Zilog ICD USB cable



Programming and debugging all recent Zilog MCUs is done with the same probe, or "smart cable". A serial RS-232, USB and Ethernet version is available. The USB version is bundled with most Zilog dev. boards, but can also be purchased separately from DigiKey or others for around $35. This probe does more than just in-circuit programming. It does full source-level in-circuit debugging (stop, trace, breakpoints, watches, registers content, etc.), all from 1 pin on the MCU.

The "native" connector on the ICD probe is a 2x3 pins ribbon cable header. Zilog has organized the pins layout so that its "reversal" proof, I guess.


Personally I don't like this connector. I've devised my own 3 pins .1" SIP connector with only the 3 signals: VCC, DBG and ground.



8. The Zilog Development Studio II IDE


Zilog freely provides a complete development environment suite called "Zilog Development Studio II" for the eZ8 (as well as other) family of Zilog microcontrollers. This is the complete, full-featured version. No demo, trial, or features limit. Its free and complete. Although some developers might find it lacking advanced features found in high-priced tool chains, everything is there for basic ANSI C or assembly development, programming and source-level debugging. For this project, I've used the recently released version 5.0.0. It features a more advanced source editor (with auto-completion, code block folding) and some other minor changes from the previous versions.

For people familiar with Microchip PIC, ZDS is like a less bloated version of Microchip MPLAB with an ANSI C compiler natively included. As far as I know, its mostly an MS Windows app., but heard some people running it inside Wine with Linux, and using the RS-232 ICD probe. See the Zilog forum for more details.


Doing projects in ZDS is very straightforward. You create a "New Project" from the file menu, answer a few questions about the MCU family used, memory size, C memory model, and then add source files to the project.

The full source code, released under a Creative Common license, is available for download at the end of this post.

The code is lightly documented and should make sense to most people familiar with C development on microcontrollers.

Their are a few minor things that I will explain in the following sections, for people unfamiliar with Zilog eZ8 MCUs.


9. eZ8 stop mode and C startup module

When the eZ8 enters stop mode (low power sleep), it stops executing code, turns off the oscillator and wait for an event to trigger a "wake-up", or recovery.

Recovery can come from a state change on an input pin, an external reset or the watchdog timer timing-out. The later is used to "wake-up" the eZ8 after about 1 second of sleep.

Unlike the Microchip PIC16F for instance, code execution doesn't resume where it left off, but at the reset vector. This causes problems with the default C startup module if you want to preserve states or variables content while in sleep. By default, the C startup code clears the RAM content (with zeros), and copy values from ROM for initialized variables. A custom version of the C startup module (startups.asm) was modified and included in the project's folder. This version doesn't clear the RAM on startup:


In the "main" function, a different code path is taken if the device is recovering from sleep, as oppose to a normal power-on reset.



10. "rom"? "near"? "far"?

The rest of the code is pretty straightforward stuff. It could easily be ported to PIC or AVR MCUs, apart from a few nuances in the C code: The "rom", "near" and "far" storage class modifier. The eZ8 is an Harvard architecture microprocessor: Code and data are stored in different address spaces. This poses problem with large arrays of constants (like character font table, menu text strings, ...). Zilog's ANSI C compiler allow the use of the "rom" storage class modifier for explicitly placing arrays in ROM, and generating the proper assembly code to access it:

char rom table[] = { [ ... large data set ...] } ;

The "near" storage class modifier is used in the code for compatibility purposes only, because some other members of the eZ8 family have more the 256 bytes of RAM and uses "far" pointers and the large memory model. In the small memory model, everything is "near".

Near pointers? Far pointers? This brings back memories from the days of x86 programming on MS-DOS :)


11. Bit Order Reversing

Being kind of lazy, I've used a character font table designed for a Nokia 5100 LCD mono display. The HT1632's frame buffer is almost identically structured, except the rows order are reversed: Row 0 is at the bottom of the display, versus the top for the Nokia LCD. This makes the font upside down when drawn in the frame buffer. Correcting the orientation implies reversing the bits order inside a byte: Bits 0 - 7 to bits 7 - 0. There are no efficient (and elegant) ways to do that in C, so I've used in-line assembly to call the BSWAP instruction who happens to do just that, in 1 instruction cycle.


12. Analog to digital converter (ADC)

The ADC of the Z8F083A is quite fast, at 2.8us per conversion. There is not much code that could get executed while waiting for the result. So when I initiate a conversion, I just wait for it to finish and get the result. The ADC is 10 bits and uses an internal 2.0 volt reference.


13. General Purpose Input / Output (GPIO)

The LED matrix operates at 5V, and the MCU operates at 3.3V.

Level translation to 5V is done by configuring output pins in "open-drain" mode, with external pull-up resistors to 5V.

The pushbutton input pin has an internal pull-up resistor enabled.


14. Source Code

The source code can be downloaded here