Transformerless ethernet or ethernet over a software transformer


tl;dr I'm curious whether or not it's plausible to work out an extremely basic 10BASE-T implementation, and what would be required to do so. I've looked up many spec sheets and found some information on how ethernet adapters work, and some whitesheets on transformerless ethernet, but my question to you is whether or not is is plausible.

Namely, what is the bare minimum you think would be needed to connect via ethernet with an Arduino. I have wired up a simple RJ45 port to a breadboard, and poked around with that on the Arduino, but, of course, nothing comes of it, likely because I didn't initiate a handshake. From research I know that I'd likely be working with Manchester Encoding for 10BASE-T.

Is a software transformer even viable? That is to say, is it possible to achieve a connection using just the RJ45 port and Arduino, and doing all the mucking around on the software side? I do have an ethernet adapter for my Arduino, so this isn't a means to connect for things like that. It's purely for education.

It should be possible to get rid of the transformer but to me it seems like a very bad idea.
The transformer provides both balanced transmission and gavlvanic insulation.

Right, and because of that I actually considered making a transformer with parts on the breadboard. Though, I wasn't able to find a whole lot of information specific to ethernet pulse transformers, there were a few whitesheets. I'm guessing without the transformer there'd be a good risk of damaging either the Arduino pins or possible the router/hub.

Hm, with a 20MHz crystal to clock the CPU, the Arduino could probably just barely manage to send data at 10MHz for short bursts. Receiving is more complicated:

I'm guessing you're going to need some kind of external IC to recover the clock so the synchronous USART (which requires a separate clock pin) can receive the data.

Ethernet recovers the clock from the data signal. That's why the signals are Manchester encoded - it guarantees transitions even when there are long strings of "0's". It also does 4B/5B encoding. Ethernet frames can be very long so that ordinary baud rate solutions don't work. Read IEEE 802.3. What you really are proposing is to design your own PHY and LLC.

Thanks for the links tylernt, those are pretty useful information.

I have the entire IEEE 802.3 specsheet, and it's quite a read. OCing my Mega2560 to 20MHz would likely cause it to overheat, I would think. I'm guessing a separate circuit for this would work well.. but at that point, it would be much easier to just drop in a PHY IC to do the work. From all this information, it certainly looks plausible. The efficiency is what worries me a bit, since IEEE 802.3 seems to be rather strict. I'm not sure if the Arduino will be able to handle a lot of data without starting to drop packets.

Ethernet is strict. One data error and you drop the frame, requiring re-transmission.

You want more than just the PHY prepackaged. You need the buffering and TCP/IP stuff too. Ethernet comes with overhead like preamble, IP addresses, MAC addresses, frame type, CRC, padding and so on. You don't want the Arduino to deal with that, right? You just want to send data and get some back without dealing with the overhead. An Ethernet shield is available for around $10 and sounds like a bargain to me. (I designed Ethernet Switches and Repeaters in a previous life and I would just get a shield.)

Yes, I'm aware of ethernet shields, and I actually have a basic one that allows me to do all of that. This is merely a personal project, but I do understand that it's not very viable or probable. I was just interested in how viable is actually was. With the information I've accumulated, I can see that it can be done, it just won't work very well. I suppose I'll decide whether or not to pursue it at a later date.

Thanks for the help and insight.

The other feature of IEEE 802.3 is that it's a shared medium. Multiple devices can use a single Ethernet segment which can be extended with bridges. You lose that feature when you go digital. There are better protocol choices for point-to-point digital communication.

20MHz is not overclocking for an ATmega chip, they're rated for 20MHz.

20MHz is not overclocking for an ATmega chip, they're rated for 20MHz.

Is it? The specsheet I have for the ATmega2560 lists the max frequency as 16MHz, so I assumed anything over that would cause overheating. I've looked at a few different datasheets and they all advise against clocking over 16MHz for this particular chip to stay in the correct temp ranges. Of course, I could always throw on a heatsink and fan :wink:

Hm, looks like the ATmega328 and ATmega1284 chips come in 16MHz and 20MHz flavors, but the poor ATmega2560 is a 16MHz-only part. Sorry.