Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 3 of 3

Thread: Using the PHY/MAC as a physical layer for RS422-type traffic

  1. #1
    Junior Member
    Join Date
    Feb 2021

    Using the PHY/MAC as a physical layer for RS422-type traffic

    Hello all,

    I have been using high-speed RS422 in my applications for years. I've always wondered about using 100Mb ethernet as just the physical layer, though.

    RS485 parts are very pricey above 20MHz (especially if you need several of them at each end).

    I've looked at PHYs before, but I got the impression they were incapable of sending super-short packets. Years ago, we were able to send so-called "runt" packages, but I think things have since changed in the PHY/MAC world.

    My preference would be to send either 2 or 4-byte packets, plus the usual checksum (I think the chip enforces this), plus inter-packet spacing (which I believe is also a requirement). Primarily, I don't want to have to send source/destination MACs.

    Does anyone know if this can be done on the Teensy 4.1? I was also thinking if it's quick to reprogram the MAC, each packet could be sent with the data as the MAC. Although the receiving side would have to be a "sniffer" and be able to receive all packets. (BTW, the arrangement here would be a Teensy 4.1 talking to another Teensy 4.1)

    Thanks in advance.

  2. #2
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    This is a really intriguing idea, to just use ethernet as a raw serial-like byte stream at 100 Mbit speed. Or maybe as a raw packet delivery?

    If the ethernet mac is configured in promiscuous mode and automatic address transmit is disabled, I believe that leaves only the 16 bit length and 32 bit crc fields used by the mac's hardware. But the overall speed would also be affected by the 7 byte preamble, 1 byte start, and 8 byte inter-packet gap. I believe that adds up to 22 bytes of overhead minimum per packet. I see some mentions of being able to use shorter preamble, so maybe the per-packet overhead could get as low as only 15 bytes?

    But of course there is the 64 byte minimum packet size. The hardware has options for how to receive small packets, but on the transmit side I don't see any way to turn off the automatic padding up to 64 bytes. So if you really want to send only 2 or 4 bytes per packet, I'm afraid the overall speed would end up pretty disappointing.

    If larger packets are used, or if a library provide a byte-oriented stream which tries to fill up maximum size packets (as we do with USB serial), maybe this could offer a long distance and high speed serial-like connection.

  3. #3
    Junior Member
    Join Date
    Feb 2021
    I figured the PHY had requirements in order to reliably TX/RX data at 100Mbps. I was hoping it wasn't going to be so much, though.

    But since writing that post, I've been thinking about:

    1. setting up a timer IRQ to collect my samples
    2. a serial buffer to collect a packet
    3. output the fewest "overhead" bytes that are required and send a fixed number of samples
    4. on reception, use the same IRQ time to consume the samples

    Loose calculations suggest I could depend on 140K packets per second at 64 byte lengths. (64 mac requirement + 22 phy requirement + 2 for laughs)

    I'm getting a couple of 4.1 boards soon -- so I'll cobble something together. Not a lot change from the serial code I have now, with the exception of learning the PHY/MAC interface.


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts