Quantcast
Channel: Raspberry Pi Forums
Viewing all articles
Browse latest Browse all 4990

SDK • Re: GPIO pin handling on the Pico

$
0
0
My IEEE488 experience is a bit out-of-date (I last built an IEE488 interface back in 1979, though I've got the IEE documents from the early 1990's when I was planning to control some test equipment but never got around to it), but:

IEEE488 was traditionally an open-collector bus with resistive termination on every interface that makes the idle state of all the lines '1', and TTL-style thresholds (0.8V/2.0V).

The actual requirement of the IEEE specification are stated in a rather complicated way (with a voltage/current graph and 7 different points on a mask you have to meet), but it also states that the typical implementation is with a 3K3 pull-up (to +5V) and a 6K8 pull-down (to GND) - which if everybody implemented it that way would give you a 3.25V resting voltage (and the specification sets it at a minimum of 2.7V).

Open-collector drivers are required by the spec to achieve the required voltage levels with a current of 48mA - though in practice the requirement obviously depends on the number of devices connected. If everybody used the standard 3K3/6K8, then each device would consume 1.5mA.

So for a traditional bus, that looks quite good for directly driving it with a Pico, particularly if you only plan to control a single instrument (your interface directly on the back of a connector for example). You can emulate open-collector by selectively enabling outputs, the resting voltage is within limits and the thresholds compatible, and although the Pico can't drive 48mA as required by the spec that doesn't matter for driving a single instrument. The only slight concern is with overshoot taking the voltage over 3.3V - which again shouldn't be too bad on a very short cable to one instrument, but gets worse if you want to support a slightly longer bus.

However, unfortunately later versions of the spec allow an alternative of tristate drivers (ie. actively driving high) on most of the lines, while still requiring them to be driven in open-collector mode for some purposes. This is a total pain for the proposed Pico interface: now you can no longer assume the max voltage is 3.3V - it will still rest at 3.3V but devices may drive the signals to 5V during a message. So you now need level shifting, but the requirement to drive individual pins as if open-collector means you can't just have a 245-style buffer and one bit of direction control, you need to have individual direction control for all the pins.

The 'nothing at all' option probably still works in practice - it will stress the Pico's pins during a message, but the Pico will probably last quite a long time before it dies. So I wouldn't build one like that, but the sort of people who happily overclock the Pico to 200MHz++ in the hope that it won't die anytime soon would probably be equally happy with an overvolted IEEE488 interface.

If you are trying to build one that's within spec, I think the LXS0108E level-shifters are unlikely to be a good fit. They might work OK for the single instrument case, but for anything more the long cables and the higher currents are both going to lead to trouble.

Obviously you can use the 75160/1/2 drivers for a fully-compliant interface, but all those signals then need level-shifting. You could use the LXS0108E for that job, but we've now got a 4-chip solution and at least 3 extra GPIOs for direction control.

Putting a 74CB3Txxx between the Pico and the pins (and otherwise driving it like the no-hardware-at-all option) looks like it should work. The on-resistance of the 74CB3T is 5R, so at (say) 10mA that's dropping only 50mV. This combo won't drive a full bus up to the full spec limit of 48mA - the RP2040's max drive of 12mA limits you to 8 typical instruments - but that's probably acceptable. And this gives you individual tristate/open-collector control of every pin without any extra GPIOs taken up for direction control. It could be a single-chip interface with the 74CB3T16210, or a slightly cheaper but bigger 2-chip interface with a pair of 74CB3T3384.

Other options include using more GPIO pins and single-direction shifters. So protect all the inputs with something simple like 74LVC245, and have a row of transistors to drive all the outputs you care about, literally as open-collector. This is probably cheaper, and bullet-proof, but will have used up nearly all of the GPIOs on the RP2040.

Or build your own version of the 74CB3T with a row of FETs. Since this is meant to be open-collector with pull-ups, you don't need the cleverness of the 74CB3T, so just a row of N-FETs with a reasonably low threshold, with gate to 3V3, source to the bus and drain to a Pico GPIO. Moderate pull-up to 3V3 at the GPIO side, and the standard 3K3/6K8 on the bus side (that's needed with all of these options).

Statistics: Posted by arg001 — Sun Oct 27, 2024 9:53 am



Viewing all articles
Browse latest Browse all 4990

Trending Articles