I have this scenario: We have existing products in the field that we continue to support with OTA FW updates. And we want to develop the next generation product which uses some different components. We would like to distribute a single FW binary that can support both old and new hardware.
Specifically, old HW uses RMII interface to LAN8720 for Ethernet (and burns 9 IO pins!).
New HW will use SPI interface to W5500 for Ethernet and probably some other new stuff on that same SPI interface.
It looks like I can enable support for both RMII and SPI Ethernet in menuconfig. Does that mean I can select which one to use at runtime?
Can single fw support multiple hardware variants? (Ethernet RMII vs. SPI)
-
- Posts: 211
- Joined: Fri May 07, 2021 10:35 am
Re: Can single fw support multiple hardware variants? (Ethernet RMII vs. SPI)
You can run both RMII and SPI Ethernet at a time. However, that's not your case. For example, if your board is version with only SPI Ethernet and you try to initialize the RMII Ethernet, the init would fail. You could theoretically use this approach in your case but it would not be ideal from failure isolation point of view. You could get into the following trouble - was this expected fail due to HW revision or was it real hardware failure of connected PHY chip?
One solution which crossed my mind is to use some kind of boot strapping on your board revisions. You add boot strap resistors to e.g. two GPIO and read their configuration at startup.
It could be like:
0 0 REV1
0 1 REV2
1 0 ...
Then you initialize either RMII interface or SPI based on the boot strap resistor configuration.
One solution which crossed my mind is to use some kind of boot strapping on your board revisions. You add boot strap resistors to e.g. two GPIO and read their configuration at startup.
It could be like:
0 0 REV1
0 1 REV2
1 0 ...
Then you initialize either RMII interface or SPI based on the boot strap resistor configuration.
Re: Can single fw support multiple hardware variants? (Ethernet RMII vs. SPI)
Thanks ESP_ondrej for your confirmation that this could work.
I already have a method to detect the HW version at run-time (on our production-line, we write a hardware version code to a special NVS partition).
I already have a method to detect the HW version at run-time (on our production-line, we write a hardware version code to a special NVS partition).
Who is online
Users browsing this forum: Bing [Bot] and 101 guests