cancel
Showing results for 
Search instead for 
Did you mean: 

How can I use DP83848 instead of LAN8742?

Bilge
Associate III

Hi,

I have a ready-made hardware and the hardware has dp83848 chip on it.I made ethernet communication with udp on stm32h7 .I can not choose a chip out of lan8742 on cubemx.

is there anyone who can guide on this?

8 REPLIES 8

Compare the two PHY chips' datasheets and modify the code accordingly.

JW

jerry_sandc
Associate III

Im having somewhat of a similar problem.  I have the STM32F769I-EVAL board with the DP83848 PHY.  I need to get this working with NetXDuo (Azure RTOS).   The nice examples I found in https://github.com/STMicroelectronics/x-cube-azrtos-f7 are for the STM32F769I-Discovery board which has the lan8742.  

Pavel A.
Evangelist III

As always, here or here you can find help.

It's hard to work remotely on a custom semi-ready hardware, but with common eval. boards it makes good sense.

 

Is NetXDuo (Azure RTOS) sufficiently open source so that you can modify the PHY-relevant portion of it? (I don't know, I don't use it).

If yes, my first post applies (i.e. you look at the sources to ascertain, which registers/bits of PHY are used, and then look at the datasheets to find out whether those registers/bits match or not, if not, modify accordingly. IIRC, I was able to migrate *my* code by making only one such change, faintly recollect that it was something around indication of autonegotiated link speed/mode, but it's years away...).

If not, you have to pester ST/Microsoft.

JW

PS. Had a quick look at the link you've given, and under BSP/Components I see both PHYs, so I'd say it should be sufficient to find all references to one PHY in the sources and bend them to refer to the other. Don't intend to delve deeper.

jerry_sandc
Associate III

Yes, i will have to 'bend' the driver to work with the HAL layer (generic ethernet API).  😁

I was really just asking if someone has gone through this exercise already.  

I wont be hiring anyone from upwork   😂

Like Jan, did this couple of times, with different PHYs (Microchip, Marvel...) and already forgot the details. Luckily the hardware was made well, the board folks were very good. So as Jan wrote, it was mainly comparing the datasheets. 

Re. "pester ST/Microsoft" - Microsoft already decided to dump ThreadX to the Eclipse Foundation.  LTS versions are supported for 5 years. The latest, 6.0 (?) will be in support until 2026. But they will only fix critical and security bugs. The opensource level of support is... basically, like upwork 🙂

> Microsoft already decided to dump ThreadX to the Eclipse Foundation

Interesting, thanks @Pavel A. !

So, @jerry_sandc is out of luck, basically nobody to pester... 😉

JW

Microsoft rarely is happy with their acquisitions, even less with their own developments. Who remembers AllJoyn? Dot.net micro? Windows CE? Now they've abandoned ThreadX in favor of what? Zephyr?