CANBUS Tx/Rx with data length > 8 bytes

On 29/11/15 06:19, Les Cargill wrote:
> Oliver Betz wrote:
>> "Marco T." wrote:
>>
>>> Hi to everybody!
>>> I should implement a function on my uC (Freescale MAC7121) that will
>>> receive and/or send data with length > 8 bytes: is it possible?
>>
>> I wonder when (whether) CAN FD will be supported widely.
>>
>> Oliver
>>
> 
> I'd kind of like to see CAN expire in general. There are
> different versions of an Ethernet PHY that can replace it. For
> other domains, there's PROFIBUS, which is weird but at least
> supports variable length PDUs.
> 

Profibus is horrendous.  It is complicated to implement, poorly
documented, "open" in the worst sense of the word (meaning "anyone can
pay lots of money to join a closed group that promises not to tell the
rest of the world how bad the specification is).  I had the "pleasure"
of working with it many years ago, using a dedicated ASIC - the best
available on the market at the time.  The documentation was barely
comprehensible - it had been translated from German to English by
someone who clearly knew nothing about Profibus or electronics in
general, and was barely competent in English.  One critical chapter -
containing the details of the register setup - was translated simply as
"original German unclear".

Profibus may not be the worst choice of fieldbus protocol - but it is
one that I would not recommend in normal circumstances.

CAN is a great choice when you want simple, clear and short telegrams
between nodes.  Now that it is common in microcontrollers, it is cheap
and easy to implement.  But that is only if /you/ have full control - if
it is a closed network.  It quickly gets horrible if you need to support
DeviceNet, CANOpen, CAN Kingdom, or these other "high level" protocols
on top of CAN.  Instead of clear and simple sub-millisecond
communication, you've got layers of negotiation about nodes and
telegrams, complex device description documents, certifications, pretend
"open" standards, and you have lost all hope of reliable timing.

Implementing your own scheme for larger telegrams over CAN is not hard
when you have a specific task (typically everything in the system is
short telegrams, except for firmware upgrades).

If you need something with higher bandwidth, jump straight to Ethernet.
 You can use standard networking and TCP/IP for ease of development
(Modbus over TCP/IP handles pretty much everything you need for a
typical fieldbus application, and you can add other protocols such as
TFTP for larger transfers).  Or you can use direct Ethernet frames for
maximal efficiency.

On 29/11/15 07:47, Les Cargill wrote:
> Dimiter_Popoff wrote:
>> On 29.11.2015 г. 07:19, Les Cargill wrote:
>>> Oliver Betz wrote:
>>>> "Marco T." wrote:
>>>>
>>>>> Hi to everybody!
>>>>> I should implement a function on my uC (Freescale MAC7121) that will
>>>>> receive and/or send data with length > 8 bytes: is it possible?
>>>>
>>>> I wonder when (whether) CAN FD will be supported widely.
>>>>
>>>> Oliver
>>>>
>>>
>>> I'd kind of like to see CAN expire in general. There are
>>> different versions of an Ethernet PHY that can replace it. For
>>> other domains, there's PROFIBUS, which is weird but at least
>>> supports variable length PDUs.
>>>
>>
>> I am not familiar with CAN but I would like to see a standardized
>> Ethernet connector for coaxial cable plus power pins (12V?). Have been
>> dreaming of that for may be 25 years.
> 
> What's wrong with PoE? You can run it over round cables with 4-conductor
> M12 connectors*. Works a treat.
> 
> https://www.vision-supplies.com/p/84533/sick-ethernet-m12-x-4-rj-45-connection-cable
> 

The trouble with PoE is that it is vastly over-engineered, resulting in
complicated and expensive parts.  If you have full control of devices on
each end, you can just pass 12V or 24V DC over a pair of lines on the
cable.  The easiest is to use one of the spare pairs (for 100 MBit), but
even for 1000 MBit all you need are a few diodes to inject the DC into
the data line.

But if you need /real/ PoE compatibility, that means a large clumpy
module to handle the DC-DC conversion, and the negotiation protocol
between the switch and the device to agree on voltages, current limits,
etc.  You also have to handle at least two standards, "mode A" and "mode
B", for which lines will carry the power - and make sure your switch and
your device agree.  And then ever PoE switch manufacturer has a dozen
variations, extensions and pseudo-standards of their own.

PoE could have been so cheap and simple that we would use it everywhere.
 Instead, it is far too complicated and expensive for the majority of uses.

> 
> 
> *I am pretty sure, but I never actually tested PoE over the 4-pin
> connectors.
> 
>> Apparently there has been no interest. Nowadays as we have more
>> RAM for buffer memory and they promote that IoT thing the necessity
>> has eventually become obvious - hopefully...
>>
> 
> IoT looks a lot like hype to me.
> 
>> Dimiter
>>
>> ------------------------------------------------------
>> Dimiter Popoff, TGI             http://www.tgi-sci.com
>> ------------------------------------------------------
>> http://www.flickr.com/photos/didi_tgi/
>>
> 

David Brown wrote:
> On 29/11/15 07:47, Les Cargill wrote:
>> Dimiter_Popoff wrote:
>>> On 29.11.2015 г. 07:19, Les Cargill wrote:
>>>> Oliver Betz wrote:
>>>>> "Marco T." wrote:
>>>>>
>>>>>> Hi to everybody!
>>>>>> I should implement a function on my uC (Freescale MAC7121) that will
>>>>>> receive and/or send data with length > 8 bytes: is it possible?
>>>>>
>>>>> I wonder when (whether) CAN FD will be supported widely.
>>>>>
>>>>> Oliver
>>>>>
>>>>
>>>> I'd kind of like to see CAN expire in general. There are
>>>> different versions of an Ethernet PHY that can replace it. For
>>>> other domains, there's PROFIBUS, which is weird but at least
>>>> supports variable length PDUs.
>>>>
>>>
>>> I am not familiar with CAN but I would like to see a standardized
>>> Ethernet connector for coaxial cable plus power pins (12V?). Have been
>>> dreaming of that for may be 25 years.
>>
>> What's wrong with PoE? You can run it over round cables with 4-conductor
>> M12 connectors*. Works a treat.
>>
>> https://www.vision-supplies.com/p/84533/sick-ethernet-m12-x-4-rj-45-connection-cable
>>
>
> The trouble with PoE is that it is vastly over-engineered, resulting in
> complicated and expensive parts.  If you have full control of devices on
> each end, you can just pass 12V or 24V DC over a pair of lines on the
> cable.  The easiest is to use one of the spare pairs (for 100 MBit),

That's a pretty bad idea, IMO. I'd only spec 
power-over-a-comm-connection if it's fully standard and very COTS.

> but
> even for 1000 MBit all you need are a few diodes to inject the DC into
> the data line.
>
> But if you need /real/ PoE compatibility, that means a large clumpy
> module to handle the DC-DC conversion, and the negotiation protocol
> between the switch and the device to agree on voltages, current limits,
> etc.  You also have to handle at least two standards, "mode A" and "mode
> B", for which lines will carry the power - and make sure your switch and
> your device agree.  And then ever PoE switch manufacturer has a dozen
> variations, extensions and pseudo-standards of their own.
>

I somehow did not find this that onerous, but we were not powering the
target with PoE, just auxiliary equipment - switches and radios. This
used Alt-A cabling.

We didn't use it in the end because we could/would not come up with the 
appropriate voltages. But in basic test, It Just Ran ( over RJ45 
connectors ).

> PoE could have been so cheap and simple that we would use it everywhere.
>   Instead, it is far too complicated and expensive for the majority of uses.
>

--
Les Cargill

upsidedown@downunder.com wrote:
> On Sat, 28 Nov 2015 23:19:42 -0600, Les Cargill
> <lcargill99@comcast.com> wrote:
>
>> Oliver Betz wrote:
>>> "Marco T." wrote:
>>>
>>>> Hi to everybody!
>>>> I should implement a function on my uC (Freescale MAC7121) that will
>>>> receive and/or send data with length > 8 bytes: is it possible?
>>>
>>> I wonder when (whether) CAN FD will be supported widely.
>>>
>>> Oliver
>>>
>>
>> I'd kind of like to see CAN expire in general.
>
> CAN is ideal when you have a lot of small nodes with a few, say 16
> binary or a few analog I/Os in a node. For other protocols you
> probably would have to use a concentrator/gateway and hardwire the
> nodes to the concentrator before going to some bus structure. With CAN
> it is economical to connect the small nodes to the buss directly.
>

It is, but in the end something has to aggregate all that. Once you
get to 30-40 end nodes, it gets messy. And people's CAN implementations
use a variety of endianness and representation of values.

> This works great with a small network (less than 10 m), but things get
> hairy at 250 m or even at 1000 m with very low data rates due to the
> signal propagation delay.
>

Yep.

>> There are
>> different versions of an Ethernet PHY that can replace it.
>
> The problem with Ethernet protocols is the requirement of at least 64
> bytes total, so for most small I/O nodes, they do not even fill that
> minimum size frame.
>

This turns out not to be a problem so long as you can maintain at least
10MBit. @ 100 MBit life is pretty good.

> One exception is EtherCAT
> ttps://en.wikipedia.org/wiki/EtherCAT
> in which the master sends out a big Ethernet frame, which then passes
> through each slave. Each slave picks the bytes it is interested in. It
> can also reuse a slot in the frame and insert input data into a free
> slot and finally the frame is passed back to the master, extracting
> all input data inserted into the frame during the pass through each
> slave. Of course, this requires specialized hardware in each node. The
> delay is only a few Ethernet bit times in each slave.
>

I find that latency and jitter aren't quite the worst thing in the
world. And the critical detail is that bandwidth reduces those.

Many CAN nodes use a 10msec poll rate; well, just about anything
with a Linux scale O/S and a select() loop will be well ahead of
10 msec in latency. In one case, I didn't even have to spend
much time turning services off to get that.

> Think about a local train, in which passengers are leaving at each
> station and others will enter at each station.
>
>> For
>> other domains, there's PROFIBUS, which is weird but at least
>> supports variable length PDUs.
>
> At least Profibus DP is just glorified multidrop Modbus RTU on RS-485.
> with all the same issues with small nodes as with all request/response
> protocols.
>

Yep. Better bit rate, though. I find in controls people a lack of
understanding that bandwidth helps.

-- 
Les Cargill

David Brown wrote:
> On 29/11/15 06:19, Les Cargill wrote:
>> Oliver Betz wrote:
>>> "Marco T." wrote:
>>>
>>>> Hi to everybody!
>>>> I should implement a function on my uC (Freescale MAC7121) that will
>>>> receive and/or send data with length > 8 bytes: is it possible?
>>>
>>> I wonder when (whether) CAN FD will be supported widely.
>>>
>>> Oliver
>>>
>>
>> I'd kind of like to see CAN expire in general. There are
>> different versions of an Ethernet PHY that can replace it. For
>> other domains, there's PROFIBUS, which is weird but at least
>> supports variable length PDUs.
>>
>
> Profibus is horrendous.

It is indeed. It's a configuration management nightmare.

> It is complicated to implement, poorly
> documented, "open" in the worst sense of the word (meaning "anyone can
> pay lots of money to join a closed group that promises not to tell the
> rest of the world how bad the specification is).  I had the "pleasure"
> of working with it many years ago, using a dedicated ASIC - the best
> available on the market at the time.

Heh.

>  The documentation was barely
> comprehensible - it had been translated from German to English by
> someone who clearly knew nothing about Profibus or electronics in
> general, and was barely competent in English.  One critical chapter -
> containing the details of the register setup - was translated simply as
> "original German unclear".
>
> Profibus may not be the worst choice of fieldbus protocol - but it is
> one that I would not recommend in normal circumstances.
>

I would agree.

> CAN is a great choice when you want simple, clear and short telegrams
> between nodes.  Now that it is common in microcontrollers,


Mmmmmm.... okay. I would gently disagree. Compared to some older
full-function CAN controllers* the micro solutions are pretty
bare. They're fine if your node fanout is small enough.

*the sort where a "send" operation takes one write to start, so
you can put that on a low-latency timer loop, with the contents 
assembled in a more relaxed manner.

> it is cheap
> and easy to implement.  But that is only if /you/ have full control - if
> it is a closed network.  It quickly gets horrible if you need to support
> DeviceNet, CANOpen, CAN Kingdom, or these other "high level" protocols
> on top of CAN.

Absolutely.

> Instead of clear and simple sub-millisecond
> communication, you've got layers of negotiation about nodes and
> telegrams, complex device description documents, certifications, pretend
> "open" standards, and you have lost all hope of reliable timing.
>
> Implementing your own scheme for larger telegrams over CAN is not hard
> when you have a specific task (typically everything in the system is
> short telegrams, except for firmware upgrades).
>
> If you need something with higher bandwidth, jump straight to Ethernet.

I could not agree more.

>   You can use standard networking and TCP/IP for ease of development
> (Modbus over TCP/IP handles pretty much everything you need for a
> typical fieldbus application, and you can add other protocols such as
> TFTP for larger transfers).

Not a big fan of MODBUS over TCP. It's okay.

>  Or you can use direct Ethernet frames for
> maximal efficiency.
>

I find that really basic ASCII protocols over UDP or TCP work just
fine. At about 100 individual elements/registers, it starts to show
real advantages over MODBUS.

My measurements of trying to go directly to Ethernet instead of using
UDP or TCP don't support that choice.


-- 
Les Cargill

On Sun, 29 Nov 2015 09:57:52 -0600, Les Cargill
<lcargill99@comcast.com> wrote:

>>   You can use standard networking and TCP/IP for ease of development
>> (Modbus over TCP/IP handles pretty much everything you need for a
>> typical fieldbus application, and you can add other protocols such as
>> TFTP for larger transfers).
>
>Not a big fan of MODBUS over TCP. It's okay.

Run Modbus RTU or Modbus/TCP frames in UDP frames.

>>  Or you can use direct Ethernet frames for
>> maximal efficiency.

The raw Ethernet or UDP is nearly as efficient, Of course, you would
have to implement the ARP protocol, but this helps configuration
somewhat.

No need to implement the TCP stack.

>I find that really basic ASCII protocols over UDP or TCP work just
>fine. At about 100 individual elements/registers, it starts to show
>real advantages over MODBUS.

Of course if you insist of using ASCII, there is also Modbus ASCII,
the frame fits nicely into an Ethernet or UDP frame :-)

>My measurements of trying to go directly to Ethernet instead of using
>UDP or TCP don't support that choice.

Some old Siemens Ethernet protocols used raw MAC addresses and there
were always problems getting it to work in a real world environment
with multiple vendors.

UDP+ARP simplifies life.

On Sun, 29 Nov 2015 12:24:38 +0100, David Brown
<david.brown@hesbynett.no> wrote:

>On 29/11/15 07:47, Les Cargill wrote:
>> Dimiter_Popoff wrote:
>>> On 29.11.2015 ?. 07:19, Les Cargill wrote:
>>>> Oliver Betz wrote:
>>>>> "Marco T." wrote:
>>>>>
>>>>>> Hi to everybody!
>>>>>> I should implement a function on my uC (Freescale MAC7121) that will
>>>>>> receive and/or send data with length > 8 bytes: is it possible?
>>>>>
>>>>> I wonder when (whether) CAN FD will be supported widely.
>>>>>
>>>>> Oliver
>>>>>
>>>>
>>>> I'd kind of like to see CAN expire in general. There are
>>>> different versions of an Ethernet PHY that can replace it. For
>>>> other domains, there's PROFIBUS, which is weird but at least
>>>> supports variable length PDUs.
>>>>
>>>
>>> I am not familiar with CAN but I would like to see a standardized
>>> Ethernet connector for coaxial cable plus power pins (12V?). Have been
>>> dreaming of that for may be 25 years.
>> 
>> What's wrong with PoE? You can run it over round cables with 4-conductor
>> M12 connectors*. Works a treat.
>> 
>> https://www.vision-supplies.com/p/84533/sick-ethernet-m12-x-4-rj-45-connection-cable
>> 
>
>The trouble with PoE is that it is vastly over-engineered, resulting in
>complicated and expensive parts.  If you have full control of devices on
>each end, you can just pass 12V or 24V DC over a pair of lines on the
>cable.  The easiest is to use one of the spare pairs (for 100 MBit), but
>even for 1000 MBit all you need are a few diodes to inject the DC into
>the data line.
>
>But if you need /real/ PoE compatibility, that means a large clumpy
>module to handle the DC-DC conversion, and the negotiation protocol
>between the switch and the device to agree on voltages, current limits,
>etc.  You also have to handle at least two standards, "mode A" and "mode
>B", for which lines will carry the power - and make sure your switch and
>your device agree.  And then ever PoE switch manufacturer has a dozen
>variations, extensions and pseudo-standards of their own.
>
>PoE could have been so cheap and simple that we would use it everywhere.
> Instead, it is far too complicated and expensive for the majority of uses.


The two standards bit does get a bit silly, but the problem with
standardizing power distribution is that you immediately run into the
question of how much power is available to the device.  If you have a
bus-like configuration, it gets worse because you now have to deal
with unknown numbers of devices drawing unknown amounts of power.  A
good chunk of the power related complexity in USB and PoE is the
management of that.

Now you could leave it strictly up to whoever's plugging things
together, and require something like a "ringer equivalence number*" to
be printed on each device, then the integrator just needs to total up
the "RENs" and compare that to the REN output of the bus-hosting
device.  OTOH, that certainly would not be acceptable for any
consumer(-ish) device today.


*And for those of you too young** to know what a REN is...  Old POTS
telephones used a higher voltage/current signal to drive the
mechanical ringer than was used to drive the speaker and microphone
circuits.  Basically in "talk" mode, there was just not enough current
on the line to move the mechanical ringer.  Obviously if you had
multiple phones, you needed more current to make them all ring at
once.  So a standard was established that a Bell 500 phone had a REN
of 1.0, and a standard phone line would drive a load of 5.0 REN.  So
you could have five phones with "standard" load ringers on a line and
have them ring reliably.  A few phones had higher RENs, and many
modern electronic phones have much lower RENs, but the idea was that
the total of the RENs for all the phones on the line has to be no more
than 5.0.  REN boosters were available (actually still are) for
situations where you needed more oomph.  Sometimes called RAL outside
the US.

**And... Damn kids, get off my lawn!

On 29.11.2015 г. 08:47, Les Cargill wrote:
> Dimiter_Popoff wrote:
>> On 29.11.2015 г. 07:19, Les Cargill wrote:
>>> Oliver Betz wrote:
>>>> "Marco T." wrote:
>>>>
>>>>> Hi to everybody!
>>>>> I should implement a function on my uC (Freescale MAC7121) that will
>>>>> receive and/or send data with length > 8 bytes: is it possible?
>>>>
>>>> I wonder when (whether) CAN FD will be supported widely.
>>>>
>>>> Oliver
>>>>
>>>
>>> I'd kind of like to see CAN expire in general. There are
>>> different versions of an Ethernet PHY that can replace it. For
>>> other domains, there's PROFIBUS, which is weird but at least
>>> supports variable length PDUs.
>>>
>>
>> I am not familiar with CAN but I would like to see a standardized
>> Ethernet connector for coaxial cable plus power pins (12V?). Have been
>> dreaming of that for may be 25 years.
>
> What's wrong with PoE? You can run it over round cables with 4-conductor
> M12 connectors*. Works a treat.

It is not about the cable being round, it is about the cabling length.
With a coaxial cable it can be nodes_count times shorter, just a single
cable running through all the nodes. And no switch necessary.

Then the 70V is somewhat too high, one cannot just use a trivial
stepdown convertor as with say 12V for smallish things.
I had designed PoE in our netMCA as an option on the board, well,
was never used. Nobody had any thoughts on having a wall adapter,
in fact need for a PoE capable router would have been more of a
barrier in user perception.

>> Apparently there has been no interest. Nowadays as we have more
>> RAM for buffer memory and they promote that IoT thing the necessity
>> has eventually become obvious - hopefully...
>>
>
> IoT looks a lot like hype to me.

Which is what it is of course. But this does not mean devices will
not be connected over the net, our netMCA is one of those "things"
quite some years before they coined the phrase.
It will take just some more RAM on the MCUs, a few MB, and tcp/ip
stacks will be practical even at higher speeds/transfer rates.

Dimiter

------------------------------------------------------
Dimiter Popoff, TGI             http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/

On Sun, 29 Nov 2015 23:23:14 +0200, Dimiter_Popoff <dp@tgi-sci.com>
wrote:

>On 29.11.2015 ?. 08:47, Les Cargill wrote:
>> Dimiter_Popoff wrote:
>>> On 29.11.2015 ?. 07:19, Les Cargill wrote:
>>>> Oliver Betz wrote:
>>>>> "Marco T." wrote:
>>>>>
>>>>>> Hi to everybody!
>>>>>> I should implement a function on my uC (Freescale MAC7121) that will
>>>>>> receive and/or send data with length > 8 bytes: is it possible?
>>>>>
>>>>> I wonder when (whether) CAN FD will be supported widely.
>>>>>
>>>>> Oliver
>>>>>
>>>>
>>>> I'd kind of like to see CAN expire in general. There are
>>>> different versions of an Ethernet PHY that can replace it. For
>>>> other domains, there's PROFIBUS, which is weird but at least
>>>> supports variable length PDUs.
>>>>
>>>
>>> I am not familiar with CAN but I would like to see a standardized
>>> Ethernet connector for coaxial cable plus power pins (12V?). Have been
>>> dreaming of that for may be 25 years.

The 10Base5 with vampire taps and RG-8 like coaxial cable was nice,
why not implement your own PoE ? The RG-8/213 like coaxial cable can
withstand several hundred volts and several amps :-)

>> What's wrong with PoE? You can run it over round cables with 4-conductor
>> M12 connectors*. Works a treat.
>
>It is not about the cable being round, it is about the cabling length.
>With a coaxial cable it can be nodes_count times shorter, just a single
>cable running through all the nodes. And no switch necessary.
>
>Then the 70V is somewhat too high, one cannot just use a trivial
>stepdown convertor as with say 12V for smallish things.

The nice thing about Ethernet is that it requires galvanic isolation
between nodes. Using some simple non-isolated stepdown converters from
12 V would ruin the isolation on the network. 70 V pretty much forces
using proper isolated converter.

On 30.11.2015 г. 02:53, upsidedown@downunder.com wrote:
> On Sun, 29 Nov 2015 23:23:14 +0200, Dimiter_Popoff <dp@tgi-sci.com>
> wrote:
>
>> On 29.11.2015 ?. 08:47, Les Cargill wrote:
>>> Dimiter_Popoff wrote:
>>>> On 29.11.2015 ?. 07:19, Les Cargill wrote:
>>>>> Oliver Betz wrote:
>>>>>> "Marco T." wrote:
>>>>>>
>>>>>>> Hi to everybody!
>>>>>>> I should implement a function on my uC (Freescale MAC7121) that will
>>>>>>> receive and/or send data with length > 8 bytes: is it possible?
>>>>>>
>>>>>> I wonder when (whether) CAN FD will be supported widely.
>>>>>>
>>>>>> Oliver
>>>>>>
>>>>>
>>>>> I'd kind of like to see CAN expire in general. There are
>>>>> different versions of an Ethernet PHY that can replace it. For
>>>>> other domains, there's PROFIBUS, which is weird but at least
>>>>> supports variable length PDUs.
>>>>>
>>>>
>>>> I am not familiar with CAN but I would like to see a standardized
>>>> Ethernet connector for coaxial cable plus power pins (12V?). Have been
>>>> dreaming of that for may be 25 years.
>
> The 10Base5 with vampire taps and RG-8 like coaxial cable was nice,
> why not implement your own PoE ? The RG-8/213 like coaxial cable can
> withstand several hundred volts and several amps :-)

I would if I felt I had the muscle to enforce a standard :).
It does not have to be 10base5, 10base2 (not sure, the 5mm coax
cable thing) is plenty I think. I am not thinking hundreds of meters,
rather a few meters to may be tens of meters. Then may be today
we can do somewhat more than 10 Mbps over the coax cable, say 50
would be very nice. Using a <3mm coax (I always have to look up the
RG whatever names...) could also be convenient within say an apartment
or a small house.

>
>>> What's wrong with PoE? You can run it over round cables with 4-conductor
>>> M12 connectors*. Works a treat.
>>
>> It is not about the cable being round, it is about the cabling length.
>> With a coaxial cable it can be nodes_count times shorter, just a single
>> cable running through all the nodes. And no switch necessary.
>>
>> Then the 70V is somewhat too high, one cannot just use a trivial
>> stepdown convertor as with say 12V for smallish things.
>
> The nice thing about Ethernet is that it requires galvanic isolation
> between nodes. Using some simple non-isolated stepdown converters from
> 12 V would ruin the isolation on the network. 70 V pretty much forces
> using proper isolated converter.
>

Obviously I agree with this. May be just 70V, isolated, would be much
better. It is no rocket science to step that down in an isolated way
nowadays.

It will take a while until we see MCU-s with an on chip PHY similar to
the DP8392...

Dimiter