Could you explain this? I’m not seeing how having one or twenty 595s in a chain requires extra pins per chip. Am I missing something (I only skimmed through the discussion above, so that’s very likely)?
Speaking of the 595s, one thing I noticed is that you don’t loop back the shift register(s) output back into SPI input pin. I scratched my head for a few minutes on this, and came to the conclusion that it you’d have to worry about the 595 MSB output clobbering the NAND flash SPI output. Also, there is very little gain in doing this, as it only eliminates the need to maintain a shadow register of the SR contents.
Perhaps Ian was simply saying I2C don’t require an extra pin per device, and can have many disparate type of devices on that bus.
In contrast, while you can chain many 595s, you’re limited to shift register style chips … you could not also use such a pin for a temperature sensor, for example.
For any readers who may not be as familiar, I2C devices each have an address, which is part of the communication protocol. You can find (non-exhaustive) list of common device addresses. Being an addressed protocol allows many devices on a single bus (and thus saves pins on the mcu).
Disappointing news on the Bus Pirate 6 assembly. We had it lined up to so we could ship them to you the day before the 7 day National holiday. Unfortunately a problem delayed production by a day. They won’t arrive at our office until after the logistics company stops working.
They will ship immediately after the holiday around October 9. We are really sorry for the delay, it’s really annoying to hit a problem like this right before an extended holiday.
Here you can see the issue with the PCBs. The LED holes are too small, and the up-facing LEDs don’t fit in some (but not all) of the panels. We don’t have to remake the boards, the PCB factory just milled the holes a bit bigger for us. It is a day delay though, which means we won’t manage to ship before the holiday.
This isn’t the first time we’ve run into issues with this LED footprint. Other batches of boards have been a little too tight, but nothing like this. We got the “official” datasheet for the exact LED used and will have a professional make a new footprint.
could this be an issue with routing precision at the pcb fab?
I know from other fabs that you usually have to pay extra to get higher precision routing.
Some of the photos I’ve seen in the fix-my-six thread show some holes that have quite some drill offset, like for example here:
This leads me to believe you are using a cost-optimized fab. If they have a similar precision for routing, this could explain the problem and your footprint could be fine. So optimizing the footprint would be mostly about dealing with the exact routing tolerances of your fab and their process. In this case i’m not sure if it isn’t best done by an engineer of your pcb fab itself, because they know their process best.
Sorry for the delay in replying. One example of use would be to inject a serial stream INTO a serial enabled LCD such as this
Without having to write firmware into a PIC microcontroller and have IT send serial data to the LCD. If I could just type text at a Bus Pirate command line on my laptop, and it would send the text to the LCD that would be great. Or maybe send a SERIES of text streams to the LCD. I need this as I’m trying to develop a custom version of the LCD for educational use. The sparkfun LCD is no longer available.
I spoke poorly Treating the 595 as an SPI device, it requires an extra MCU GPIO pin. While with the I2C bus we can use IO expanders and other devices on the same bus without consuming more a MCU GPIO pin per additional chip (for the CS pin).
Just in general I’m not a fan of the 595 approach because it takes a lot of board real estate, complicates routing of the “high speed” internal SPI bus, and is just generally kind of wonky to deal with in code. Scheduling simple pin operations like enabling the power supply/changing analog mux channel amongst display updates and NAND access just feels kind of dirty to me.
It felt triumphant to #ifdef that all way when porting to the RP2350B chip
This. In the past we warned them and they opened it up a bit. We’ve had the same issue with three fabs ranging from dirty cheap (JLC protopacks) to standard (Dirty fab) to super high end (the “northern China fab” we call it, they do aerospace and custom color stuff).
The current boards are from the Dirty fab. They’ve done several big batches of BP5 without major issues. They also did the 5XL and 6 initial batches of 100 without issue. I suspect an engineer didn’t tweak it properly this time. “Something happened” and nobody is ever going to tell me, so the best I can do is try to prevent “something” from happening again from our side.
We’re going to double check the footprint to start, then get feedback from the fab about how much tolerance to add ourselves to ensure problem free assembly going forward.
Just a quick update: the Shenzhen office is back at work, we want to get replacement boards and back orders out ASAP.
We’re spot testing Bus Pirate 6c boards with the bug -e9 command, in addition to the full self test. So far everything looks good. The resistor change will fix it, but we just want to check for corner cases or other issues.
@jin requests that if you have moved or changed address since ordering, please open a support ticket with your new address.
I had a question, but not sure if Ticket would be better. I got one of the first batch BP6, so when the replacement gets shipped, is there a way I can order/buy the RS232 plank and serial survival pack, and have it thrown in to save on shipping? If not, I understand, I’m sure you guys are swamped and I would not want to add more confusion to your plates!
Hey @detonation - It is probably best to place a separate order to avoid problems. Shipping the replacements will be a big bulk effort and we want to get it done as quickly as possible.
Treating the 595 as an SPI device, it requires an extra MCU GPIO pin. While with the I2C bus we can use IO expanders and other devices on the same bus without consuming more a MCU GPIO pin per additional chip (for the CS pin).