AXE033/110 Emulator (Serial Display/Logger) using an 08M2

AllyCat

Senior Member
Hi,

This project is primarily a Hardware design to offer most of the features of the AXE033 Serial (RS232) LCD Display Driver and the more recent AXE131 to 134 OLED variants. However, I have used the 033 as a "Headline" because it includes an I2C bus and an optional Real-Time Clock. The design contains so many "options" that I don't expect to ever offer a "definitive" implementation program, but nearly all the features have been separately documented on this forum, sometimes in the Code Snippets section (often in considerable detail), so I will include Hot-Links where appropriate.

The I2C bus is the heart of the concept, with its on-chip "silicon hardware" virtually essential to achieve an acceptable display (update) speed. Also, many sensors are available with an I2C interface, (for example Temperature, Humidity, Barometric Pressure, Light level, LIDAR, ADC, DAC, etc.), usually mounted on breakout boards, so the project has also a Data Logging capability. The (RAM/EPROM) memory inside the 08M2 is quite limited, but an optional element of the design is a 24{L}Cxx I2C EEPROM, offering up to 128 MBytes. The circuit design and components have been selected such that the entire functionality can be achieved on a circuit board the size and profile (almost) of a single AA battery, using only through-hole techniques. Thus it can employ a switched and/or lidded AA battery box as an "Enclosure", but the physical construction will not be discussed in this first post of the thread.

The Display

The design is particularly intended to drive a low cost 0.91 inch (diagonal) 32 x 128 pixels OLED Graphics display (with a SSD13xx driver), but other sizes are available up to 2+ inches. The 1.3 inch (64 x 128 pixels) and 1.5 inch (128 x 128 pixels) versions might be also of interest because they often employ the SH11xx driver which offers a benefit of the graphics RAM being READable via the I2C bus (the SSD13xx chips are Write Only), more details HERE. A full 96 characters ASCII font set can be stored in about half of the Program Memory of the 08M2 as described HERE with relatively simple subroutines to convert to "Double-Height", "Double-Width" and "Quadruple-Height" characters.

The 32 x 128 pixels display format is particularly flexible because it can be configured as 4 rows of 20 characters (5 x 7 font in a 6 x 8 pixels cell), or two rows of 20 or 16 (more widely spaced) Double Height characters, or a single row of Quadruple Height characters, optionally using a "Character Rounding" (Diagonal Interpolation) algorithm, to give higher quality characters. This could give up to 10 characters across the width, which may be sufficient particularly for numerical presentations. Or post #6 in the previous link includes an average 3-pixels wide (6 pixels Rounded) "Proportional" ASCII font (varying in width from 1 to 5 core pixels), particularly appropriate for "soft" (individual pixels) side-scrolling.

Of course the 08M2 does not have sufficient pins to drive the normal "Parallel" LCD or OLED Character displays (like the 1602 or 2004), but these are often supplied with an "I2C Bus Expander" Backpack, or they can be obtained separately at modest cost. A further advantage of the backpacks is that they generally include the necessary "Contrast" Potentiometer, and control of the Backlight LED (including the possibility of backlight PWM dimming), for LCD modules.

Schematic Diagram

AA-I2C-OLED-EmulatorJune26.png

Above is a Schematic Circuit Diagram of the project (click to view). It might look rather complicated, particularly all the "Switches", but these are intended only to indicate some of the available "Options", in practice they might be 0.1 inch "pin headers" with bridging links as appropriate, but in most cases they will be embedded within the basic "PCB" layout. Similarly, a few connections are labelled as "Flyleads", a single flexible wire, with a Solder Tag that can be sandwiched between a spring and the body of one of the batteries in an AA battery holder, or perhaps terminated elsewhere on the PCB (e.g. for a LED).

Most of the PICaxe's pin functions are "fixed" by the application, i.e. Programming I/O (C.5 and C.0) and I2C hardware SCL and SDA (C.1 and C.2) leaving only C.3 ("Input Only") and C.4, but these definitions can be misleading, particularly with the 08M2. Pin C.3 (and even C.5) can be used for low power Output control via their internal "Weak Pullup" resistors (available on all 08M2 signal pins). Also, the "Output Only" Programming pin C.0 has a secondary function as a "DAC output", which has such a high source impedance (up to 160k) that it can be used as an Analogue (ADC) input via the READDAC{10} instruction.

RS232 Serial Input

Perhaps the greatest feature of the design is that ALL of PICaxe's "RS232" serial protocols are supported. Contrary to some "generic" descriptions, both SERTXD and SEROUT can be used on pin C.0, and also the HSEROUT hardware is allocated to that pin on the 08M2. Similarly, SERRXD and SERIN can be input on pin C.5, but the default HSERIN connection is pin C.1, already reserved for the I2C SCL signal. However, the base PIC (08)M2 chip has an "Alternative Pin Function" SFR which allows HSERIN to be swapped to pin C.5. This allows the Programming connector (3.5 mm coaxial or the "Legacy" 0.1 inch pin-header) to become a "Universal" serial interface port. There are a few issues, because the base M2 chips' hardware does not support the Idle Low ("RS232") signal polarity, only the Idle-High "TTL" or "True" format. Thus the design includes an optional inverter (Q1), which is activated by the Weak Pullup resistor on pin C.3. My original investigation was discussed HERE but the switching/interrupt arrangement has been improved for this thread.

The normal (Idle Low) Programming is coupled via R3, to be decoded by the internal firmware (pin C.3 is Tri-stated, so Q1 is off), but C.5 can be released (from the programming task) by a DISCONNECT instruction at the start of the User Program. The HSERIN module is then connected by a POKESFR to APFCON, after the external inverter has been activated by the pullups on C.3 (base bias) and C.5 (Collector/Drain load). PICaxe Basic does not permit directly enabling the Pullup on C.5, but this can be overcome by a direct POKESFR command, or by using a variable in the PULLUP instruction (having set the variable to %101000). Alternatively, (with R3 disconnected) D1 blocks any positive input voltage attempting to Program the chip, but allows a High to {H}SERIN after the Input Pullup has been activated.

Interrupts

The M2 family supports interrupts only on specific pins (of a single internal port), so the 08M2 actually has more interrupt-capable pins than the 14M2. However, unfortunately C.5 is not one of those pins, so another must be found (generally C.3) for the "RS232" to activate an interrupt. That is the reason for the resistor (R1) between pin C.3 and the base of the inverter transistor (Q1). The base of a bipolar transistor is effectively a forward diode to its emitter (ground) so clamps at about 0.6 volt; R1 allows the voltage on C.3 to rise high enough to generate an Interrupt. If the transistor is replaced by a MOSFET (e.g. 2N7000) then the pullup resistor can be omitted (zero ohms link). If neither an Interrupt nor signal inversion is required, then Q1 (bipolar or FET) can be used as a (Pull-down) External Power controller.

Another "Interrupt" possibility can use the base PIC's "Interrupt on Change" FLAGS, available on ALL of the 08M2's signal pins, including C.5. This cannot achieve a "genuine" interrupt (i.e. be transparent to the main program), but for a 2400 baud serial input stream with the PE Terminal Emulator's "5ms inter-character gap" (Serial Terminal > Settings) there is a period of more than 20ms between the start pulse of a first character and the completion of a third character (when the Internal Hardware Buffer would overflow). Thus a 20ms Polling Loop could be sufficient to catch any serial input, and to PWM-dim a LED, such as a LCD backlight.

Port.pin C.4

No specific function is required of pin C.4, so it is generally free for the User to employ as required. On the schematic diagram it is connected to a 4-pin header footprint, together with Supply, Ground and the Programming Input. Applications could be to drive a Model-making Servo, or to connect to a DS18B20 Temperature sensor (which requires a pin with combined Input and Output capability). The Programming Interface alone cannot directly accommodate a DS18B20, but Earth is available and C.0 can be set High to emulate a Power Supply rail. Then C.4 can be bridged to the Programming Input to allow a wired external sensor to be linked via the Programming Socket. Like for the I2C, the Weak Pullup resistors (on C.4 and C.5) may be sufficient for the DS18B20, but it's probably necessary to increase the pulldown resistance R4 (which allows the PICaxe to bootup without a Programming Cable) and/or to make use of the "Normally Closed" switches (when no plug is inserted) on the 3.5 mm socket.

Well, the forum's 10,000 characters-per-post limit is here again. Not yet discussed is the LED array at the top of the diagram, which represents only 4 "holes" at the corners of a 0.1 inch square on the PCB (for a vertical resistor and possibly a bi-colour LED). Also, the current-sensing capability of the resistor (R5) between the separated "Earth" rails, which can be read by a READDAC{10} instruction (on pin C.0).

Cheers, Alan.
 
That's quite a project. You've certainly managed to wring a lot out of the little 08M2! While I'm unlikely to replicate the circuit, I admire your dedication.

As an aside, I once built a NiMH battery charger around the older PICAXE 08M. It was a squeeze to fit the code into the available 256 program bytes and just 6 usable pins, but it was a successful project. Pin 4 had to double as an ADC input for sampling the charging current using a shunt resistor and as an output for audible alerts and flashing an LED.
 
Hi,

Thanks for your comments, I must admit that I hadn't considered an "audible alert" feature (there definitely isn't any space on the PCB) although I previously have used the little black, tub-shaped sounders on some of my AA-sized project boards. It is perhaps fortunate that I didn't join the PICaxe Club until after the M2 chips were available; I do like a challenge, but haven't been tempted by the "Sale" offer of the 08M2 LE chips (256 bytes of Program, 32 of RAM and NO BPTR), even for less than a Pound. :)

Not fully investigated yet, but I consider that monitoring current flow with the Programming "Output only" pin is quite "creative". However, as shown, the current-sense input voltage will remain always below the Digital Output (Low) threshold level, to keep the Serial Data reporting reliable. It looks as if my next formal post in this thread could also hit the 10,000 characters barrier, so I may as well include some details that I had already drafted, here now :

Current Sensing

The design nominally has two Earth Rails which are restrained from differing by more than about half a volt, by two (semi-optional) forward-conducting diodes, in case the current-sensing resistor (R5) is too high for the current. Configured as shown, current flowing into either of the buffer FET/transistor drivers (or the programming interface Earth) generates a positive voltage which can be detected by the PICaxe's ADC on pin C.0 . Alternatively, the PICaxe's Earth pin could be referenced to the other Earth Rail, to exclude the buffers' currents and/or respond to the opposite direction of current flow. However, since C.0 is the "DAC" Output pin, it is possible to bleed a controllable current out of the pin through R6, to offset the voltage across R5, thus accommodating either direction of current flow.

The value of R5 determines the current sensitivity of the measurement, obviously limited to about half a volt but the (optional) Schottky (-type) diode tends to have a "softer" conduction curve (V/I) which may approximate to a logarithmic transfer characteristic. Using the FVR2048 (2 volt) internal reference with a READDAC10 instruction gives a half volt full-scale BYTE value, or the FVR1024 can give an acceptable 0.25 volt full-scale. However, the current-monitoring is not really intended to achieve a "precision" value, more a verification of an "expected" (or unexpected) current flow.

The LED(s)

The Application will normally include a back-lit LCD or an OLED display, so a separate LED is hardly necessary. Therefore the LED components shown also cover some more general aspects of the User-Interface. In particular their function might be as a Light Sensor, to allow the display brightness to be increased automatically under high light level conditions such as direct sunlight. Thus, the LEDs might actually be replaced by other 2-pin components such as a Phototransistor or Light Dependent Resistor, but the light-sensing capability of a normal LED is also being considered. The most suitable are reported to be Green or Yellow, in a "water clear" package, but their sensitivity is still expected to be only for direct-sun detection, at best. LDRs are by far the most sensitive, partly due to their larger size/collection area, then Phototransistors because their (floating) base amplifies the collector-base (photoelectric) leakage current. A LED's reverse (Diode) leakage will be much lower and their Photo-Voltaic (generation) even less, and of course limited to the forward voltage drop of the diode (junction).

Thus the switch array shown in the schematic diagram is mainly to indicate the potential connection points of LEDs, or similar components, into the overall circuit. In practice, any PICaxe pin might be suitable, but here pins C.0, C.2 and C.4 have been particularly identified. C.0 is especially appropriate if the Serial Output is Not being connected back to a Terminal Emulator (such as PE6) and C.4 is potentially available because it is not committed to any core function. C.2 is of course the I2C Data line, which is "safe" to pulse, provided that the Clock line is not activated (or vice-versa), but the LED must be operated as "Active Low" (i.e. with its other terminal connected to the supply rail, via a resistor). C.2 is also the only (08M2) pin directly supported by the OS for PWM Output, but I believe that POKESFR commands can activate most other pins (except C.1 and C.3) to give a PWM output using the base PIC's "Bridge" or APFCON configurations.

I2C Bus, EEPROM and RTC

The I2C Bus is not shown with any (normal) Pullup Resistors, because they will very probably already be fitted to any Breakout Boards or modules that are included (such as the OLED or RTC). Only the bare EEPROM chip will not, but for this the PICaxe's internal Weak Pullup resistors can be activated, perhaps even automatically as shown in this (large) "Code Snippet". More will be said about the EEPROM (and RTC) in the "construction" sections but perhaps it's worth noting here that the four pins on one side of the package are all connected to Earth so can be linked by a solid BTC (Bare Tinned Copper wire) "flylead" to create a 5-pin SIL (Single In Line) module, that may be mounted vertically, or perhaps "folded" under the RTC module. Alternatively, the "Write Protect" pin may be permanently connected to Ground, with a link across the body of the package, to Earth all the pins on the opposite side. C.0 is not particularly useful for Write Protection because its default/idle level is Low ("Unprotected").

The RTC is specifically a "3231 RTC for Pi" module, available for some years on a thin 14 mm square PCB with a "DS3231" on the top side and a 10mm diameter (yellow, 3mm thick) rechargeable lithium cell on the underside. Its standard 5-pin (0.1 inch pitch) header socket lifts the body sufficiently high above the PCB that small components can be mounted underneath. If purchasing, ensure that the battery is actually included (soldered in) because it may be very difficult (and expensive) to obtain separately, later. Some of these RTCs are available at such low cost (particularly from AliExpress) that they almost MUST be "Fake", but presumably/hopefully "good enough" for a simple low-cost project. If thermal stability is a particular issue then perhaps my "Chiptemp" Routine might be useful. ;)

Cheers, Alan.
 
Last edited:
Back
Top