PiDP-11 running slow with MAX3232 serial

[Mince]

[Copied from https://www.stardot.org.uk/forums/viewt ... 39#p406539 when I hijacked a thread about an HCR Electronics EPROM programmer.]

I could do with some help adding serial ports to my PiDP-11.

I built my PiDP-11 and set it up and everything was running hunky dory — blinkenlights flashing, switches and knobs working, lamp test, everything.

I wanted to add some real serial ports, though, and bought a couple of CH340G USB-TTL adapters and added a couple of Maxim MAX3232CPE+ (note 3232 and not 232, if that makes any difference) RS-232 transceivers. I used 50V 0.1µF capacitors for C1 and 0.47µF for C2-4: I picked these values from the datasheet at https://www.farnell.com/datasheets/1913103.pdf, given that Vcc is 5V.

The problem is the Pi is now running REALLY slowly — the PiDP-11 side looks fine in that all the switches seem to work and respond. If I login via SSH (over wireless), however, the Pi really grinds: things like 'apt upgrade' take ages (much longer than normal), and it is generally very sluggish.

Also, I don't get any useful output from the RS-232 interfaces: connecting something gives me no input or output, my oscilloscope can decode RS-232, so I think something is subtly wrong, such as the voltage.

If I take the Pi off the PiDP-11 board, it runs quickly again.

I'm doing more fiddling about and trying to remove things from the board again to see when it speeds up (currently, it looks like removing C2-4 has made a difference) but I'm hoping someone can suggest something obvious I should be looking for. For example, could using too large or small caps cause this?

The Pi is a 3B+ and I'm powering it from a 2.5A genuine Raspberry Pi micro USB PSU.

When running something meaty, I get a message from the kernel saying that the voltage has dropped on input. I think the PSU is OK but I'm not tried another.

The capacitors I'm using are ceramic ones, so I think unpolarised — these: https://www.farnell.com/datasheets/2305633.pdf — the MAX3232 datasheet doesn't say any particular type is needed.

Any tips greatly received!

[hoglet]

(replicating my reply from the other thread)

In PiTubeDirect we found if the Pi's UART is enabled without configuring weak pullups on GPIO 14/15 then the UART RxD line will float low. In this state the UART sees an endless stream of Null characters. This is a bit surprising, because UARTs normally identify the start bit with a 1->0 transition. So it appears the Pi UART works differenty. This caused all manner of issues with PiTubeDirect, as the UART interrupt handler was running every 100us. I'm not sure if all Pi models work like this, or just the ones that use the BCM2835.

So, it might be worth checking with a scope that the UART RxD pin on the Pi GPIO connector is close to 3.3V in the idle state, when no characters are being transmitted.

In fact, this page suggests the Pidp-11 has a voltage divider on the RxD pin. If nothing is connected, this will infact be pulling it low, even if a weak pullup is enabled.

Dave

[Mince]

Thanks — I'll try this over the weekend. At the moment, my room is full of stuff and I'll need the week to make enough space for the oscilloscope!

Oddly, now I've removed the 4x 470nF capacitors from one of the MAX3232s, I don't seem to get the issue any more, although I also don't have anything connected to it, either.

I do get the kernel message about undervoltage, and the Pi runs really sluggishly, if I run things powered from the 5V connector on the PiDP-11 board (the header shared with the 5V TTL serial port on the Pi GPIO): I'm using a bench power supply to feed 5.35V (which is what the PiDP-11 page suggests) and have a limit of 2.5A set. But, the bench power supply claims it's never supplying more than about 0.5-0.6A that way. That seems odd.

I'm wondering if there's something with a bad connection on the PiDP-11 board and I need to check my soldering.

I'll report back after more tests after the weekend.

[scruss]

If you're getting undervoltage from a proper power supply, something on your PiDP-11 board is taking too much power. Additional serial ports shouldn't add much, and MAX3232s (real ones, at least) are very low power.

The main emulator task — if it's anything like my PiDP-8/i — runs in a tight loop, so one core is always at 100%. This can make other tasks appear sluggish

I see you've asked at the right forum: Running slow with MAX3232 serial — what have I done wrong?. Someone there will know, if it can be known.

[Mince]

The PiDP-11 software seems to only use about 30% of a single core, at least when it's running the blinkenlights system.

It's odd as, if I do something like 'apt update', the load average will go up for a few seconds, whilst it's running. It will then peak at something like 1.20. But, when it finishes, I'd expect the load average to drop back down again in a few seconds, but it actually continues to rise up to 2-3 for a further three or so minutes afterwards, before falling again. 'top'., however, only shows the 'server11' process using about 30%, so I'm not sure what's causing that.

I'm not sure how the values are counted to explain the discrepancy between the 1 minute load average and the usage of each process, though. Maybe that would be explained by the interrupts on the UART as Dave mentioned.

I'll do some more fiddling over the weekend.

[Mince]

In PiTubeDirect we found if the Pi's UART is enabled without configuring weak pullups on GPIO 14/15 then the UART RxD line will float low. In this state the UART sees an endless stream of Null characters. This is a bit surprising, because UARTs normally identify the start bit with a 1->0 transition. So it appears the Pi UART works differenty. This caused all manner of issues with PiTubeDirect, as the UART interrupt handler was running every 100us. I'm not sure if all Pi models work like this, or just the ones that use the BCM2835.

So, it might be worth checking with a scope that the UART RxD pin on the Pi GPIO connector is close to 3.3V in the idle state, when no characters are being transmitted.

In fact, this page suggests the Pidp-11 has a voltage divider on the RxD pin. If nothing is connected, this will infact be pulling it low, even if a weak pullup is enabled.

When the Pi is on the PiDP-11 board, measuring between GPIO pin 6 (= GND) and pin 10 (GPIO 15, RXD), I seem to be getting mostly 0V but with occasionally "blips" up to about 680mV, about 34ns in length; if I measure at the header on the PiDP-11 board, I'm seeing blips about 480mV instead. This is without the jumpers from the UART header into the MAX3232 from being in place.

If I remove the Pi from the PiDP-11 board and just run it standalone, the voltage is 3.6V, so it looks like the behaviour you described.

Do you think this could be triggering the problem? I presume disabling the terminal on the GPIO serial UART wouldn't actually stop this from having an effect; just stop the terminal running?

I presume, also, the serial interfaces I get with the USB-TTL converters wouldn't be affected by this?

I don't remember this being an issue I tried doing the serial mod and it does seem much better now I've removed half of the 470nF capacitors around the second MAX3232. Does that make sense?

[Mince]

My previous test at the header was when it was only connected to the scope and nothing else.

I've now tried connecting the UART header to a breadboard and from that on to the MAX3232 and a couple of other wires off with the scope probe and ground clipped on. That gives me a solid 5V.

[hoglet]

Do you think this could be triggering the problem? I presume disabling the terminal on the GPIO serial UART wouldn't actually stop this from having an effect; just stop the terminal running?

You could try an experiment to test if this is the cause.

I can think of two ways to test this:

1. With the Pi removed from the PiDP-11 try connecting pin 10 (GPIO 15, RXD) to GND and see if this triggers the problem

2. With the Pi installed in the PiDP-11 try removing the 1K resistor that pulls pin 10 to ground (this is located near the serial console header) and see if this fixes the problem.

Could you post a photo of the board?

Dave

[Mince]

If I short GND and RXD on the GPIO connector, I immediately see a process called kworker/u8:N-events_unbound (where 'N' varies between 0 and 3; I think it corresponds to the core) appear and jump to the top of the process listing in 'top'. It uses between about 3.5-8% of CPU but the overall load average stays about 0.3-0.4. It doesn't, however, seem to affect the performance of the system.

When I attach the Pi to the PiDP-11 board, though, the MAX3232 brings RX up to 5V (since I have the UART pins jumped across to the TTL side of that) and I don't get any such events.

Things get more confusing, though...

I've removed the Pi from the PiDP-11 and disabled the pidp11 processes so they won't start after boot, so load average is really low — like 0.01. My test, to make the Pi do something, is to run "sudo apt install git -y ; sudo apt remove git -y ; sudo apt autoremove -y" using 'time' so I can see how long it takes.

Immediately after boot, it was 27.7s real and 19.08s user. I then ran it again, almost immediately, and it took 3m52.7s real but still 19.632s user. All throughout this, dpkg or any other processes 'apt' fires off, occasionally pop up, but mostly the top process is 'top' itself, at about 1-2% but the load average is up at 3-4. I've run it a second time and get the same result.

I think I'm tempted to get another SD card and reinstall Linux and try things on a generic install, off the PiDP-11 board, then on it, and perhaps with another Pi, then put the PiDP-11 software back on, as this is all looking a bit odd now.

[hoglet]

If I short GND and RXD on the GPIO connector, I immediately see a process called kworker/u8:N-events_unbound (where 'N' varies between 0 and 3; I think it corresponds to the core) appear and jump to the top of the process listing in 'top'. It uses between about 3.5-8% of CPU but the overall load average stays about 0.3-0.4. It doesn't, however, seem to affect the performance of the system.

OK, so this does suggest the serial port is emitting and endless series of NULL characters when pulled low, which it will be if nothing is connected to the port (i.e. no jumpers to the MAX3232).

In this state one of the cores will be fielding the UART interrupts (every 100us @ 115200 baud) and these have the potential to impact performance. That depends on what else the Pi is doing, and may have more of an effect on I/O bound tasks than CPU bound tasks.

The interrupt rate will depend on the baud rate of the UART. Any idea what this would be?

When I attach the Pi to the PiDP-11 board, though, the MAX3232 brings RX up to 5V (since I have the UART pins jumped across to the TTL side of that) and I don't get any such events.

So that's working as expected, assuming this is measured on the 5-pin header on the PiDP-11. The resistor divider will be lowering the voltage that the Pi sees.

Key question: Did you have the jumpers in place when you started experiencing the original issue?

Things get more confusing, though...

I've removed the Pi from the PiDP-11 and disabled the pidp11 processes so they won't start after boot, so load average is really low — like 0.01. My test, to make the Pi do something, is to run "sudo apt install git -y ; sudo apt remove git -y ; sudo apt autoremove -y" using 'time' so I can see how long it takes.

Immediately after boot, it was 27.7s real and 19.08s user. I then ran it again, almost immediately, and it took 3m52.7s real but still 19.632s user. All throughout this, dpkg or any other processes 'apt' fires off, occasionally pop up, but mostly the top process is 'top' itself, at about 1-2% but the load average is up at 3-4. I've run it a second time and get the same result.

I think I'm tempted to get another SD card and reinstall Linux and try things on a generic install, off the PiDP-11 board, then on it, and perhaps with another Pi, then put the PiDP-11 software back on, as this is all looking a bit odd now.

I think this is worth a try.

If the SD card is in any way unreliable it can cause all manner of wierdness.

Dave

[Mince]

In this state one of the cores will be fielding the UART interrupts (every 100us @ 115200 baud) and these have the potential to impact performance. That depends on what else the Pi is doing, and may have more of an effect on I/O bound tasks than CPU bound tasks.

The interrupt rate will depend on the baud rate of the UART. Any idea what this would be?

I'd used raspi-config to enable the UART with kernel messages and a serial terminal and set the baud to 9600, so I assume that rate?

When I attach the Pi to the PiDP-11 board, though, the MAX3232 brings RX up to 5V (since I have the UART pins jumped across to the TTL side of that) and I don't get any such events.

So that's working as expected, assuming this is measured on the 5-pin header on the PiDP-11. The resistor divider will be lowering the voltage that the Pi sees.

Key question: Did you have the jumpers in place when you started experiencing the original issue?

Yes — I've got two MAX3232s in there: two are connected to the USB-TTL adapters (which I was hoping to give me serial terminals into the emulated PDP-11, but I stopped playing with that as I had this problem).

The other MAX3232 had one TTL link connected to the Pi UART header on the PiDP-11 board; the other was not connected — I assume that wouldn't have been a problem?

I think I'm tempted to get another SD card and reinstall Linux and try things on a generic install, off the PiDP-11 board, then on it, and perhaps with another Pi, then put the PiDP-11 software back on, as this is all looking a bit odd now.

I think this is worth a try.

If the SD card is in any way unreliable it can cause all manner of wierdness.

I've done some more testing — I moved the SD card to a spare Pi 2B and I get the same behaviour (although it takes around 32s user as it's slower, but real time is still 4-5 minutes).

I then replaced the SD card I normally use in the Pi 2B (which just has Raspberry Pi OS without a desktop and not much extra installed, although I think the GPIO is enabled as I had an LED screen and temperature sensor connected, although not now), certainly not the PiDP-11 software. That doesn't seem to have the same issues: it always takes the same (sub-minute) real time to run. I've now moved that SD card to the Pi 3B+ and it is consistently running the above command in around 30s of real time and 16.358s of user time, even when it's reinstalled on the PiDP-11 board (with the UART connected to the MAX3232). So I'm now thinking it's a software problem.

I'll take a fresh card and install Raspberry Pi OS on it, test it as above, whilst connected to the PiDP-11 board. If all is good, I'll gradually reinstall things and see where and if it goes wrong, but this is looking more like a software problem (or a problem with the SD card) now!

[Mince]

The good news is that I've fixed things, and the cause was... the SD card! Or perhaps the type of SD card!

I was using a SanDisk Ultra 16GB, SDHC C10 (one of the red and grey ones) and I've switched to a SanDisk Edge 16GB, SDHC A1 U1 C10 (a black one) and everything is now working. I tried a different SanDisk Ultra red/grey one and had the same problem (with a fresh image written to the card). The first alternative card I tried was another black SanDisk 16GB U1 C10 card, not branded Edge, and that didn't have any problems.

This is all very weird — maybe the two SanDisk Ultra cards are broken in some way, but I get no errors, just sluggish performance once it gets busy, or maybe they're optimised for video or large files: I've used those in some other Pis and not had any issues, though. I'm going to stick with the Edge though.

This is all without changing the MAX3232s out, plus using the 0.1µF and 0.47µF capacitors; all the serial ports are working, too (although I haven't got them working under BSD2.11 yet, but that's for later)! So I think everything is OK.

I haven't had the 'undervoltage' errors since I've had the PiDP-11 in pieces and I've traced that to the short extension between the Micro USB power input on the Pi and the panel mount connector: if I put that back inline, I get the warnings; that it out and they go. I've ordered a new one of these that is supposedly compatible with the Pi3B (I'm getting it from ThePiHut, so I assume it's going to cope with the higher current/voltage).

So, it turned out to have nothing to do with my soldering or electronics and was something different. Sorry for leading you all on a wild goose chase and thanks for all your help!