Yes, it worked ;-). I locked myself up in the office for the last 48 hours. And rewrote AsyncWebserver but using Ethernet.h instead of LWiP. All features of AsyncWebserver are available, the only thing you need to take care of is the periodic upkeep (a single line of code in the main loop).
I also added an updater for the internal ESP clock (separate) to update over NTP via Ethernet.h.

All in all it took the most out of the past 48 hours but for me it was very worthwhile. Consumed progmem is less than half of what is was (total program went down from 1.1MB to 604kB). Static ram usage went down from (critical 90%) to a comfortable 35%. Dynamic Ram usage decreased by a 40%. All of this is probably mostly due to the fact that we can rely on the W5500's internal IP stack instead of LWiP.

Another gain for me is that the periodic upkeep is very predictible, making my main control loop (which also runs RS485) more stable and very predictible. Loop time is now (very) stable at under a ms. Wheres with LWiP it would vary a lot under network load. As an embedded system engineer (by background) this is one of the things that pleases me the most. I can serve a 60MB file or even upload a large file (limited only by storage) to the system without noticable impact on the main process.

Performance wise it seems to be a tad slower for now than LWiP over WiFi with AsyncWebserver. Serving the webui of around 3MB takes about a second longer at roughly 4 seconds to fully load. But there is plenty room for optimization as i now only use a single socket buffer of 2048kB in the w5500 at a time. So there is about 8 times as much performance available.

I'll most likely make a Github page for this if there is any interest from the community. For now i'm going to have a good sleep 😉👍

PPG is pretty finicky and the signal more often than not requires cleanup by software algorithms. Double readings are not uncommon and appear even in medical grade sensors. Most sensors used nowadays have multiple emittors or a single emittor with multiple sensors. The "evaluation sensor" with one led and one sensor used for this device will indeed require very precise and stable placement. Even so i'd recommend trying to get the raw signal out of the sensor if possible at 24-40hz (24 and 40hz are commonly used for PPG processing algorithms and usually a good place to start from). working with and visualising the raw signals will give you a much better insight of what you're measuring.

Current supplyed by the Core2 is not gona be a limiting factor in this. Noise of the voltage convertor could cause issues, but this can only be checked if the raw signal is analysed. Often sensors make use of motion sensors to discard readings during detected motion.

I also had some issues with the M5Stack basic and SD cards. I was unable to read 9 out of 10 cards. In the end i ended up slowing down the SD card clock from 40Mhz to 10Mhz, this solved all the read issues for me. You can achieve this by editing the M5Stack.cpp file, in the function M5Stack begin SD is enabled using the following function:

// TF Card
if (SDEnable == true) {
    SD.begin(TFCARD_CS_PIN, SPI, 40000000);
}

I changed this to:

// TF Card
if (SDEnable == true) {
    SD.begin(TFCARD_CS_PIN, SPI, 10000000);
}

Since than i have had no more troubles reading from and writing to the SD card.

Yes, it worked ;-). I locked myself up in the office for the last 48 hours. And rewrote AsyncWebserver but using Ethernet.h instead of LWiP. All features of AsyncWebserver are available, the only thing you need to take care of is the periodic upkeep (a single line of code in the main loop).
I also added an updater for the internal ESP clock (separate) to update over NTP via Ethernet.h.

All in all it took the most out of the past 48 hours but for me it was very worthwhile. Consumed progmem is less than half of what is was (total program went down from 1.1MB to 604kB). Static ram usage went down from (critical 90%) to a comfortable 35%. Dynamic Ram usage decreased by a 40%. All of this is probably mostly due to the fact that we can rely on the W5500's internal IP stack instead of LWiP.

Another gain for me is that the periodic upkeep is very predictible, making my main control loop (which also runs RS485) more stable and very predictible. Loop time is now (very) stable at under a ms. Wheres with LWiP it would vary a lot under network load. As an embedded system engineer (by background) this is one of the things that pleases me the most. I can serve a 60MB file or even upload a large file (limited only by storage) to the system without noticable impact on the main process.

Performance wise it seems to be a tad slower for now than LWiP over WiFi with AsyncWebserver. Serving the webui of around 3MB takes about a second longer at roughly 4 seconds to fully load. But there is plenty room for optimization as i now only use a single socket buffer of 2048kB in the w5500 at a time. So there is about 8 times as much performance available.

I'll most likely make a Github page for this if there is any interest from the community. For now i'm going to have a good sleep 😉👍

Hi Felix

Thanks for your reply. 2 SPI masters you say, thats an interesting take and could well be an issue i have overlooked. My take was purely looking for race conditions between the chip select and spi usage. (Since the w5500 lwip is probably controlled in core 0 and the SD and TFT are controlled in core 1).

I've looked into using Ethernet last night, and this works however the http has to be done in local code as there does not seem to be a more intelligent webserver out there using Ethernet. Also the examples are all synchronous and blocking. I started coding a webserver based on Ethernet, but after one hour found myself wondering if that was really necessary (like parsing requests and so on in local code). So the support for Ethernet seems way more limited ( low level ) over LWiP. Even though it is a possible rout to threat so it is still a consideration.

Thanks,
Bas

Hi all,
I have a project where i want to use the Core Basic together with the w5500 Lan Base in an industrial setting. Since the Core Basic is fitted into a steel cabinet and there is lots of interference i don't want to rely on WiFi. I'm using the espressif arduino framework to proram the base. Now i can get SD to work, and i can get the w5500 to work but not together. As soon as initiate the w5500 module and connect to LAN my SD card stops to function. Not really surprising probably since they are both using the same SPI bus (also together with the TFT display).

I'm using the esp32_w5500 lwip driver from espressif, wich plays nice with the spi_master (spi_bus_add_device). However the entire SD and TFT SPI interface of M5Stack is completely ignoring this and is just hard setting CS without checking.

The most elegant solution whould be to find a SDFS implementation that works nicely together with spi_master i guess. But i wonder what is your take on this. Has anybody else ever tried the w5500 module together with SD. It does seem like a common thing to do, but i cannot find any actual cases of this, nor real solutions.

So i'd like to share some thoughts. I'm willing to spend some efford into changing up the SD and TFT drivers from M5Stack, but i want to know if there are already available solutions first.

Best regards,
Bas

PPG is pretty finicky and the signal more often than not requires cleanup by software algorithms. Double readings are not uncommon and appear even in medical grade sensors. Most sensors used nowadays have multiple emittors or a single emittor with multiple sensors. The "evaluation sensor" with one led and one sensor used for this device will indeed require very precise and stable placement. Even so i'd recommend trying to get the raw signal out of the sensor if possible at 24-40hz (24 and 40hz are commonly used for PPG processing algorithms and usually a good place to start from). working with and visualising the raw signals will give you a much better insight of what you're measuring.

Current supplyed by the Core2 is not gona be a limiting factor in this. Noise of the voltage convertor could cause issues, but this can only be checked if the raw signal is analysed. Often sensors make use of motion sensors to discard readings during detected motion.

Glad to hear it worked for you too!

I also had some issues with the M5Stack basic and SD cards. I was unable to read 9 out of 10 cards. In the end i ended up slowing down the SD card clock from 40Mhz to 10Mhz, this solved all the read issues for me. You can achieve this by editing the M5Stack.cpp file, in the function M5Stack begin SD is enabled using the following function:

// TF Card
if (SDEnable == true) {
    SD.begin(TFCARD_CS_PIN, SPI, 40000000);
}

I changed this to:

// TF Card
if (SDEnable == true) {
    SD.begin(TFCARD_CS_PIN, SPI, 10000000);
}

Since than i have had no more troubles reading from and writing to the SD card.

Hi all,
I'm willing to add a counter functionality to the PBHub v1.1. It seems possible from the spec sheet of the STM32F030F4p6 used in this device. Also the programming pins are broken out, so reprogramming the chip is not too hard. It whould be very preferrable to add the functionality on the existing FW instead of creating the FW from scratch. In the github of m5stack i was only able to find the FW of the EXT.IO using the same chip, however the PBHub v1.1 is not listed. Any idea's on this one? Also when playing with custom FW, it whould be nice to have the option to reflash the factory firmware.
Best regards, and thanks,
Bas