-
-
Notifications
You must be signed in to change notification settings - Fork 494
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Support for W5500 SPI Ethernet Controller #1200
base: master
Are you sure you want to change the base?
Conversation
Could you please cleanup your commit history? I see a lot of temporary commits etc. Its not required to put all into one commit. |
Should be better now. |
comment from my end:
I think for plain ESP32 this is not so important because there you have the MAC boards like OLIMEX but C3 and S2 also come without the MAC and will rely on SPI. W5500 breakouts without PoE can be had rather cheap, so I guess this support will also spark some ideas from other people. |
It should now successfully compile for all platforms 😅 |
are there still any issues open? |
I think it just has not been revisited yet. |
@tbnobody do you have anything else that needs to be adressed? |
unfortunately this has now rotten so that there are conflicts. @LennartF22 are they easy to resolve? If there are no other open items I would urge to clear up remaining issues and merge this. |
@markusdd The merge conflicts are negligible and easy to fix, but I won't fix them right now, because the @tbnobody It would probably be good if I reimplemented my changes to the RF24 library in a clean way, so that my changes could eventually be merged into RF24 library's |
@LennartF22 I opened a question on how to get the changes for the virtual HAL into RF24 library upstream. |
@LennartF22 Great, I see you haven't been accepted yet @tbnobody What is the current state of play now for the merge? |
is this going to be integrated any time soon ? |
@LennartF22 besides the straight forward way of adding a custom device / hardware "utility driver" to the RF24 library upstream, we could also add your changes to the RF24 library eg as @tbnobody could you answer @LennartF22 's question about this PR or tell us your thoughts about supporting the OpenDTU Fusion boards with its Power-over-Ethernet add-on adding such an out-of-the-box build ? |
I should add that this is not only about ethernet, this also is the basis for solving the issue of running 2 RFs and e.g. an additional ePaper display in a stable fashion. |
@LennartF22 is it possible to be able the Huawei 4850G2 in combination with the CMT2300A? It is a software issue, right? Could it be solved in a similar way this ethernet issue was solved? |
@markusdd That would be awesome, adding support for the HMS/HMT with Huawei would be great. Currently only HM can be combined with the Huawei (i.e. max HM 1500 instead of for example combing the HMT-2250 with the Huawei).
|
Hi. No. What you are asking for is the reverse. What you want is one external device to be driven by 2 different software drivers. This is certainly possible, but completely unrelated to what we do here. Only connection is that once this here would finally get a review and maybe approval, the path to doing what you are asking for would become easier. |
Hi. I'm looking for a solution that a CMT2300A can be used together with the Huawei and Pylontech. The Pylontech is covered by the ESP32 CAN controller. So also in my case two devices need to be controlled over one SPI bus (HMT/HMS and Huawei). The case that both the CMT2300A and NRF24L01+ are needed are currently not in focus, as the power limiting function only controls one Hoymiles. |
Is the Huawei using 3-wire SPI? That sounds like some long cables. Or is it controlled via the CMT RF? |
TL;DR Yes, this would probably also fix your issue, but there are better alternatives (like making use of the ESP32's internal CAN controller). As far as I understood, the Huawei 4850G2 can be controlled via CAN bus, and the current implementation uses an external CAN controller + transceiver (probably MCP2515), and is not using the internal CAN controller of the ESP32 for some reason. The best solution would be to just use the internal CAN controller of the ESP32, which just requires a CAN transceiver to be hooked up to the ESP32, but still requires some code changes. Using the CMT2300A and an external CAN controller via SPI should not be a problem at all though, because we can give both of them their own SPI bus, as long as there is no nRF24L01+ on top of that. If that configuration does not work, the problem is most probably that the SPI busses are assigned statically (for example the CMT2300A might always uses bus 2, and the CAN controller might always try to use bus 2, too). This should be a rather easy software fix. It gets more problematic when there are more than two SPI devices. Of course hooking up more than one device to the same SPI bus is possible, but it requires much attention due to concurrency and interrupts. It becomes even more complicated when a three wire and normal SPI device need to operate on the same SPI bus. In this PR, I implemented sharing of an SPI bus between the nRF and the CMT, which means that one SPI bus is always free, no matter which RF modules are used (it is even possible to use both simultaneously). This leaves the second SPI bus free for many other applications: for example SPI Ethernet controllers, CAN controllers and displays. Although this would solve the issue with using the CMT2300A and an external CAN controller simultaneously, it is not the prefered solution, as you then cannot use stuff like SPI Ethernet at the same time without major software headaches, while it can be solved in a much simpler way (alluding to the internal CAN controller of the ESP32). |
@LennartF22 @markusdd OK, in theory the RS485 could be used for the Pylontech, there is even code on it. |
"If that configuration does not work, the problem is most probably that the SPI busses are assigned statically (for example the CMT2300A might always uses bus 2, and the CAN controller might always try to use bus 2, too). This should be a rather easy software fix." I fully agree that that software solution would be ideal: I don't understand how we achieve this "rather easy software fix". Which steps do we need to take to achieve that? |
I've rebased the source and made several changes already:
Currently figured out the following problems when compiling with
That's because espc3 has less SPI hosts.
That's true as long as a patched version of a display library is used right? Because it must also support the handling with SpiPatcher. My fear is to maintain a whole bunch of librarys myself and upgrade it's versions. |
@tbnobody That's good to hear! I definitely understand that you don't want to maintain several additional, external libraries, as that sort of defeats the purpose of having external libraries in the first place :) That's why we already contacted the RF24 maintainers on how they would go about adding support for our needs in a proper fashion, and quickly found a good solution, but nobody has implemented it yet. I haven't been particularly motivated myself so far to implement it, because this PR was seemingly not going anywhere, but now I will try to take care of it as soon as I find some spare time.
Yes and no. I guess you would already profit from the two RF modules only using one SPI bus, because as long as you don't need Ethernet on lets say an ESP32-S3, you now have a dedicated SPI bus to spare, so that available libraries can be used off-the-shelf. On top of that, I think there even was a PR with a modified library for some SPI display that used bit banging to get around the SPI bus issues already. I don't know about the fate of that PR, but using the SPI patcher over the bit banging would be a prettier solution, if some modifications need to be done to the library anyways, although some mechanism would be needed to avoid the display driver claiming the SPI bus for too long transfers.
So currently, only using one RF module with the ESP32-C3 is supported? I think nothing speaks against using |
The problem is indeed the The SpiPatcher which uses SPI2 #define HOYMILES_HOST_DEVICE SPI2_HOST works without problems. |
Oh I see, I didn't read properly 😅 Ideally, we would not build the ETHSPI class for the ESP32-C3 target at all, but that obviously also requires some macros wherever the ETHSPI object is called. We should also be able to use a hack like this, as SPI Ethernet on the ESP32-C3 won't/cannot be used anyway: #ifdef SPI3_HOST
#define ETH_HOST_DEVICE SPI3_HOST
#else
#define ETH_HOST_DEVICE SPI2_HOST
#endif |
Is this still being worked on? |
+1 ... kind of. I – like so many others – am interested in seeing the W5500 being supported by OpenDTU, but can thoroughly understand tbnobody’s dislike for a half-baked, hacked solution which requires continuous attention in order to keep things properly working. |
I wouldn't agree that it is hacked tbh. Frankly some of this is actually a necessary clean-up or improvement of how spi devices are handled in general, the real issue is that Espressif has made our life very hard by changing around the SPI port nomenclature. My issue is that I cannot get ANY feedback what the holdup is or what we can do about it. |
Being able to attach both an ePaper display and the W5500 is also a must IMO. That’s what SPI is made for. |
While I understand that (and it is possible), I still want to make you aware that the ESP is still a microcontrller and this is primarily a DTU. The Display code puts a heavy load on these devices and I haven't been a fan of this from day one. If anything, I recommend using i2c displays. The bus inside the ESPs is not the fastest and pushing too much through one SPI is problematic. |
It's sad that there has been zero reaction since ages. I doubt that this is going to be implemented any time soon. |
I don't know if it would be possible for @LennartF22 to at least rebase the fork to give people on PoE the latest greatest codebase, will be necessary anyway to go ahead with this. But yeah, for mainline support ahoy is the only route right now, but it sucks for everybody who is relying on OpenDTU exclusive features. Tried to contact noby oon Discord as well but no respoonse yet. |
In order to use Ethernet on newer ESP32 versions like the ESP32-S3, which don't have an Ethernet MAC included anymore, Ethernet over SPI has to be used. In this PR, the W5500 Ethernet controller can be configured in the
pin_mapping.json
or via build flags, similar to how Ethernet over RMII was (and still is) supported before.Unfortunately, both externally available SPI master drivers of the ESP32 are already in use when the nRF24 and CMT2300A are configured. Although both RF modules could theoretically run on the same SPI bus (with shared data and clock pins) without issues, support for having the two RF modules on different physicals pins of the ESP32 must be maintained for obvious reasons.
To still support SPI Ethernet, this PR implements a wrapper for SPI transactions initiated by the RF module drivers, which reconfigures the signals between the two physical sets of GPIO pins and only one, shared SPI peripheral automatically when needed. The switching/reconfiguration process has been heavily optimized, so that this change should not have any negative impact on the performance of OpenDTU.
As the RF24 library currently only supports directly using the Arduino SPI functions, it had to be forked. In the future, we could try to create a PR to bring the added functionality of the RF24 library to the original repository, or we could just continue using the fork, as the RF24 library probably won't have relevant changes for OpenDTU/ESP32 anyway.
The code has already successfully been tested by multiple users of the OpenDTU Fusion (together with the new OpenDTU Fusion Shield).