using a pi 400 to debug a pico

Post by john larkin
The Raspberry Pi pico has its 3-pin SWD debug port. I'd like to
connect it to the 40-pin header on the back of the Pi400, to use the
400 as the dev/debug platform for some RP2040-based boxes.
Has anyone done this? What Pi400 pins connect to the SWD port?
Googling doesn't help. I have the RP400 Beginners Guide book and it
doesn't mention doing this.
Anybody have links about doing this?

https://www.electronicshub.org/programming-raspberry-pi-pico-with-swd/

john larkin

2024-01-15 23:13:21 UTC

On Mon, 15 Jan 2024 13:21:14 -0800 (PST), Lasse Langwadt Christensen

https://www.electronicshub.org/programming-raspberry-pi-pico-with-swd/

It doesn't say so, but when he says "raspberry pi" I think he means a
Pi3. I'll be using a Pi4, inside the Pi400 unit, but I expect the pins
are the same on its 40-pin header.

Oh, I found a reference in the book "Programming the Raspberry Pi
Pico/w in C". Looks like the same pins, GPIO24(18) and GPIO25(22).

Thanks

I'm designing a PCB that will have a 40 pin ribbon cable connector to
the Pi400 and a 20-pin ribbon to the various RP2040 target boards. It
will do the debug connection and have a bunch of scope mux's and DVM
mux's and stuff, to make it easy to time code execution and check the
power supplies and such.

Looks like I can power my board from the 40 pin header too.

Lasse Langwadt Christensen

2024-01-16 00:34:31 UTC

Post by john larkin
On Mon, 15 Jan 2024 13:21:14 -0800 (PST), Lasse Langwadt Christensen

https://www.electronicshub.org/programming-raspberry-pi-pico-with-swd/

It doesn't say so, but when he says "raspberry pi" I think he means a
Pi3. I'll be using a Pi4, inside the Pi400 unit, but I expect the pins
are the same on its 40-pin header.

afaik the 40 pin header on all Pi's are compatible, except for maybe some of the alternate functions
and on the Pi5 the GPIOs are one the new RP1 chip via pci-e so probably adds a us of latency

John Larkin

2024-01-16 03:18:40 UTC

On Mon, 15 Jan 2024 16:34:31 -0800 (PST), Lasse Langwadt Christensen

Post by john larkin
On Mon, 15 Jan 2024 13:21:14 -0800 (PST), Lasse Langwadt Christensen

https://www.electronicshub.org/programming-raspberry-pi-pico-with-swd/

It doesn't say so, but when he says "raspberry pi" I think he means a
Pi3. I'll be using a Pi4, inside the Pi400 unit, but I expect the pins
are the same on its 40-pin header.

afaik the 40 pin header on all Pi's are compatible, except for maybe some of the alternate functions
and on the Pi5 the GPIOs are one the new RP1 chip via pci-e so probably adds a us of latency

I probably don't care about the latency of the port pins from the 40
pin header, from the Pi400. It will be controlling multiplexers and
such. We'll use port pins from the RP2040 chip on the DUT to time
software, but those are real port pins.

Michael Schwingen

2024-01-16 13:58:13 UTC

What debug software are you planning to use? OpenOCD?

The pinout seems to be quite flexible - look at
interface/raspberrypi-gpio-connector.cfg in the OpenOCD sources /
distribution.

If you want something nice with level translation that handles power
sequencing between Pi and Target board, the JTAG Hat should do what you
want:

https://github.com/mschwingen/hardware/tree/master/JTAG_hat

I think this should also work an a pi400.

cu
Michael

--
Some people have no respect of age unless it is bottled.

John Larkin

2024-01-16 15:33:19 UTC

On 16 Jan 2024 13:58:13 GMT, Michael Schwingen

What debug software are you planning to use? OpenOCD?

Whatever the pi400 uses. I'll let a programmer deal with that.

Post by Michael Schwingen
The pinout seems to be quite flexible - look at
interface/raspberrypi-gpio-connector.cfg in the OpenOCD sources /
distribution.
If you want something nice with level translation that handles power
sequencing between Pi and Target board, the JTAG Hat should do what you
https://github.com/mschwingen/hardware/tree/master/JTAG_hat
I think this should also work an a pi400.

Is there a schematic somewhere?

I plan to make my own board, as described. I'm especially interested
in scoping realtime performance.

Post by Michael Schwingen
cu
Michael

Michael Schwingen

2024-01-16 15:57:32 UTC

Post by Michael Schwingen
If you want something nice with level translation that handles power
sequencing between Pi and Target board, the JTAG Hat should do what you
https://github.com/mschwingen/hardware/tree/master/JTAG_hat
I think this should also work an a pi400.

Is there a schematic somewhere?

It is linked in the description:

https://github.com/mschwingen/hardware/tree/master/JTAG_hat/pcb_ms_v3/Doc

It's basically a bunch of 74LVC2T45 (which handle the "one side powered
down" as well as the level-shifting), plus open-drain drivers for the reset
signals. Note that you need to switch direction for the SWDIO signal, the
rest is unidirectional.

cu
Michael

--
Some people have no respect of age unless it is bottled.

John Larkin

2024-01-16 16:35:30 UTC

On 16 Jan 2024 15:57:32 GMT, Michael Schwingen

Is there a schematic somewhere?

https://github.com/mschwingen/hardware/tree/master/JTAG_hat/pcb_ms_v3/Doc
It's basically a bunch of 74LVC2T45 (which handle the "one side powered
down" as well as the level-shifting), plus open-drain drivers for the reset
signals. Note that you need to switch direction for the SWDIO signal, the
rest is unidirectional.
cu
Michael

Do you think it's worth buffering the SW Debug pins? I was thinking I
might buffer the clock, since it's unidirectional and maybe
edge/impedance sensitive. I have no idea what the timing from the
Pi400 will be like, but people seem to use breadboards and dangling
wires and get away with it.

If the rate is reasonably low, the SWDIO data line won't matter much.

Michael Schwingen

2024-01-16 19:04:14 UTC

Post by Michael Schwingen
https://github.com/mschwingen/hardware/tree/master/JTAG_hat/pcb_ms_v3/Doc
It's basically a bunch of 74LVC2T45 (which handle the "one side powered
down" as well as the level-shifting), plus open-drain drivers for the reset
signals. Note that you need to switch direction for the SWDIO signal, the
rest is unidirectional.

Do you think it's worth buffering the SW Debug pins?

Definitely. Otherwise, when powering down one side of the link (eg. the
RP2040 target), current from any data line being "H" will flow through the
target's protection diodes into its VCC.

This leads to all kinds of problems (like the device not properly starting
when powered up again). It will probably survive, but it's unspecified
behaviour and may cause hours of debugging trouble.

The cheap solution is series resistors that limit the current to non-fatal
levels, but then you may have to lower the speed and may still experience
strange behaviour.

IMHO, at the price of a few LVC buffers, it is not worth leaving them out.
And with the buffers, you can handle targets running at voltages other than
3.3V.

Post by John Larkin
I was thinking I
might buffer the clock, since it's unidirectional and maybe
edge/impedance sensitive.

You definitely need series resistors in the clock line to reduce reflections
- I had to add them on some other debug probe (BusBlaster, old revision)
where they were missing, causing errors at ~15cm cable length.

Post by John Larkin
I have no idea what the timing from the
Pi400 will be like, but people seem to use breadboards and dangling
wires and get away with it.

It's the edge rate that matters, and the SWCLK input on the RP2040 will be
quite fast. Again, it's not worth saving some cents and have unreliable
operation afterwards.

cu
Michael

--
Some people have no respect of age unless it is bottled.

john larkin

2024-01-16 21:15:57 UTC

On 16 Jan 2024 19:04:14 GMT, Michael Schwingen

Do you think it's worth buffering the SW Debug pins?

Definitely. Otherwise, when powering down one side of the link (eg. the
RP2040 target), current from any data line being "H" will flow through the
target's protection diodes into its VCC.
This leads to all kinds of problems (like the device not properly starting
when powered up again). It will probably survive, but it's unspecified
behaviour and may cause hours of debugging trouble.
The cheap solution is series resistors that limit the current to non-fatal
levels, but then you may have to lower the speed and may still experience
strange behaviour.
IMHO, at the price of a few LVC buffers, it is not worth leaving them out.
And with the buffers, you can handle targets running at voltages other than
3.3V.

Post by John Larkin
I was thinking I
might buffer the clock, since it's unidirectional and maybe
edge/impedance sensitive.

Post by John Larkin
I have no idea what the timing from the
Pi400 will be like, but people seem to use breadboards and dangling
wires and get away with it.

It's the edge rate that matters, and the SWCLK input on the RP2040 will be
quite fast. Again, it's not worth saving some cents and have unreliable
operation afterwards.
cu
Michael

The Pico schematic is instructive. It claims that the RP2040 chip has
no diodes to its Vcc, and the pico has no added resistors that might
limit current in logic signals. There is one fet in the VSYS adc path
that I don't understand.

Lasse Langwadt Christensen

2024-01-16 21:41:07 UTC

Post by john larkin
On 16 Jan 2024 19:04:14 GMT, Michael Schwingen

Do you think it's worth buffering the SW Debug pins?

Definitely. Otherwise, when powering down one side of the link (eg. the
RP2040 target), current from any data line being "H" will flow through the
target's protection diodes into its VCC.
This leads to all kinds of problems (like the device not properly starting
when powered up again). It will probably survive, but it's unspecified
behaviour and may cause hours of debugging trouble.
The cheap solution is series resistors that limit the current to non-fatal
levels, but then you may have to lower the speed and may still experience
strange behaviour.
IMHO, at the price of a few LVC buffers, it is not worth leaving them out.
And with the buffers, you can handle targets running at voltages other than
3.3V.

Post by John Larkin
I was thinking I
might buffer the clock, since it's unidirectional and maybe
edge/impedance sensitive.

Post by John Larkin
I have no idea what the timing from the
Pi400 will be like, but people seem to use breadboards and dangling
wires and get away with it.

It's the edge rate that matters, and the SWCLK input on the RP2040 will be
quite fast. Again, it's not worth saving some cents and have unreliable
operation afterwards.
cu
Michael

it is there to stop back feeding the chip thought the ADC pin when the 3.3V is off.
The ADC capable pins have diodes to VCC, it is only the FT pins that doesn't have diodes

john larkin

2024-01-16 22:44:51 UTC

On Tue, 16 Jan 2024 13:41:07 -0800 (PST), Lasse Langwadt Christensen

Post by john larkin
On 16 Jan 2024 19:04:14 GMT, Michael Schwingen

Do you think it's worth buffering the SW Debug pins?

Definitely. Otherwise, when powering down one side of the link (eg. the
RP2040 target), current from any data line being "H" will flow through the
target's protection diodes into its VCC.
This leads to all kinds of problems (like the device not properly starting
when powered up again). It will probably survive, but it's unspecified
behaviour and may cause hours of debugging trouble.
The cheap solution is series resistors that limit the current to non-fatal
levels, but then you may have to lower the speed and may still experience
strange behaviour.
IMHO, at the price of a few LVC buffers, it is not worth leaving them out.
And with the buffers, you can handle targets running at voltages other than
3.3V.

Post by John Larkin
I was thinking I
might buffer the clock, since it's unidirectional and maybe
edge/impedance sensitive.

Post by John Larkin
I have no idea what the timing from the
Pi400 will be like, but people seem to use breadboards and dangling
wires and get away with it.

It's the edge rate that matters, and the SWCLK input on the RP2040 will be
quite fast. Again, it's not worth saving some cents and have unreliable
operation afterwards.
cu
Michael

it is there to stop back feeding the chip thought the ADC pin when the 3.3V is off.
The ADC capable pins have diodes to VCC, it is only the FT pins that doesn't have diodes

But the possible current is from its own VSYS through a 200K resistor.

Even before the 3.3 volt switcher starts up, that's under 25 uA. Is
that some sort of hazard?

How about any external analog inputs? Do they have to be limited to
microamps?

Lasse Langwadt Christensen

2024-01-16 23:10:41 UTC

Post by john larkin
On Tue, 16 Jan 2024 13:41:07 -0800 (PST), Lasse Langwadt Christensen

Post by john larkin
On 16 Jan 2024 19:04:14 GMT, Michael Schwingen

Do you think it's worth buffering the SW Debug pins?

Definitely. Otherwise, when powering down one side of the link (eg. the
RP2040 target), current from any data line being "H" will flow through the
target's protection diodes into its VCC.
This leads to all kinds of problems (like the device not properly starting
when powered up again). It will probably survive, but it's unspecified
behaviour and may cause hours of debugging trouble.
The cheap solution is series resistors that limit the current to non-fatal
levels, but then you may have to lower the speed and may still experience
strange behaviour.
IMHO, at the price of a few LVC buffers, it is not worth leaving them out.
And with the buffers, you can handle targets running at voltages other than
3.3V.

Post by John Larkin
I was thinking I
might buffer the clock, since it's unidirectional and maybe
edge/impedance sensitive.

Post by John Larkin
I have no idea what the timing from the
Pi400 will be like, but people seem to use breadboards and dangling
wires and get away with it.

It's the edge rate that matters, and the SWCLK input on the RP2040 will be
quite fast. Again, it's not worth saving some cents and have unreliable
operation afterwards.
cu
Michael

it is there to stop back feeding the chip thought the ADC pin when the 3.3V is off.
The ADC capable pins have diodes to VCC, it is only the FT pins that doesn't have diodes

But the possible current is from its own VSYS through a 200K resistor.
Even before the 3.3 volt switcher starts up, that's under 25 uA. Is
that some sort of hazard?

maybe it is for running on a battery, afaict the quiescent current on the switcher when disabled is only 1uA
but then they have a 100k pull up on enable ...

Post by john larkin
How about any external analog inputs? Do they have to be limited to
microamps?

the datasheet doesn't mention any allowable current, only max voltage

john larkin

2024-01-16 19:02:19 UTC

On 16 Jan 2024 15:57:32 GMT, Michael Schwingen

Is there a schematic somewhere?

This is a first pass at the dev board.

Loading Image...

It would be used in development and production test. Every
RP2040-based board would have the small-pitch 20 pin ribbon cable
header.

The pushbuttons look primitive but will probably work.

Michael Schwingen

2024-01-17 17:59:55 UTC

Post by john larkin
This is a first pass at the dev board.
https://www.dropbox.com/scl/fi/709v4pqjhe91jnwqh4wvg/Z566_Sch_2.jpg?rlkey=fjq3a9re53cv5l0zn9ya00akk&raw=1
It would be used in development and production test. Every
RP2040-based board would have the small-pitch 20 pin ribbon cable
header.

Those are huge. For SWD, I really like the 10-pin Cortex-Debug connectors
(1.27mm pitch). Or a minimal 2*3 pin 2.54mm header.

Post by john larkin
The pushbuttons look primitive but will probably work.

What are these for? I would wire a BSS138 to a free GPIO to automate that.
However, when using SWD, you should not really need them.

cu
Michael

--
Some people have no respect of age unless it is bottled.

john larkin

2024-01-18 00:07:20 UTC

On 17 Jan 2024 17:59:55 GMT, Michael Schwingen

Those are huge. For SWD, I really like the 10-pin Cortex-Debug connectors
(1.27mm pitch). Or a minimal 2*3 pin 2.54mm header.

The half-pitch 20 wire ribbon cable is just 0.5" wide. The box
connector on the target board is just a bit wider. That's not bad.

I plan to use all 20 wires, so I can do the CPU debug and check power
supplies and clocks and stuff, and snoop code execution times.

I figure that a furious bare-metal loop on the second CPU core might
often replace an FPGA. But I want to really time some code on an
oscilloscope.

I saw somewhere that the RP2040 has some fast bit counting calls. So
maybe an SPI interface and those calls might decode a delta-sigma ADC
at some usable rate.

https://www.amazon.com/Signals-Systems-Dummies-Mark-Wickert/dp/111847581X

Post by john larkin
The pushbuttons look primitive but will probably work.

What are these for? I would wire a BSS138 to a free GPIO to automate that.
However, when using SWD, you should not really need them.

Pushing the buttons can set the 2040 into USB memory-stick mode, to
access the flash. That could be handy.

I think I'll do both, allow the buttons and a couple of Pi400 port
pins to ground RUN and BOOT. The boot pin is overloaded, actually the
flash memory chip select!

Do you know if there is a way for running software to essentialy reset
itself and enter the USB flash-stick mode? That could be handy for
field code upgrades.

Post by Michael Schwingen
cu
Michael

Michael Schwingen

2024-01-18 18:19:18 UTC

Post by Michael Schwingen
Those are huge. For SWD, I really like the 10-pin Cortex-Debug connectors
(1.27mm pitch). Or a minimal 2*3 pin 2.54mm header.

Ah, OK - I had assumed this was the standard ARM 20-pin 2.54mm connector.

Post by Michael Schwingen
What are these for? I would wire a BSS138 to a free GPIO to automate that.
However, when using SWD, you should not really need them.

Pushing the buttons can set the 2040 into USB memory-stick mode, to
access the flash. That could be handy.

Hm. I would assume you use SWD if you have it available - that should be
better for scripted/automatic flashing since it dows not need to wait for a
simulated USB stick to appear and be mounted.

Post by john larkin
I think I'll do both, allow the buttons and a couple of Pi400 port
pins to ground RUN and BOOT.

That sounds good.

Post by john larkin
Do you know if there is a way for running software to essentialy reset
itself and enter the USB flash-stick mode? That could be handy for
field code upgrades.

Sorry, no - I have some here, but beyond doing some simple tests, I have not
looked into the details. I would guess yes - entering the bootloader for
upgrades is possible on almost any microcontroller I have used in the past.

However, for field upgrades, you should ask yourself if the stock bootloader
is the right thing to use if the upgrade is done by the end user - I would
recommend to use some kind of bootloader that is specific to your product
and makes sure that only correct files that are intended for this exact
board can be uploaded. On our devices, the firmware file has a header with
the device name in it, and the bootloader checks that (plus checksums and a
signature) before allowing an upgrade.

If the field upgrade is performed by trained technicians, the stock
bootloader may be OK - but keep in mind that flashing the wrong file may
damage the hardware (for example by setting pins to output mode that should
be inputs), unless you plan ahead for this scenario and design the hardware
so that it is robust against this kind of abuse.

cu
Michael

--
Some people have no respect of age unless it is bottled.

whit3rd

2024-01-17 20:16:29 UTC

Why bother with pins, and ribbon connector insertion force? Just print
test point pads, a few alignment holes, and make a plug of
spring pins. It's not like you need this access while the unit is
bolted into its box and racked into a larger system.

Do it with two different diameter alignment pins, so it doesn't get
reversed. A captive nut to retain it would be useful, too.

john larkin

2024-01-18 00:10:07 UTC

Why bother with pins, and ribbon connector insertion force? Just print
test point pads, a few alignment holes, and make a plug of
spring pins. It's not like you need this access while the unit is
bolted into its box and racked into a larger system.
Do it with two different diameter alignment pins, so it doesn't get
reversed. A captive nut to retain it would be useful, too.

Too much work! We can buy the ribbon cables and connectors from
stock.

Jasen Betts

2024-03-09 01:26:48 UTC

Why bother with pins, and ribbon connector insertion force? Just print
test point pads, a few alignment holes, and make a plug of
spring pins. It's not like you need this access while the unit is
bolted into its box and racked into a larger system.
Do it with two different diameter alignment pins, so it doesn't get
reversed. A captive nut to retain it would be useful, too.

Too much work! We can buy the ribbon cables and connectors from
stock.

True, you'd have to order from digikey and wait a day to get such a
connector (tag connect)

we use the Tag Connect TC2030IDC connector intended for PIC programming to
program our ESP32 boards one end plugs right into the ESP-prog, no
modification is needed.

The price seems to have dropped recently, perhaps a patent has
expired, also I'm seeing Chinese clones now.

--
Jasen.
🇺🇦 Слава Україні

John Larkin

2024-03-09 17:23:24 UTC

On Sat, 9 Mar 2024 01:26:48 -0000 (UTC), Jasen Betts

Why bother with pins, and ribbon connector insertion force? Just print
test point pads, a few alignment holes, and make a plug of
spring pins. It's not like you need this access while the unit is
bolted into its box and racked into a larger system.
Do it with two different diameter alignment pins, so it doesn't get
reversed. A captive nut to retain it would be useful, too.

Too much work! We can buy the ribbon cables and connectors from
stock.

True, you'd have to order from digikey and wait a day to get such a
connector (tag connect)
we use the Tag Connect TC2030IDC connector intended for PIC programming to
program our ESP32 boards one end plugs right into the ESP-prog, no
modification is needed.
The price seems to have dropped recently, perhaps a patent has
expired, also I'm seeing Chinese clones now.

A 20 pin half-pitch ribbon cable would take, if anything, less board
area, and be less wobbly. And has 20 connections! I could use a 16 pin
ribbon connector, but I have plans for all 20. I want to do more than
just JTAG a CPU.

John Larkin

2024-03-09 17:36:09 UTC

On Sat, 9 Mar 2024 01:26:48 -0000 (UTC), Jasen Betts

Why bother with pins, and ribbon connector insertion force? Just print
test point pads, a few alignment holes, and make a plug of
spring pins. It's not like you need this access while the unit is
bolted into its box and racked into a larger system.
Do it with two different diameter alignment pins, so it doesn't get
reversed. A captive nut to retain it would be useful, too.

Too much work! We can buy the ribbon cables and connectors from
stock.

True, you'd have to order from digikey and wait a day to get such a
connector (tag connect)
we use the Tag Connect TC2030IDC connector intended for PIC programming to
program our ESP32 boards one end plugs right into the ESP-prog, no
modification is needed.
The price seems to have dropped recently, perhaps a patent has
expired, also I'm seeing Chinese clones now.

Why do many of the target PCBs have four additional giant holes?

https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcTlRvjZHFFNSi9PpkrUiXktuw0dU9DN3lM_ww&usqp=CAU

https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcTNgPz2NFWTfZgl-GSKQ6u6jeSGHt--yJQqjQ&usqp=CAU

Jasen Betts

2024-03-09 19:51:58 UTC

Post by John Larkin
On Sat, 9 Mar 2024 01:26:48 -0000 (UTC), Jasen Betts

Why bother with pins, and ribbon connector insertion force? Just print
test point pads, a few alignment holes, and make a plug of
spring pins. It's not like you need this access while the unit is
bolted into its box and racked into a larger system.
Do it with two different diameter alignment pins, so it doesn't get
reversed. A captive nut to retain it would be useful, too.

Too much work! We can buy the ribbon cables and connectors from
stock.

True, you'd have to order from digikey and wait a day to get such a
connector (tag connect)
we use the Tag Connect TC2030IDC connector intended for PIC programming to
program our ESP32 boards one end plugs right into the ESP-prog, no
modification is needed.
The price seems to have dropped recently, perhaps a patent has
expired, also I'm seeing Chinese clones now.

Why do many of the target PCBs have four additional giant holes?

For the retaining hooks, AKA "legs", these are optional.

--
Jasen.
🇺🇦 Слава Україні

John Larkin

2024-03-09 21:09:38 UTC

On Sat, 9 Mar 2024 19:51:58 -0000 (UTC), Jasen Betts

Post by John Larkin
On Sat, 9 Mar 2024 01:26:48 -0000 (UTC), Jasen Betts

Why bother with pins, and ribbon connector insertion force? Just print
test point pads, a few alignment holes, and make a plug of
spring pins. It's not like you need this access while the unit is
bolted into its box and racked into a larger system.
Do it with two different diameter alignment pins, so it doesn't get
reversed. A captive nut to retain it would be useful, too.

Too much work! We can buy the ribbon cables and connectors from
stock.

True, you'd have to order from digikey and wait a day to get such a
connector (tag connect)
we use the Tag Connect TC2030IDC connector intended for PIC programming to
program our ESP32 boards one end plugs right into the ESP-prog, no
modification is needed.
The price seems to have dropped recently, perhaps a patent has
expired, also I'm seeing Chinese clones now.

Why do many of the target PCBs have four additional giant holes?

For the retaining hooks, AKA "legs", these are optional.

I think they are some sorts of stabilizers; must make the connections
more reliable. They really blow up the board area. I like my 20-pin
ribbon connector better.

I can sneak the ribbon cable out of a closed box, for temperature
testing or whatever. And bring out more signals. That pogo thing
sticks up.

Jasen Betts

2024-03-11 05:38:52 UTC

Post by John Larkin
On Sat, 9 Mar 2024 19:51:58 -0000 (UTC), Jasen Betts

Post by John Larkin
On Sat, 9 Mar 2024 01:26:48 -0000 (UTC), Jasen Betts
Why do many of the target PCBs have four additional giant holes?

For the retaining hooks, AKA "legs", these are optional.

I think they are some sorts of stabilizers; must make the connections
more reliable.

They are plastic hooks they make the connection more reliable by
maintaining it hands-free. Without them you must hold the connector
to the board fighting the spring force of the pogo-pins.

Post by John Larkin
They really blow up the board area. I like my 20-pin
ribbon connector better.

Yes.

Post by John Larkin
I can sneak the ribbon cable out of a closed box, for temperature
testing or whatever. And bring out more signals. That pogo thing
sticks up.

It seems unsuited for your application.

--
Jasen.
🇺🇦 Слава Україні

John Larkin

2024-03-11 15:02:50 UTC

On Mon, 11 Mar 2024 05:38:52 -0000 (UTC), Jasen Betts

Post by John Larkin
On Sat, 9 Mar 2024 19:51:58 -0000 (UTC), Jasen Betts

Post by John Larkin
On Sat, 9 Mar 2024 01:26:48 -0000 (UTC), Jasen Betts
Why do many of the target PCBs have four additional giant holes?

For the retaining hooks, AKA "legs", these are optional.

I think they are some sorts of stabilizers; must make the connections
more reliable.

They are plastic hooks they make the connection more reliable by
maintaining it hands-free. Without them you must hold the connector
to the board fighting the spring force of the pogo-pins.

Post by John Larkin
They really blow up the board area. I like my 20-pin
ribbon connector better.

Yes.

Post by John Larkin
I can sneak the ribbon cable out of a closed box, for temperature
testing or whatever. And bring out more signals. That pogo thing
sticks up.

It seems unsuited for your application.

The real advantage of the pogo thing is its small cost saving, which
matters in high-volume, low margin products.

In high volume, one could both JTAG and access all the other signals
(like the ones I want) with a whole-board pogo fixture, but that has
downsides too.

Michael Schwingen

2024-01-18 18:24:37 UTC