[Wiki] Using the PEX - USART interface


#1

Introduction
The PEX header exposes three of the four pins of USART0. Those can be used to communicate with other serial devices, most notably including another Pokitto for building 2-player games. Very little setup is required for this, either in hardware or software.

Components
The simplest test is a loopback test with a single Pokitto, and all that takes is a single breadboard jumper cable. Beyond that, you’ll need another device with a serial interface. The simplest setup is with a second Pokitto (note: I only have one Pokitto, so haven’t tested this, but document it here anyway).

A more complex alternative is to use a USB/serial adapter to connect to a USB port on a PC or mobile device. These are readily available from Amazon, or more cheaply (though probably more slowly) from ebay. This should be for a TTL-level output, not an RS-232 level output.

Finally, you’ll need three breadboard jumper cables. One end should be male to plug into the Pokitto, and the other end of the appropriate gender to plug into the other device, so male to male to connect two Pokitto. The TTL/RS-232 converter will need a fourth jumper cable.

Hardware connections

First, some warnings:

  1. These setups are for testing. A connection you are using regularly should use a hat of some kind, and Pokitto-to-Pokitto connections need some buffering compnents.
  2. Make sure any other devices are 3.3V, not 5V. Using a 5V device could damage your Pokitto.
  3. Power down everything while you are connecting things.
  4. Power up the other device first. The Pokitto can handle this, and the other device may not.

For a loopback test, connect EXT6 to EXT7 on your Pokitto.

If you’re connecting two Pokitto (lucky you!), then connect EXT6 on one to EXT7 on the other, and vice versa. Use the last cable to connect Ground to Ground.

To connect to a USB/Serial converter, connect EXT7 to the Rx pin, EXT6 to the Tx pin and Ground to Ground.

This image shows a Pokitto connected to a USB. The black cable is Ground, green is Pokitto Tx to converter Rx, and the orange is Pokitto Rx to converter Tx.
Software

The demo program is a simple “terminal” emulator. It prints incoming characters to the Pokitto display, and reports button presses/releases to the other end. If you are using mbed online, you can copy it from my program page. Otherwise, you can start with the source here:

/*
 * Serial PEX header demo.
 */
 
 #include "mbed.h"
 #include "Pokitto.h"

Pokitto::Core demo;

Serial ser(EXT7, EXT6);

struct {
    uint8_t button;
    char *name;
    } buttons[] = {
        {BTN_A, "Button A"},
        {BTN_B, "Button B"},
        {BTN_C, "Button C"},
        {BTN_UP, "Up button"},
        {BTN_DOWN, "Down button"},
        {BTN_LEFT, "Left button"},
        {BTN_RIGHT, "Right button"}
    };


int main () {
    demo.begin();
    demo.display.persistence = 1;
    demo.display.clear();
    ser.baud(115200);
    while (demo.isRunning()) {
        if (demo.update()) {
                while (ser.readable()) {
                    demo.display.write(ser.getc());
                    }
                for (uint8_t i = 0; i < NUM_BTN; i += 1) {
                    if (demo.buttons.pressed(buttons[i].button)) {
                        ser.printf("%s pressed\r\n", buttons[i].name);
                    } else if (demo.buttons.released(buttons[i].button)) {
                        ser.printf("%s released\r\n", buttons[i].name);
                    }      
                }          
            } 
        }    
    
}

The serial interface is ser. The interface used is baud to set the baud rate, readable to see if there are any characters available, getc to read those characters, and finally printf to report button up and down events.

Build the project, or downloadmy build (35.9 KB) and install it on your Pokitto.

Loopback test with one Pokitto

This looks a lot like a simple button test. You press buttons on the Pokitto, and strings announcing the press and release events are displayed on the screen. The Pokitto display code and button handling code don’t quite agree with each other, so you don’t get proper newlines.

Testing with second Pokitto

Just start the two connected Pokitto once the demo is installed on both. If everything is connected properly, buttons pressed on one Pokitto will be reported on the other. Yes, it’s just that easy!

Testing

We’re going to use the Arduino serial monitor for testing. Not only is it cross-platform, working the same on Windows, the Mac and Linux, but it may be familiar to many of you already.

If you don’t already have it, you can download the Arduino application from arduino.cc. Download the IDE, don’t use the web app.

Now start Arduino application. Under the “Tools” menu, check the “Port” menu for a list of serial ports. On Linux, you’re looking for something of the form /dev/ttyUSB#, where the # is normally 0, but may be higher than that if you’ve been playing with USB converters. On a Mac, it’s of the frorm /dev/tty.subserial-########, where the last bit depends on the chip you are using. On Windows, it will be COM#. If you’re using a TTL serial converter, it’ll be something different on the Mac and Linux. If there’s more than one name that matches the pattern you’re looking for, you’ll have to figure out which one is the Pokitto. Unplugging it and seeing which one vanishes works very well.

Here you can see the Arduino IDE with the two menus you need to deal with highlighted in red.

Once you’ve identified the proper port, select it. Then select “Serial Monitor” under the “Tools” menu to open the serial monitor. At the bottom right are a pair of drop-down menus. Set the “Line ending” one to “Both NL & CR”, and set the other to “115200 baud”. Check “Autoscroll” on the bottom left.

And here is the serial monitor window showing the correct settings, again highlighted in red.

Try pressing buttons on the Pokitto. You should see reports about button’s being pressed and released show up in the monitor. Now type some text into the line above that, and hit “Send”. It should show up on the Pokitto. If neither work, try swapping the cables going to EXT6 and EXT7 - you may have gotten them backwards.

Testing with Android

If you have an Android device with OTG usb support and a USB convertern, you can use it to test as well. Install the serial usb terminal from the play store. Connect the Pokitto and the USB converter, connect the converter to your Phone, then start the Pokitto and the app. Select “USB Device” from the menu, and choose your device - there should only be one. Under the “Setting” menu, set the baud rate to 115200, then make sure it’s set to 8 bits, 1 stop bit, no parity and Send is “CR+LF”.

Now select “Terminal” from the menu, and if the plug icon on the right - left of the trash can - isn’t connected, tap it to connect. Once it’s connected, try pushing buttons on the Pokitto. You should get reports in the terminal window. If that works, try typing some text into the input line at the bottom, and hitting the airplane to send it to the Pokitto. That text should show up on the Pokitto display. If neither works, try swapping the cables going to EXT6 and EXT7 - you may have them backwards.

Some Alternatives for testing

If your PC has an RS-232 output, you can also get a TTL to RS-232 converter to use instead. The setup on your PC will be nearly identical to the USB converter but with a different device name. You will need to provide power to the converter
from the Pokitto.

There are also Bluetooth/Serial (SPP) adapters. Setting those up is much more difficult, as you need to get a pair of wireless devices talking to each other. But it does provide a wireless connection, so cool. Like the RS-232 converters, you’ll need to provide the adapter with power from the Pokitto.

If you’re interested on more information about either of these, please ask in the forums.


Safely establishing a connection between Pokitto and an Arduino Uno
Interpreted language (esp32 specific)
#2

Wow. Thank you for that writeup!


#3

I’d be careful about direct wire connections between two devices, without some kind additional buffer or protection circuitry.

If one device is powered up and the other isn’t, and the powered device has a high on an output signal, there’s a chance you could damage the pins on one or both of the devices. You’d be forcing current into the unpowered input. High current could flow through the protection diode on the input, possibly burning it out. That same high current could overload the output, causing it to fail.

If you’re going to do this, I suggest you always follow this procedure:

  • Avoid touching the metal pins of the cables while connecting them, to prevent damaging the devices due to static discharge.
  • Before connecting the cable, make sure both devices are powered up.
  • Connect the ground wire first, then the signal wires.
  • Disconnect the cable before powering off either device:
    First disconnect the signal wires, then lastly the ground wire.

It would be better to make a TTL to RS232 “hat” for each Pokitto using a module like this, or equivalent circuitry. This would “buffer” and protect the signals and, as a bonus, allow a much longer cable to be used.


#4

Well, I’ve got some edits to make, so adding your advice is certainly possible. At the very least, pointing out that this type of breadboard hookup is for testing, so you want something a bit more permanent if you’re going to be using it on a regular basis!

I’m a software guy, so I’d like to clarify a few things:

First, the breakout boards are designed for connecting to µ-processor dev boards like the Expresso the pokitto design is based on. I can tell by examination they have components between the header points and the IC pins, which I expect are the buffer/protection circuitry you talk about. I’d also assumed that those µ-controller boards have a similar design. Is that assumption wrong? Does they expect only to be connected to the device breakout boards that have such protection? If not, is the Pokitto PEX header different from other µ-controller boards in this respect?

Your power order advice seems counter-intuitive. To me, the most likely source of damage seems to be accidentally shorting things while moving connections around. So you’re better off making sure everything is powered off before connecting or disconnecting things. Part of that is knowing that the signal and supply levels are the same, so you really can’t force more voltage onto a pin than it is designed to handle. This is common advice in the RC community, where it’s understood that this means that damage isn’t impossible, but unlikely. Is this wrong, or again the difference between connecting a µ-controller board to a device breakout as opposed to another µ-controller board?

Finally, I’m not really a fan of the idea of using RS-232 for a more permanent solution, for two reasons. First, it uses significantly higher voltage levels, so accidental damage seems more likely. Second, the cable design is older, which is why they need more voltage. For a permanent connection, I was thinking more along the lines of a hat built on something like these: https://www.amazon.com/MagiDeal-10pcs-Female-Pinboard-2-54mm/dp/B0183KF7TM/ref=sr_1_3?ie=UTF8&qid=1509911378&sr=8-3&keywords=usb+breakout. You get a more recent cable design, so no need for higher voltages. I haven’t looked at it beyond the vague thought that it’s interesting, so I’m not sure how well it would actually work. But this is also well beyond the scope I intended for the wiki article.


#5

By breakout boards, are you referring to the TTL to RS232 modules that I suggested and linked to? If so, they have no additional protection circuitry other than what’s built into the MAX3232 converter chip itself. The converter chip provides buffering and protection on the RS232 side, to prevent damage to the µ-processor pins running at TTL levels, since these pins are no longer connected directly to the “outside world”.

Likewise, most µ-processor dev boards don’t provide additional protection circuitry. They just bring the µ-processor pins directly out to the header. Additional protection circuitry might interfere with whatever the developer intends to use the pins for.

It’s highly likely that the Pokitto also just connects the I/O pins directly to the PEX. Adding protection to each pin would take up board space and add additional cost (and could also interfere with intended uses, as above).

This is true if all your circuitry is powered up or down at the same time. The problem occurs when one device is powered down when the other device that it’s connected to is powered up, which could be the case with two Pokittos directly connected with just wire jumpers over the PEX interface.

That’s the problem. A device that’s powered down is, from an electronics point of view, actually powered up with a supply voltage (Vdd) of 0 volts. Therefore, any voltage that you apply to an I/O pin will be higher than the 0V supply voltage at this time.

However, upon examining the datasheet for the NXP LPC11U68 processor that the Pokitto uses, it appears that the I/O pins can handle 3.6V even when powered down, so directly interconnecting two Pokitto’s should be safe. This isn’t true for most other processors and interface chips, so in general it’s not a good practice to follow.

The bottom line is that, unless the inputs of the device in question are capable of handling voltages that you’re going to apply when the device is powered down, you need something to prevent that from happening. Although not necessary in the case of the Pokitto, using TTL to RS232 converters instead of direct wiring is one way to provide this kind of protection.

Incorrect. The converter chip on both sides provides protection against the high cable voltages from reaching the digital (Incorrectly termed TTL) level signals on the device side, even when the chip is powered down. This is mandated by the RS232 specification.

Also incorrect. The higher voltages are to allow longer cable lengths and more noise immunity. What do you mean by older cable design? Older than what?

Using USB connectors has nothing to do with the voltages that you can use on a cable. You don’t get better low voltage operation just by using a USB connector instead of something else. Since we only need 3 wires (TX, RX, GND) I’d suggest using a standard 3.5mm stereo headphone (TRS) jack, This would make the cable easy to obtain since 3.5mm stereo plug to plug cables are common.


#6

No, I was referring to things like the USB breakouts I referenced below. Things designed to make it easy to connect the chips in question to µ-controller boards like the arduino. I don’t believe the RS-232/TTL converter chips (as opposed to something like the USB/TTL Serial converters) are in that category.

The key word here is “accidentally” This is all great if you never have n accident or make a mistake (in which case, you’re a better man than I am). But if you do, sending an RS-232 signal into a 3.3v pin seems like a really good way to let out the magic smoke.

[quote=“MLXXXp, post:5, topic:625”]
Also incorrect. The higher voltages are to allow longer cable lengths
and more noise immunity.[/quote]

These are two sides of the same coin. Using a newer cable design allows you to get longer runs and better noise immunity for a given voltage level. But yeah, RS-232 is meant for much longer runs than USB.

Older than USB cables.

[quote=“MLXXXp, post:5, topic:625”]
Using USB connectors has nothing to do with the voltages that you can use on a cable.[/quote]

Quite right. I wanted to use a better cable design, and get easy-to-find connectors. If we could use a standard USB cable - as opposed to having to wire the connectors specifically for this case - that would be gravy.

[quote=“MLXXXp, post:5, topic:625”]
Since we only need 3 wires (TX, RX, GND) I’d suggest using a standard 3.5mm stereo headphone (TRS) jack,[/quote]

I like that idea. Simpler to connect than a USB connector, and we can design it to use a standard cable. Also a standard practice in the RC world, though they typically use mono cables carrying CPPM signals (and finding mono cables has gotten to be a pita).


#7

Getting back to the Wiki entry:

So the suggested changes are to note that these setups are for testing, and you want a hat and cable combo once you’ve got things working properly.

What do you recommend for making the connections: everything power down, or everything powered up? I’d prefer that it work for both the USB/Serial converter & two pokittos if possible, just to simplify the wiki. I think the RS-232/TTL converter may require special handling, so I’m thinking about dropping it to keep the wiki simple. Maybe add a section on “other connections” at the end to discuss RS-232 and SPP (had originally planned on doing that, but decided it was to complicated for the Wiki).


#8

That sounds familiar :


#9

For testing purposes, it doesn’t really matter for the Pokitto(s). For a Pokitto linked to some other device, such as a PC with a USB to TTL converter, it would be safest if the other device is powered up before powering up the Pokitto, to avoid damaging this other device.

If individual wires are connected one at a time, instead of a cable with a connector where all contacts connect at the same time, it’s best to connect the ground wire first and disconnect the ground wire last. Both ends of each wire should be connected or disconnected before moving on the next wire, to avoid shorting the open ends of two wires connected at their other ends.

And note (which you have in the OP) that to help ensure that the Pokitto won’t be damaged, a USB to TTL converter or other device must provide 3.3V signals to the Pokitto not 5V! Even though the Pokitto’s pins are 5V tolerant, this only applies if the Pokitto is powered up. If the Pokitto is powered down, a 5V signal can damage it.


All of the I/O pins on the PEX are directly wired to the processor. As such, they are only intended for connecting to devices on the same circuit board, or to other boards or peripherals a short distance from the processor, and powered up or down at exactly the same time. For reliable and safe communications between separate devices over reasonably long distances, cabling and signalling and protocols intended for this purpose should be used. In the case of using the processor’s UART interface, RS232 is a good choice. Using a connector such as a headphone jack, should address concerns about high voltages accidentally reaching the PEX.


#10

I’ve been meaning to test the breakpoint of the gpio pins in this kind of situations. This discussion is giving me good cause to do so.


#11

Well, I’m only going by what is stated in the datasheet. You may be able to exceed these limits without noticing any problems.

However, even if experimental testing seems to allow exceeding the stated limits, that may not be the case for parts from an earlier or later factory run.

Also, trusting test results would give me cause for concern after reading statements like the following found in the datasheet:

An ADC input voltage above 3.6 V can be applied for a short time without leading to immediate, unrecoverable failure. Accumulated exposure to elevated voltages at 4.6 V must be less than 10^6 s total over the lifetime of the device. Applying an elevated voltage to the ADC inputs for a long time affects the reliability of the device and reduces its lifetime.


#12

Ok, I’ve done the update I talked about. if someone wants to provide instructions for an iPhone, I’d be glad to add them.


#13

Can you test with a single Pokitto connecting 6 to 7? Having the Pokitto talking to itself.
That is the way I test serial by having physical echoes of what you type.


#14

You’re right, a simple loopback test works. It just isn’t as satisfying to me, so I overlooked it. I’ll add it right now.