Logic Analyzers: Capabilities And Limitations

Last time, we’ve used a logic analyzer to investigate the ID_SD and ID_SC pins on a Raspberry Pi, which turned out to be regular I2C, and then we hacked hotplug into the Raspberry Pi camera code with an external MCU. Such an exercise makes logic analyzers look easy, and that’s because they are! If you have a logic analyzer, you’ll find that a whole bunch of hacks become available to you.

In this article, let’s figure out places where you can use a logic analyzer, and places where you can’t. We’ll start with the first limitation of logic analyzers – capture speed. For instance, here’s a cool thing you can buy on Aliexpress – a wristband from TTGO that looks like a usual fitness tracker, but has an ESP32 in it, together with an IMU, an RTC, and an IPS screen! The seller also has an FFC-connectable devboard for programming this wristband over UART, plus vibromotor and heartrate sensor expansion modules.

You can run C, MicroPython, Rust, JavaScript, or whatever else – just remember to bring your own power saving, because the battery is super small. I intended to run MicroPython on it, however, and have stumbled upon a problem – the ST7735-controller display just wouldn’t work with the st7735.py library I found; my image would be misaligned and inverted.

The specifications didn’t provide much other than “ST7735, 80×160”. Recap – the original code uses an Arduino (C++) ST7735 library and works well, and we have a MicroPython ST7735 library that doesn’t. In addition to that, I was having trouble getting a generic Arduino ST7735 library to work, too. Usually, such a problem is caused by the initialization commands being slightly different, and the reason for that is simple – ST7735 is just the name of the controller IC used on the LCD panel.

Each display in existence has specifics that go beyond the controller – the pixels of the panel could be wired up to the controller in a bunch of different ways, with varying offsets and connection types, and the panel might need different LCD charge pump requirements – say, depending on the panel’s properties, you might need to write 0x10 into a certain register of the ST7735, or you will need 0x40. Get one or more of these registers wrong, and you’ll end up with a misaligned image on your display at best, or no output at worst. Continue reading “Logic Analyzers: Capabilities And Limitations”

Copper Be Gone: The Chemistry Behind PCB Etching

For a lot of reasons, home etching of PCBs is somewhat of a dying art. The main reason is the rise of quick-turn PCB fabrication services, of course; when you can send your Gerbers off and receive back a box with a dozen or so professionally made PCBs for a couple of bucks, why would you want to mess with etching your own?

Convenience and cost aside, there are a ton of valid reasons to spin up your own boards, ranging from not having to wait for shipping to just wanting to control the process yourself. Whichever camp you’re in, though, it pays to know what’s going on when your plain copper-clad board, adorned with your precious artwork, slips into the etching tank and becomes a printed circuit board. What exactly is going on in there to remove the copper? And how does the etching method affect the final product? Let’s take a look at a few of the more popular etching methods to understand the chemistry behind your boards.

Continue reading “Copper Be Gone: The Chemistry Behind PCB Etching”

Share Your Projects: Leave Breadcrumbs

I’ve talked about a low-effort way to document your projects by taking plenty of pictures, and about ways that your PCBs could be documenting themselves. Today, let’s talk about a quick and easy way that you could help other hackers as you go through your own hacking adventures — leaving breadcrumbs.

In short, breadcrumbs are little pieces of crucial information that you had to spend time to figure out. They are solutions to problems that another hacker just like you could stumble upon in the future, something that you perhaps wish you didn’t have to figure out on your own, and certainly something that others won’t need to spend time figuring out.

Breadcrumbs are about saving time, for you and others. It helps if you think of your solved problems in terms of time spent. If you figure out a small problem and then publish your solution, you might be saving half an hour, a full hour, or a good few hours of time another hacker that’s could even be less experienced in debugging than you. In fact, your breadcrumb might even make a difference between someone completing a project and abandoning it!

However, there’s also the trade-off of taking time to document something. If you can’t publish your solution in a few minutes’ time, it might become much harder to persuade your brain to publish the next time you have something notable. Here’s a guideline: if you’ve just figured out a cool terminal command that helps you solve a certain kind of problem, you should have a quick way to publish that command within a minute. The good news is, the internet has a hundred different places you could easily share your findings, depending on the kind of problem you’ve solved! Continue reading “Share Your Projects: Leave Breadcrumbs”

All About USB-C: Example Circuits

In the six months that have passed after the last USB-C article has been released, I have thought up a bunch of ways that these articles could have been improved. It’s, of course, normal to have such a feeling — expected, even. I now believe that there’s a few gaps that I could bridge. For instance, I have not provided enough example circuits, and sometimes one schematic can convey things better than a thousand words.

Let’s fix that! I’ll give you schematics for the kinds of USB-C devices you’re actually likely to want to build. I’ll also share a bunch of IC part numbers in this article, but I don’t have an exhaustive collection, of course – if you find more cool ICs that work for USB-C purposes and aren’t mentioned here, please do let us all know in the comments!

Continue reading “All About USB-C: Example Circuits”

DisplayPort: Taming The Altmode

The DisplayPort altmode is semi-proprietary, but it can absolutely be picked apart if we try. Last time, we found a cool appnote describing the DisplayPort altmode in detail, switched the FUSB302 into packet sniffing mode and got packet captures, learned about PD VDMs (vendor-defined messages), and successfully replayed the captured messages to switch a USB-C port into the DisplayPort altmode. Today, we will go through the seven messages that summon the DisplayPort altmode, implement them, and tie them all into a library – then, figure out the hardware we need to have DisplayPort work in the wild.

For a start, as you might have seen from the diagram, a single command can be either a request or a response. For instance, if you get a Discover Identity REQ (request), you reply to it with a Discover Identity ACK (response), adding your identity data to your response along the way. With some commands, the DP source will add some data for you to use; for most commands, your DP sink will have to provide information instead – and we’ll do just that, armed with the PDF provided and the packet captures.

We have seven commands we need to handle in order to get DisplayPort out of a compatible USB-C port – if you need a refresher on these commands, page 13 of the ST’s PDF on the DP altmode will show you the message sequence. These commands are: Discover Identity, Discover SVIDs, Discover Modes, Enter Mode, DP Status Update, DP Configure, and Attention. Out of these, the first four are already partially described in the base USB PD standard, the two DP commands afterwards are DisplayPort-altmode-specific but sufficiently described in the PDF we have, and the Attention command is from the base standard as well, mostly helpful for reporting state of the HPD pin. Let’s start with the first two! Continue reading “DisplayPort: Taming The Altmode”

PCIe For Hackers: Our M.2 Card Is Done

We’ve started designing a PCIe card last week, an adapter from M.2 E-key to E-key, that adds an extra link to the E-key slot it carries – useful for fully utilizing a few rare but fancy E-key cards. By now, the schematic is done, the component placement has been figured out, and we only need to route the differential pairs – should be simple, right? Buckle up.

Getting Diffpairs Done

PCIe needs TX pairs connected to RX on another end, like UART – and this is non-negotiable. Connectors will use host-side naming, and vice-versa. As the diagram demonstrates, we connect the socket’s TX to chip’s RX and vice-versa; if we ever get confused, the laptop schematic is there to help us make things clear. To sum up, we only need to flip the names on the link coming to the PCIe switch, since the PCIe switch acts as a device on the card; the two links from the switch go to the E-key socket, and for that socket’s purposes, the PCIe switch acts as a host.

While initially routing this board, I absolutely forgot about one more important thing for PCIe – series capacitors on every data pair, on the host TX side of the link. We need three capacitor pairs here – on TX of the PCIe switch uplink, and two pairs on TX side of the switch – again, naming is host-side. I only remembered this after having finished routing all the diffpairs, and, after a bit of deliberation, I decided that this is my chance to try 0201 capacitors. For that, I took the footprints from [Christoph]‘s wonderful project, called “Effect of moon phase on tombstoning” – with such a name, these footprints have got to be good.

We’ve talked about differential pair calculations before in one of the PCIe articles, and there was a demo video too! That said, let’s repeat the calculations on this one – I’ll show how to get from “PCB fab website information” to “proper width and clearance diffpairs”, with a few fun shortcuts. Our setup is, once again, having signals on outer layers, referenced to the ground layer right below them. I, sadly, don’t yet understand how to calculate differential impedance for signal layers sandwiched between two ground planes, which is to say – if there’s any commenters willing to share this knowledge, I’d appreciate your input tremendously! For now, I don’t see that there’d be a tangible benefit to such an arrangement, anyway.

Continue reading “PCIe For Hackers: Our M.2 Card Is Done”

DisplayPort: Tapping The Altmode

Really, the most modern implementation of DisplayPort is the USB-C DisplayPort altmode, synonymous with “video over USB-C”, and we’d miss out if I were to skip it. Incidentally, our last two articles about talking USB-PD have given a few people a cool new toy to play with – people have commented on the articles, reached out to me for debugging help, and I’ve even seen people build the FUSB302B into their projects! Hot on the heels of that achievement, let’s reach further and conquer one more USB-C feature – one that isn’t yet openly available for us to hack on, even though it deserves to be.

For our long-time readers, it’s no surprise to see mundane capabilities denied to hackers. By now, we all know that many laptops and phones let you get a DisplayPort connection out of a USB-C port. Given that the USB-C specifications are openly available, and we’ve previously implemented a PD sink using those specifications, you’d expect that we could do DisplayPort with the same ease. Yet, the DisplayPort altmode specification is behind a VESA membership paywall, with a hefty pricetag – a practice of theirs that has been widely criticized, counter to their purpose as a standards organization and having resulted in some of their standards failing.

Not to worry, however – we can easily find an assortment of PDFs giving a high-level overview and some details of the DisplayPort altmode, and here’s my favorite! I also have a device running MicroPython with a FUSB302 chip connected, and a few DisplayPort altmode devices of mine that I can disassemble. This, turns out, is more than enough for us to reverse-engineer our way into an open-source DisplayPort altmode library!

Continue reading “DisplayPort: Tapping The Altmode”