That’s why it’s a tea table discussion 
Maybe one of these could be used for pullups/pulldowns in a future version of the cheap BusPirate, aka. followup of the current Rev5?
You’d probably only use one of them with one pull resistor value. Or maybe two if you want them on both sides of the connector for layout reasons.
But then also the cheap BP would get pullups and pulldowns.
Nice suggestion!
I need to review what would be needed. The I2Creset could be moved to the 595s. Not sure where the I2C pins could come from without the schematic in front of me.
Maybe an I2C Io expander could help, but I’m pretty sure everything that can be offloaded is already attached to the 595s. There’s not a lot of pins on the 2040.
This does lead into something I’ve been pondering.
At some point it will be cost effective to migrate 5rev10 to the rp2350 for the extra ram. This is effectively the 5XL. Then maybe some upgrades like the per pin pullx you suggest. While keeping the BOM cost similar.
I’ve kind of painted myself in a corner with a constantly incrementing version number. It feels like we need a Samsung Galaxy like tiered system.
This might lead to expectations that all three tiers are upgraded at the same time. That’s just not a sound investment in FCC/CE compliance certs though.
Maybe not 3 tiers, but just two would suffice?
A slightly & carefully upgraded 5 for the cheap tier and the fully-featured one once we figured out which of the ideas we are currently testing in 7Rev0, 7Rev1 and 8 work out.
And BTW: if we don’t find a reasonable way to fit the Vout protection onto the board without breaking the bank, then I am not angry if we leave it out even if I invested some time into developing it. We just should have properly tried to make enough space.
I have no doubt we will get there, but step by step. There’s no deadline, and prototype boards are cheap.
We will have a lot more concrete info tomorrow with regard to two sides assembly.
You mentioned that you want to send 7RevA-PC1 to layout soon.
So I did a quick stroll through the schematics.
I’ve noticed that you haven’t moved the BUTTONS input to the new I2C GPIO expander. Currently all the other pins are outputs, so you neither have to poll, nor connect the interrupt/INT pin.
When you connect BUTTONS to the I2C expander and connect it’s INT to the RP2350 it would currently be a zero-sum thing.
But it looks to me like CURRENT_DETECT is also a digital input, though you are currently reading it with the ADC mux. I guess this was done to save pins? Would save ADC cycles to move that to the new GPIO expander.
Also there were ideas floating around like using a 4-way joystick instead of a single button. These inputs would probably have to always go through the GPIO expander. So I’d say better connect the INT now.
I sat down to change that, but then I thought we might want analog debouncing before offloading that to the IO expander. I would like to give it some more thought.
incidentally I got some samples of such 4-way joysticks yesterday.
When you add a small cap or stick to the top it feels really nice and clicky. Good haptic feedback. Would allow to add some properly usable menu to the lcd.
But the downside is that it is huge, especially the height. It would mean you’d have to substantially increase the height of the case to fit it. So I’m not sure if it is worth.
But maybe you can get some samples yourself and try it out for yourself.
What kind of debouncing do you currently do for the button? Some software thing?
Even if you keep the button connected to the RP2350 I would still consider moving CURRENT_DETECT off the ADC (to the RP2350 or the gpio expander), just because it is a digital signal and we don’t want to waste ADC cycles on it. Also having interrupt capability for it would be nice.
Yes, I agree. I will work something out and propose it here.
Oh, goodness, that’s a chonky switch! 10.3mm!
Yes, “some software thing” TM. It was on a roll for a bit (short vs long vs double taps). But the proper thing is to do it in PIO. I’m always open to new derivatives though.
Yes, PIO should work well for debouncing. So the button stays on the RP2350 (until I suggest to add a secondary RP2040 just for IO muxing 
)
Have you seen the BP6REV0? It was a 2021-2 attempt to use two RP2040 to replace all the other chips. Shades of that.
Edit:
6REV1 was rp2350 with the core voltage smps
6REV2 with rp2350 with external core regulator is what actually went into production.
I didn’t look into these older designs yet. And you were under NDA back then and couldn’t publish progress reports. So I didn’t see it happen live.
Did you have issues with the core smps of the RP2350 in 6REV1? Even when using the magic Abracon inductor, spun by fair maidens during moonlight out of unicorn hair, orientation determined by divining rod?
The first 6 was actually made with RP2040s. According to the PCB, we made this one in September 2023. It uses 2 RP2040s, with one replacing the 595 IO expanders. There is also a follow along logic analyzer, which is run in the second 2040. There was some weird splitting of the display and analog side from the main terminal chip.
I did not write firmware for this one though. The changes were so drastic that I couldn’t find the motivation to sit down and do it. I am much more likely to complete a project if I take small incremental steps.
This was interesting. I made REV1 with the SMPS and REV2 with the LDO at the same time. I was concerned the SMPS wouldn’t pass FCC/CE and I only had six weeks from NDA read in to shipping assembled and certified hardware.
In the end both passed, but 1. the SMPS components cost more than the LDO, and 2. it takes up more board space at a really critical location. Since we are not optimizing for power consumption the LDO was the better choice.
The other thing about this, and I could be mistaken, is that the magic inductor choice was unceremoniously changed at least once. Having already done FCC/CE testing, I decided to avoid that whole situation.
The PCAL6524 has optional built-in debouncing (if you apply a clock of a couple kHz to P0_0), in case that sounds desirable!
Wow, what an interesting chip!
I2C IO expander pricing:
| Part Number | Quantity | Unit Price | Full Reel Quantity | Reel Unit Price |
|---|---|---|---|---|
| PI4IOE5V9535ZDEX | 100 | 2.5元 | 3500 | 2.3元 |
| TCA9555RTWR | 100 | 2.8元 | 3000 | 2.6元 |
| XL9555QF24 | 100 | 2.2元 | 3000 |
Double sided board assembly: startup price is double normal startup price. Our current factory does not support red glue (surface tension only).
Thanks for the pointer.
It looks like it is one of the fancy GPIO expanders. It also has fully integrated pullups and pulldowns with 100k.
Unfortunately it seems they didn’t go all the way with the debouncing, but wanted to avoid integrating an RC-oscillator at all costs. Don’t know their reasoning why. But now you can’t just program the debouncing time into a register, but have to supply an external clock for it. For the BusPirate with just one button for now this defeats the whole purpose of using an GPIO expander - we’d either need one pin from the RP2350 or an extra oscillator. This would only make sense when we have several buttons.
Also I guess this chip will be quite expensive in comparison to the Diodes one that is planned now.
