Hi, I am currently trying the first of many programs from Arduino Due + Ethernet Shield to Teensy 4.1 + NativeEthernet, as Teensy 4.1 promises much better performance and capabilities. Unfortunately, I am hitting an issue, I cannot understand and would very much appreciate any input.
The programs does Home Automation, reading data from devices, installed throughout my home, using either Ethernet, KNX (Serial1) or RF (Serial 2). The original program has perfectly worked for several years. The program itself consists of many sub routines, which are mostly short but very project dependent. Posting the complete software here would at this stage not be helpful, because of its length, particularly as most subroutines are not even running/called, when the freeze happens.
Teensy acts both as Server and client, with a typical Loop() time of less than 40us, increasing to approx.. 150us, when the HueBridge is called for switching. All other processing is faster.
I am using EEPROM at the start to read project dependent parameters. These parameters can be changed trough a WebInterface (not active at this moment), so EEPROM is only accessed during Setup().
There is a singe timer ISR, which reads the KNX Bus (9600baud) every 60ms – an interrupt which takes approx. 300us at most, usually less than 25us. All other information is polled/processed inside Loop().
There is also an Interrupt on Pin 9, triggered when a command is received by RF (pre-processed by a Mini Pro), but that interrupt is very rare, very short and was never activated during those instances of “freeze”.
I am also accessing an OLED display by SDI, once per minute, usually only writing a few characters – an activity which does not happen during the Loop which shows those long freeze.
I have stated my concerns (issue #16) on https://github.com/vjmuzik/NativeEthernet/issues but received no response, hence I try here too, adding some additional information, I collected since then:
Initially (see my description on GitHub), I could detect that calling client.available() [both when acting as server or client] Teensy 4.1 froze for 1786.5ms. Not each time, but infrequently with an average frequency of approx. 1.5 per hour. In other words, NativeEthernet took such long time to provide the number of bytes read by the client.
Since then, for testing purposes, I removed all those connection to servers, which gave long responses, such reading out all data from my two Philips Hue Bridges. In addition, I added many timing markers, allowing me to measure the time different subroutines ran.
It showed me that this 1786ms freeze happens also outside calling client.available(), even outside any subroutine accessing actively at that time the Ethernet port.
I don’t know how NativeEthernet works in detail, I also do not know which house keeping Teensy might do in the background, therefore my current assumption is, that something is going on inside NativeEthernet (or Serial, Serial1, Serial2, SDI), maybe a buffer overrun or similar.
Before undertaking a further strip down to my program, even considering replacing NativeEthernet all together (instead using a SDI connected Ethernet shield), I would very much appreciate if somebody has an idea where I should look first.
Thanks for reading and thanks for any assistance.
The programs does Home Automation, reading data from devices, installed throughout my home, using either Ethernet, KNX (Serial1) or RF (Serial 2). The original program has perfectly worked for several years. The program itself consists of many sub routines, which are mostly short but very project dependent. Posting the complete software here would at this stage not be helpful, because of its length, particularly as most subroutines are not even running/called, when the freeze happens.
Teensy acts both as Server and client, with a typical Loop() time of less than 40us, increasing to approx.. 150us, when the HueBridge is called for switching. All other processing is faster.
I am using EEPROM at the start to read project dependent parameters. These parameters can be changed trough a WebInterface (not active at this moment), so EEPROM is only accessed during Setup().
There is a singe timer ISR, which reads the KNX Bus (9600baud) every 60ms – an interrupt which takes approx. 300us at most, usually less than 25us. All other information is polled/processed inside Loop().
There is also an Interrupt on Pin 9, triggered when a command is received by RF (pre-processed by a Mini Pro), but that interrupt is very rare, very short and was never activated during those instances of “freeze”.
I am also accessing an OLED display by SDI, once per minute, usually only writing a few characters – an activity which does not happen during the Loop which shows those long freeze.
I have stated my concerns (issue #16) on https://github.com/vjmuzik/NativeEthernet/issues but received no response, hence I try here too, adding some additional information, I collected since then:
Initially (see my description on GitHub), I could detect that calling client.available() [both when acting as server or client] Teensy 4.1 froze for 1786.5ms. Not each time, but infrequently with an average frequency of approx. 1.5 per hour. In other words, NativeEthernet took such long time to provide the number of bytes read by the client.
Since then, for testing purposes, I removed all those connection to servers, which gave long responses, such reading out all data from my two Philips Hue Bridges. In addition, I added many timing markers, allowing me to measure the time different subroutines ran.
It showed me that this 1786ms freeze happens also outside calling client.available(), even outside any subroutine accessing actively at that time the Ethernet port.
I don’t know how NativeEthernet works in detail, I also do not know which house keeping Teensy might do in the background, therefore my current assumption is, that something is going on inside NativeEthernet (or Serial, Serial1, Serial2, SDI), maybe a buffer overrun or similar.
Before undertaking a further strip down to my program, even considering replacing NativeEthernet all together (instead using a SDI connected Ethernet shield), I would very much appreciate if somebody has an idea where I should look first.
Thanks for reading and thanks for any assistance.