An Elektor Platino-based system intended as a debugging tool for serial communication busses.
Even though the more expensive oscilloscopes can interpret certain digital signals when they are formatted in a known way, as SPI, I2C or plain serial for instance, a microcontroller can do this much better. In this article we therefore present a Platino-based system that speaks and understands several serial protocols, and that is intended as a debugging tool for serial communication busses.
A word about vocabulary
Let’s start by defining some context. A ‘bus’ is a group of signals. A ‘communication protocol’ is a set of rules that dictates how data is transmitted between computers. A ‘standard’ is a thing or idea against which something similar can be measured or compared. ‘Serial’ means one bit at a time. ‘Synchronous’ serial signals comprise separate data and clock signals; ‘asynchronous’ serial signals only have data signals.
In this article we will use the term ‘protocol’ for the way bits are supposed to be ordered on the line (e.g. one start bit, eight data bits, no parity, and one stop bit). ’Standard’ will refer to the physical expression of the data (e.g. the voltage levels and signal polarities on the line).
Specifications
With the above vocabulary in mind we can write down the following list of specifications for our test tool:
Multi-protocol
Multi-standard
Because this list is rather short whereas our project is an excellent target for feature creep, let’s add some more detail.
Multi-protocol (one at a time):
Plain vanilla serial
I2C / SMBus
SPI
Other? 1-Wire?
Multi-standard:
RS-232
RS-485 / DMX512
MIDI
5 V
3.3 V
With these standards we cover a pretty large range of possible protocols. The popular protocols are present from the start, while more exotic ones can be added later on.
From an operational perspective we specify flexibility.
Multi-standard hardware
As mentioned above, as the basis for our project we chose the Elektor Platino platform fitted with a backlit alphanumerical display with four 20-character lines, a rotary encoder, a pushbutton, a buzzer, and a tricolour LED. Equipped with an ATmega1284P microcontroller it has ample memory (128 KB program memory plus 16 KB of RAM) for serial protocols and nifty features. To that we added an extension board with the required interfaces for our serial standards.
The Platino multi-standard serial interface add-on board 130409-11 (see schematic in the download section) has interfaces for RS-232 (K8/IC4), RS-485 (K9/IC3), MIDI (input on K12/IC5, output on K13/IC6) multiplexed by IC2. K10/IC1 provide the interface for I2C, SPI and other 5-volt (T1) or 3.3-volt (T2) level signals where IC1 ensures the required level shifting. Other signal levels are possible through EVCC (1.2 V to 5 V) and by setting JP2. T3 is intended as 1-Wire output
If we load a suitable bootloader into the MCU the whole system becomes Arduino compatible and we can profit from the large number of Arduino libraries available online.
Multi-protocol software
Because our space is limited we will not waste it on such futile details as hardware descriptions.
Even though the ATmega1284P has hardware peripherals for the main serial protocols “UART”, I2C and SPI, its fixed pinout makes that we cannot profit from all of them together with Platino’s user interface elements. For this reason we decided to handle the relatively low-speed I2C protocol (400 kHz max.) in software (bit-banged master up to 400 kHz, bit-banged slave up to 10 kHz), giving the SPI bus the opportunity to fully express itself up to 8 MHz. This also implies that only one of the two hardware UARTs is available, as PD2 (RXD1) and PD3 (TXD1) are needed to control part of the LCD instead of the SPI lines PB6 (MISO) and PB7 (SCK). For TTL-level serial data a software UART is required using some of the pins of the SPI bus.
In case it wasn’t clear already, our tester will do only one serial protocol at a time.
Ergonomics come first
Because the tester’s usefulness depends for a large part on its ergonomics, we have spent quite some time on fine-tuning the user interface (UI). The objective was to make using the device as easy and comfortable as possible even though the display has limited space and cannot do colourful graphics. All the parameters are accessible by rotating and pushing the rotary encoder, and without going through many layers of menu. The result is, paradoxically, a rather cryptic main screen, but, as any user will quickly discover, easy to master.
A cryptic but easy to master main screen.
Spinning the encoder will move the little arrow to the next parameter; pushing the encoder will change the parameter’s value or enter edit mode for parameters with a wide range (serial baud rate for instance).
Main screen
Protocol - placing the cursor (the arrow) at the left of the protocol name by rotating the encoder and then pressing its pushbutton will bring up the protocol’s submenu where you can set the parameters specific to the protocol.
Data display format - press the encoder to toggle between ASCII ('A') or hexadecimal ('H').
TX data size - press the encoder’s pushbutton to enter edit mode. Rotating the encoder will increment or decrement the field’s value (0…7, yes it is possible to send nothing). Press the rotary encoder again when done. For most protocols this value will be set to the selected protocol mode (e.g. 3 for MIDI) but this can be overridden here, allowing to send more or less data.
Repeat count - press the encoder’s pushbutton to enter edit mode. Rotating the encoder will increment or decrement the field’s value (-1…99, -1 means forever). Press the rotary encoder again when done.
Repetition rate - press the encoder’s pushbutton to enter edit mode. Because this field can have up to four digits (‘0000’ to ‘9999’ milliseconds), rotating the encoder will increment or decrement the first digit. Pressing the rotary encoder again will move the cursor to the next digit.
TX data - press the encoder’s pushbutton to enter string editing. It can work in ASCII as well as in hexadecimal mode, depending on the data display format field.
Note that TX data can be up to seven bytes long. This upper limit is imposed by the available space on the second line. When the data display format is hexadecimal there is just enough space to print seven hexadecimal values.
The third and fourth lines are reserved for RX data.
Protocol menus
RS-232 & RS-485
RS-232 and RS-485 share the port settings, but the output is routed to different interfaces. (RS-485 also uses a bus enable signal.)
RS-232 menu.RS-485 menu. Baud rate: 1 Hz - 2 MHz Parity: none, odd, even Data (bits): 5-8 Stop (bits): 1 or 2
SPI
SPI menu. Role: Master (SPI) or Slave (spi) Data direction: MSB or LSB first Mode (CPOL & CPHA): 0-3 Speed: 125 kHz, 250 kHz, 500 kHz, 1 MHz, 2 MHz, 4 MHz, 8 MHz Signal level: 5V or 3V3
I2C & SMBUS
The SMBUS protocol uses most of the settings from the I2C menu, except for slave mode as our SMBUS implementation only supports master mode.
I2C mode does start-stop-start (S-P-S) between write and read, SMBUS does a repeated start (Sr) between write and read.
I2C menu. Role: Master (I2C) or Slave (i2c) Address (slave or mine when I am slave): 0-0x7f W(rite count): 0-7 bytes (also used for SMBUS block protocols) R(ead count): 0-99 bytes (also used for SMBUS block protocols)
(ignore) NACK: Y(es) or N(o) (ignoring NACK will make the master do the full transaction even when there is no slave responding or even present) Speed (master): 10, 25, 50, 100, 200, 400 kHz. In slave mode only clock speeds up to 10 kHz are supported. Signal level: 5V or 3V3
SMBUS menu. Protocol: quick command, send byte, receive byte, write byte/word/32/64/block, read byte/word/32/64/block, process call, block write-read C(ommand): 0-0xff TX[8] (8th databyte for write64 protocol): 0-0xff PEC: yes or no
MIDI
MIDI menu. Ch(annel): 1-16 Status: Note off, note on, aftertouch, control change, program change, channel pressure, pitch bend, system exclusive D1 (first data byte): 0-127 D2 (second data byte): 0-127
Hardware requirements
Platino (150555-1), fully assembled with 16 MHz crystal & ATmega1284P. Rotary encoder on S5 and pushbutton on S4 (A for left-handed, C for right-handed). RGB LED: don’t connect blue (the pin closest to the centre of the board) as this pin is also used for the LCD backlight.
Möchten Sie einen Kommentar mit Ihrer Bewertung hinterlassen? Bitte melden Sie sich unten an. Nicht gewünscht? Dann schließen Sie einfach dieses Fenster.
Diskussion (1 Kommentar)