Electronic – Ethernet: Why is the link status “down” when there is a speed mismatch

The basic answer is that you can do whatever communication you want to do.

Every chip which has an ethernet component to it can do simple phy-to-phy communication (i.e. layer 1 if we're talking about the OSI model), and unless your chip has a built-in IP stack or AX.25 layer or some other type of level-2/3 (i.e. data/network abstraction) layer baked into the silicon, this is what you will have to use.

The hardware is capable of doing some part of the ethernet protocol, whether this is 10BASE-T, 100BASE-T or whatever, and if you add an IP-layer your software stack will utilize that functionality. You can use that functionality directly!

Most people choose to put some sort of IP layer with TCP or UDP communications because this helps hide some of the complexity, and makes the code work the same way on their computer as it does on the chip. It also means that things like putting an ethernet switch in the middle of multiple circuits will work, and many other niceties that comes with using a professionally developed standard that a lot of people have thought about and tested. You don't have to do this if you don't want to, and it will save you a lot of complexity and processing power if all you're doing is sending simpled sequential messages from one circuit to another though.

I agree with @Spoon though, in that I think you should pick a different protocol if you're using simple point-to-point communication. If there a reason you're not using RS-485, RS-232, I²C, or some similar simple serial protocol? A lot of those will likely be easier than using ethernet.

Good luck!

Beginning from 10BASE-T, there is no CDMA/CD in Ethernet because (and while) the underlaying PMA/PMD provides the PCS (providing the service interface for the MAC) with a full duplex data transmission mechanism. In 10BASE-T, 100BASE-TX, 1000BASE-X, 1000BASE-T, etc., the half duplex mode of operation, i.e. providing CRS and CD signals by the PHY to its MAC, is speculatively simulated in the PHY by itself like the following:

• carrier sense := rx activity or tx activity
• collision detect := rx activity and tx activity

(Be careful here and remember that rx activity as well as tx activity are on the medium side while carrier sense is on the PHY service interface, i.e. MAC, side.)

Returning to your counters, they (could) show how the actions over the PHY (being taken by the MAC serviced) correlate/correspond with the actions under the PHY (happening at the medium) and may (could) be like the following:

• lost carrier counter increments when carrier sense transits from HIGH to LOW while TX_EN is HIGH (generally speaking, it's implementation dependent and could be sole TX_EN, sole RX_DV, or combination thereof)

• no carrier counter increments when TX_EN transits from LOW to HIGH while carrier sense is LOW (it's also implementation dependent and could be other any)

In other words, the first counter indicates how many times the link fails while a packet was transmitted and/or received---collectively, presented---at the medium, and the second counter indicates how many times the MAC attempts to send a packet while there was no physical link.

An yes, in 10BASE-T (and in EEE today) FLPs are generated while the medium is idle, but this is not the case as it is shown above.