ChatGPT, The Worst Summer Intern Ever

July 26, 2023 by Dan Maloney 71 Comments

Back when I used to work in the pharma industry, I had the opportunity to hire summer interns. This was a long time ago, long enough that the fresh-faced college students who applied for the gig are probably now creeping up to retirement age. The idea, as I understood it, was to get someone to help me with my project, which at the time was standing up a distributed data capture system with a large number of nodes all running custom software that I wrote, reporting back to a central server running more of my code. It was more work than I could manage on my own, so management thought they’d take mercy on me and get me some help.

The experience didn’t turn out quite like I expected. The interns were both great kids, very smart, and I learned a lot from them. But two months is a very tight timeframe, and getting them up to speed took up most of that time. Add in the fact that they were expected to do a presentation on their specific project at the end of the summer, and the whole thing ended up being a lot more work for me than if I had just done the whole project myself.

I thought about my brief experience with interns recently with a project I needed a little help on. It’s nothing that hiring anyone would make sense to do, but still, having someone to outsource specific jobs to would be a blessing, especially now that it’s summer and there’s so much else to do. But this is the future, and the expertise and the combined wisdom of the Internet are but a few keystrokes away, right? Well, maybe, but as you’ll see, even the power of large language models has its limit, and trying to loop ChatGPT in as a low-effort summer intern leaves a lot to be desired.

Continue reading “ChatGPT, The Worst Summer Intern Ever” →

PCIe For Hackers: Our M.2 Card Is Done

July 25, 2023 by Arya Voronova 18 Comments

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

July 24, 2023 by Arya Voronova 11 Comments

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” →

Ask Hackaday: What’s Linux Anyway?

July 21, 2023 by Al Williams 55 Comments

Any time we mention Linux, it is a fair bet we will get a few comments from people unhappy that we didn’t refer to it as GNU/Linux or with some other appellation. To be fair, they aren’t wrong. Linux is a kernel. Much of what we think of as a Linux desktop OS is really from other sources, including, but not limited to, GNU. We thought about this after reading a report from [The Register] that Linux has nearly half of the desktop OS Linux market. Wait, what?

If you are like us, you probably think that’s a typo. It isn’t. But the more you think about it, the less sense it makes. You know that half of the world’s desktops don’t run Linux. But maybe they mean Unix? Nope. So how can Linux have almost half of the Linux market? That’s like saying nearly half of Hackaday readers read Hackaday, right?

Continue reading “Ask Hackaday: What’s Linux Anyway?” →

PCIe For Hackers: An M.2 Card Journey

July 20, 2023 by Arya Voronova 22 Comments

I’ve designed a few M.2 adapters for my own and my friends’ use, and having found those designs online, people have asked me for custom-made adapters. One of these requests is quite specific – an adapter that adds one more PCIe link to an E-key M.2 slot, the kind of slot you will see used in laptops for WiFi cards.

See, the M.2 specification allows two separate PCIe links connected to the E-key slot; however, no WiFi cards use this apart from some really old WiGig-capable ones, and manufacturers have long given up on connecting a second link. Nevertheless, there are some cards like the Google Coral M.2 E-key dual AI accelerator and the recently announced uSDR, that do indeed require the second link – otherwise, only half of their capacity is available.

It’s not clear why both Google and WaveletSDR designed for a dual-link E-key socket, since those are a rare occurrence; for the Google card, there are plenty of people complaining that the board they bought just doesn’t fully work. In theory, all you need to do to help such a situation, is getting a second PCIe link from somewhere, then wiring it up to the socket – and a perfect way to do it is to get a PCIe switch chip. You will lose out on some bandwidth because the uplink PCIe connection of the switch can only go so fast; for things like this AI accelerator, it’s not much of a problem since the main point is to get the second device accessible. For the aforementioned SDR, it might turn out useless, or you might win some but lose some – can’t know until you try! Continue reading “PCIe For Hackers: An M.2 Card Journey” →

Smart Assistants Need To Get Smarter

July 19, 2023 by Lewin Day 81 Comments

Science fiction has regularly portrayed smart computer assistants in a fanciful way. HAL from 2001: A Space Odyssey and J.A.R.V.I.S. from the contemporary Iron Man films are both great examples. They’re erudite, wise, and capable of doing just about any reasonable task that is asked of them, short of opening the pod bay doors.

Cut back to reality, and you’ll only be disappointed at how useless most voice assistants are. It’s been twelve long years since Siri burst onto the scene, with Alexa and Google Assistant following years later. Despite years on the market, their capabilities remain limited and uninspiring. It’s time for voice assistants to level up.

Continue reading “Smart Assistants Need To Get Smarter” →

DisplayPort: Under The Hood

July 17, 2023 by Arya Voronova 14 Comments

Last time, we looked at all the things that make DisplayPort unique for its users. What about the things that make it unique for hackers? Let’s get into all the ways that DisplayPort can serve you on your modern tech wrangling adventures.

You Are Watching The AUX Channel

With DisplayPort, the I2C bus we’ve always seen come bundled with VGA, DVI and HDMI, is no more – it’s been replaced by the AUX bus. AUX is a 1 MHz bidirectional diffpair – just a bit too complex for a cheap logic analyzer, though, possibly, something you could wrangle with the RP2040’s PIOs. Hacking thoughts aside, it’s a transparent replacement for I2C, so that software doesn’t have to be rewritten – for instance, it usually does I2C device passthrough over AUX, so that EDID data can still be stored in a separate EEPROM chip on the monitor or eDP LCD panel.

AUX isn’t just a differential bus, it’s more pseudodifferential, like USB2 – for instance, AUX_P and AUX_N are used separately, with a combination of 1 MΩ and 100 kΩ pullups and pulldowns signaling different states of the physical connection – for instance, a pullup on AUX+ and a pulldown on AUX- means that an external device has been connected. If you’d like to learn which combination of resistors means what, you can find in the DisplayPort specification, which isn’t distributed openly but isn’t hard to come by, either.

Also, DisplayPort link training happens over AUX, and in order to facilitate that, a piece of DisplayPort controller’s external memory is usually exposed over the AUX channel, through a mechanism that’s called DPCD. If you dig a bit, using “DPCD” as the keyword, you can easily reach into the lower-level details of your DisplayPort connection. Some of the DPCD memory map is static, and some parts are FIFOs you can funnel data into, or out of. You can find a wide variety of documents online which describe the DPCD structure – for now, here’s a piece of Bash that works on Linux graphics drivers for AMD and Intel, and will show you you the first 16 bytes of DPCD:

# sudo dd if=/dev/drm_dp_aux0 bs=1 skip=256 count=16 |xxd 00000000: 0084 0000 0000 0000 0108 0000 0000 0000 ................ [...]

In particular, the 4th nibble (digit) here describes the amount of lanes for the DisplayPort link established – as you can see, my laptop uses a four-lane link. Also, the /dev/drm_dp_aux0 path might need to be adjusted for your device. In case you ever want to debug your DP link, having direct access to the DPCD memory space like this might help you quite a bit! For now, let’s move onto other practical aspects. Continue reading “DisplayPort: Under The Hood” →