Homebrew Network Card With No CPU

A modern normal network card will have onboard an Ethernet controller which, of course, is a pre-programmed microcontroller. Not only does it do the things required to keep a computer on the network, it can even save the primary CPU from having to do certain common tasks required for communicating. But not [Ivan’s]. His homebrew computer — comprised of 7 colorful PCBs — now has an eighth card. You guessed it. That card connects to 10BASE-T Ethernet.

There’s not a microcontroller in sight, although there are RAM chips. Everything else is logic gates, flip flops, and counters. There are a few other function chips, but nothing too large. Does it work? Yes. Is it fast? Um…well, no.

The complete computer.

He can ping others on the network with an 85 ms round trip and serve web pages from his homebrew computer at about 2.6 kB/s. But speed wasn’t the goal here and the end result is quite impressive. He even ported a C compiler to his CPU so he could compile uIP, a networking stack, avoiding the problems of writing his own from scratch.

Some compromises had to be made. The host computer has to do things you normally expect a network card to do. The MTU is 1024 bytes (instead of the more common 1500 bytes, but TCP/IP is made to expect different MTU sizes, which used to be more common when more network interfaces looked like this one).

Even on an FPGA, these days, you are more likely to grab some “IP” to do your Ethernet controller. Rolling your own from general logic is amazing, and — honestly — the design is simpler than we would have guessed. If you check out [Ivan]’s blog, you can find articles on the CPU design, its ALU, and even a VGA video card all from discrete logic. The whole design, including the network card is up on GitHub.

We love the idea of building a whole computer system soup to nuts. We wish we had the time. If you need a refresher on what’s really happening with Ethernet, our [Arya Voronova] can help.

How DEC’s LANBridge 100 Gave Ethernet A Fighting Chance

Alan Kirby (left) and Mark Kempf with the LANBridge 100, serial number 0001. (Credit: Alan Kirby)
Alan Kirby (left) and Mark Kempf with the LANBridge 100, serial number 0001. (Credit: Alan Kirby)

When Ethernet was originally envisioned, it would use a common, shared medium (the ‘Ether’ part), with transmitting and collision resolution handled by the carrier sense multiple access with collision detection (CSMA/CD) method. While effective and cheap, this limited Ethernet to a 1.5 km cable run and 10 Mb/s transfer rate. As [Alan Kirby] worked at Digital Equipment Corp. (DEC) in the 1980s and 1990s, he saw how competing network technologies including Fiber Distributed Data Interface (FDDI) – that DEC also worked on – threatened to extinguish Ethernet despite these alternatives being more expensive. The solution here would be store-and-forward switching, [Alan] figured.

After teaming up with Mark Kempf, both engineers managed to convince DEC management to give them a chance to develop such a switch for Ethernet, which turned into the LANBridge 100. As a so-called ‘learning bridge’, it operated on Layer 2 of the network stack, learning the MAC addresses of the connected systems and forwarding only those packets that were relevant for the other network. This instantly prevented collisions between thus connected networks, allowed for long (fiber) runs between bridges and would be the beginning of the transformation of Ethernet as a shared medium (like WiFi today) into a star topology network, with each connected system getting its very own Ethernet cable to a dedicated switch port.

On Cloud Computing And Learning To Say No

Do you really need that cloud hosting package? If you’re just running a website — no matter whether large or very large — you probably don’t and should settle for basic hosting. This is the point that [Thomas Millar] argues, taking the reader through an example of a big site like Business Insider, and their realistic bandwidth needs.

From a few stories on Business Insider the HTML itself comes down to about 75 kB compressed, so for their approximately 200 million visitors a month they’d churn through 30 TB of bandwidth for the HTML assuming two articles read per visitor.

This comes down to 11 MB/s of HTML, which can be generated dynamically even with slow interpreted languages, or as [Thomas] says would allow for the world’s websites to be hosted on a system featuring single 192 core AMD Zen 5-based server CPU. So what’s the added value here? The reduction in latency and of course increased redundancy from having the site served from 2-3 locations around the globe. Rather than falling in the trap of ‘edge cloud hosting’ and the latency of inter-datacenter calls, databases should be ideally located on the same physical hardware and synchronized between datacenters.

In this scenario [Thomas] also sees no need for Docker, scaling solutions and virtualization, massively cutting down on costs and complexity. For those among us who run large websites (in the cloud or not), do you agree or disagree with this notion? Feel free to touch off in the comments.

SatCat5: UART, SPI And I2C Via Ethernet With FPGA-Based Design

Arty A7-based prototype of SatCat5 with custom switch I/O board. (Credit: The Aerospace Corporation)
Arty A7-based prototype of SatCat5 with custom switch I/O board. (Credit: The Aerospace Corporation)

To the average microcontroller, Ethernet networks are quite a step up from the basic I2C, SPI and UART interfaces, requiring either a built-in Ethernet MAC or SPI-based MAC, with tedious translation between Ethernet and those other interfaces. Yet what if this translation could be done automatically and transparently?  This is what the SatCat5 FPGA-based project by [The Aerospace Corporation] aims to provide: a gateway akin to an unmanaged Ethernet switch that also supports those non-Ethernet links. Recently they answered a range of questions about the project on Hacker News.

The project name comes from the primary target audience: smallsat and cubesat developers, which is an area where being able to route more traffic over a common Ethernet-based bus is a major boon. The provided Xilinx Artix-7-based reference design (pictured) gives a good idea of how it can be used: it combines an Arty A7 development board with a custom PCB containing an Ethernet switch IC (SJA1105), TJA1100 transceiver, two RJ45 jacks and four PMOD connectors, here connected to two UARTs for bidirectional communication between them. Ethernet frame encapsulation is provided using the standard Serial Line Internet Protocol (SLIP), with more details covered in the FAQ. At a minimum an FPGA like a Lattice iCE40 is required, with an MCU capable of using the provided C++ libraries, or a custom implementation.

Thanks to [STR-Alorman] for the tip.

Ethernet For Hackers: Transformers, MACs And PHYs

We’ve talked about Ethernet basics, and we’ve talked about equipment you will find with Ethernet. However, that’s obviously not all – you also need to know how to add Ethernet to your board and to your microcontroller. Such low-level details are harder to learn casually than the things we talked about previously, but today, we’re going to pick up the slack.

You might also have some very fair questions. What are the black blocks near Ethernet sockets that you generally will see on boards, and why do they look like nothing else you see on circuit boards ever? Why do some boards, like the Raspberry Pi, lack them altogether? What kind of chip do you need if you want to add Ethernet support to a microcontroller, and what might you need if your microcontroller claims to support Ethernet? Let’s talk.

Transformers Make The Data World Turn

One of the Ethernet’s many features is that it’s resilient, and easy to throw around. It’s also galvanically isolated, which means  you don’t need a ground connection for a link either – not until you want a shield due to imposed interference, at which point, it might be that you’re pulling cable inside industrial machinery. There are a few tricks to Ethernet, and one such fundamental Ethernet trick is transformers, known as “magnetics” in Ethernet context.

Each pair has to be put through a transformer for the Ethernet port to work properly, as a rule. That’s the black epoxy-covered block you will inevitably see near an Ethernet port in your device. There are two places on the board as far as Ethernet goes – before the transformer, and after the transformer, and they’re treated differently. After the transformer, Ethernet is significantly more resilient to things like ground potential differences, which is how you can wire up two random computers with Ethernet and not even think about things like common mode bias or ground loops, things we must account for in audio, or digital interfaces that haven’t yet gone optical somehow.

Continue reading “Ethernet For Hackers: Transformers, MACs And PHYs”

Dial-Up Is Still, Just Barely, A Thing

In an era dominated by broadband and wireless cellular networks, it might come as a surprise to many that dial-up internet services still exist in the United States. This persistence is not a mere relic of nostalgia — but a testament to the diverse and uneven nature of internet infrastructure across the country.

Yes, dial-up internet, with those screechy, crackly tones, remains a useful tool in areas where modern, high-speed internet services are either unaffordable or unavailable. Subscriber numbers are tiny, but some plough on and access the Internet by the old ways, not the new.

Continue reading “Dial-Up Is Still, Just Barely, A Thing”

Pictures of the internals of the Starlink adapter

Restoring Starlink’s Missing Ethernet Ports

Internet connectivity in remote areas can be a challenge, but recently SpaceX’s Starlink has emerged as a viable solution for many spots on the globe — including the Ukrainian frontlines. Unfortunately, in 2021 Starlink released a new version of their hardware, cost-optimized to the point of losing some nice features such as the built-in Ethernet RJ45 (8P8C) port, and their proposed workaround has some fundamental problems to it. [Oleg Kutkov], known for fixing Starlink terminals in wartime conditions, has released three posts on investigating those problems and, in the end, bringing the RJ45 ports back.

Starlink now uses an SPX connector with a proprietary pinout that carries two Ethernet connections at once: one to the Dishy uplink, and another one for LAN, with only the Dishy uplink being used by default. If you want LAN Ethernet connectivity, they’d like you to buy an adapter that plugs in the middle of the Dishy-router connection. Not only is the adapter requirement a bother, especially in a country where shipping is impeded, the SPX connector is also seriously fragile and prone to a few disastrous failure modes, from moisture sensitivity to straight up bad factory soldering.

Continue reading “Restoring Starlink’s Missing Ethernet Ports”