Inverted serial signaling with SerialPIO?

[myklemykle]

Hi,

I see that the SoftwareSerial wrapper around SerialPIO does not support the inverted-signaling feature of SoftwareSerial. Is there some other way to do inverted signaling with SerialPIO? I just need to do this on the transmit side.

It looks like the high-idle signal happens in pio_uart.pio? So maybe that would have to be inverted in that file? There must be some way to write a PIO program to do this, some mirror-world version of pio_uart.pio ... but it's daunting.

Or is there some higher-level switch to invert all the signals from a PIO instance, or all the signals on a GPIO?

(Why? I'm trying to pass MIDI signals through two audio outputs that have DC-blocking capacitors on them. Because of the MIDI TRS wiring standard, the MIDI signal goes between two output pins rather than between one pin and ground. Without the DC blocking in place, I can use SerialPIO + Arduino MIDI on the tip pin, set the ring pin high, and it works. But the DC blocking cap on the ring pin prevents that pin from supplying a constant +v. If the ring pin was instead sending the exact inverse signal of the tip pin, then I think the current would be AC-enough to pass the blocking cap.)

Thanks for any advice!
-m-

[earlephilhower]

Looking at the datasheet, there doesn't seem to be an invert this pin bit, so I do believe for inverted output you'd need to hack SerialPIO.

That said, if you just need to invert output then I think it's almost trivial. Not tested, but you'd invert the data bits before writing to the FIFO here:

arduino-pico/cores/rp2040/SerialPIO.cpp

Line 367 in 6e52b72

pio_sm_put_blocking(_txPIO, _txSM, val);

becomes

pio_sm_put_blocking(_txPIO, _txSM, ~val);

And then in the PIO program you'd need to set the idle bit to low:

arduino-pico/cores/rp2040/pio_uart.pio

Line 32 in 6e52b72

pull side 1 ; Force stop bit

becomes

pull               side 0 ; Force stop bit

You'd need to pioasm the updated .pio file, of course, for that change to take effect.

[earlephilhower]

For some reason GH didn't send a mail with your update. Visually, looks OK. But given what you're seeing, it seems like maybe the PIO program is not using the _inv version.

The problem, I think, is that the PIO programs are actually dynamically generated (only that initial set x, ## changes between 5..8 bits per char) and the static PIOProgram *_getTxProgram(int bits) call is using the &pio_tx_program and not the one you're hoping to use.

There is a std::map<> defined just before those calls in the same file. I suggest the easiest thing to do is to make bits signed in the std::map<> with positive being normal and negative being inverted. Basically you'd do something like

static PIOProgram *_getTxProgram(int bits) {
    auto f = _txMap.find(bits);
    if (f == _txMap.end()) {
        pio_program_t * p = pio_make_uart_prog(abs(bits), bits < 0 ? &pio_tx_program_inv : &pio_tx_program);
        _txMap.insert({bits, new PIOProgram(p)});
        f = _txMap.find(bits);
    }
    return f->second;
}

...
void SerialPIO::begin(unsigned long baud, uint16_t config) {
    ...
    if (_tx != NOPIN) {
        _txBits = _bits + _stop + (_parity != UART_PARITY_NONE ? 1 : 0) + 1/*start bit*/;
        _txPgm = _getTxProgram(_txBits * _inverted ? -1 : 1);
    ...

[myklemykle]

Thanks for your patience with this. You're right about the cause -- if I just hack up the pio_tx program to set it low, i see it going low. But I actually tried to fix this per your suggestion once already & I don't see an effect. Here's what it looks like:

static PIOProgram *_getTxProgram(int bits, bool inverted) {
    auto f = _txMap.find(bits * (inverted ? -1 : 1));
    if (f == _txMap.end()) { 
        pio_program_t * p;
        if (inverted)
          p = pio_make_uart_prog(bits, &pio_tx_inv_program);
        else
          p = pio_make_uart_prog(bits, &pio_tx_program);
        _txMap.insert({bits, new PIOProgram(p)});
        f = _txMap.find(bits);
    }
    return f->second;
}       

Does anything has to change in pio_tx_program_init ? One version of that is being called for both tx programs, and it mentions driving the output high.

[earlephilhower]

Here's the issue:

....
        _txMap.insert({bits, new PIOProgram(p)});
        f = _txMap.find(bits);
....

You want to make bits negative in the map and the find...

....
        _txMap.insert({bits * (inverted ? -1 : 1), new PIOProgram(p)});
        f = _txMap.find(bits * (inverted ? -1 : 1));

[myklemykle]

Duh! Okay it's working now. Thanks so much for your help.

I can submit a PR with just this inverted TX addition, but it seems like it would be complete & useful to provide the inverted RX version as well. But I'm not actually set up to test that at the moment. Should I submit just the TX half?

[earlephilhower]

I'd say submit anyway. I might manually add (untested, but it's pretty simple at least it would be there as a start for someone who cares enough to try) the Rx side to the PR just for completeness.

[Andy2No]

(Why? I'm trying to pass MIDI signals through two audio outputs that have DC-blocking capacitors on them. Because of the MIDI TRS wiring standard, the MIDI signal goes between two output pins rather than between one pin and ground.

It's a current loop, driving an LED inside the opto-isolator of the receiving device. One pin, on the transmit / output side is meant to be connected to +5V DC, via a 220R resistor (that pin drives the anode of the LED), the other side should be connected to your output pin via another 220R resistor, but yes, it's active low (that output pin drives the cathode of the LED), so it would be nice to have an inverted output, to save having the open collector inverting buffer, or transistor, that it should have.

Since we're just driving an LED, using 3V logic signals with a 3.3V supply instead of 5V is fine, though really the resistor values should be adjusted to keep the LED current in a 5-10mA range.

I can see how it can still work with a capacitor on the output, but do you have to have one on both pins? It would simplify it if you could have the anode side pin of the MIDI socket connected directly to 3.3V via a resistor, staying closer to the MIDI spec.

Inverting the data may work but the idle state of the UART (PIO) should be inverted too. Since there's a DC blocking capacitor, you might get away with not inverting it but it seems like it could add more problems, especially with seeing the first bit of the transmission... You might have to add some dummy start bits to the data, to get around that.

FWIW, a ULN2003A makes a good inverting open collector buffer in chip form, but you get seven of them in one chip. You could use the rest to drive brighter LEDs via resistors, or just ignore them. An NPN transistor with two resistors works too - one to limit the base current, and one to limit the collector current.

MIDI will still work without using an open collector output, but that was the intention.

[myklemykle]

Thanks for the thoughts. FWIW this board has only 2v-3.v power to drive MIDI with. I'm not in a position to change that, or to change the hardware. Also the output channels have lowpass filters on them to suppress hf noise. Can't change those either.

Fortunately the MIDI wiring standard specifies current, not voltage. Since i have a UART on both the source and sink pins of the MIDI port, and since the MIDI connection will be opto-isolated by definition, I can drive the same signal to both pins and invert one of them, so the voltage swing is more like -2.5 to +2.5 -- but less actually, due to the filters.

But apparently it's enough to make the difference! I am now sending data successfully. I'll see how well it works at lower power & with other MIDI ports, but so far I'm pleased. (And/or relieved, since i promised this feature without really understanding the standard. =)