T4.1 Ethernet Library

The sensor is a rain-detection sensor. I am not sure why writeBuffer.available() would return 0 unless nothing gets written to the buffer as long as there is no rain and no manual polling ...
 
That would make sense but server.available() never returns a client if it doesn't have data available.
 
I hear you ...

I got this code from the sensor vendor's website. The odd thing is that the code works PERFECTLY on a Teensy 4.0.
 
I will get access to the sensor on Monday and of course happy to try anything.

I will change WriteBufferingStream to WriteBufferingClient and will update you.

Thank you.
 
Just getting started with the NativeEthernet library. Installed today's versions of both FNET and NativeEthernet from the GitHub repos. The 'Webserver' example that ships with NativeEthernet works fine, as does 'DhcpAddressPrinter'. When I try to run the 'WebserverMDNS' example I get:

WebServerMDNS:10: error: no matching function for call to 'EthernetServer::EthernetServer(int, bool)'
EthernetServer server(443, true); //Uncomment for TLS

Is there another dependency that I am missing?
 
There isn’t any other dependencies, it’s already preconfigured for TLS to be active. So either it’s not using the new ones you downloaded or the fnet_user_config.h file was changed to disable TLS.
 
@vjmuzik - thanks for taking time to reply. Turns out that it wasn't using the newly installed versions. Sorted now and working as expected. Cheers!
 
Hi,

Trying to have a way to detect if a cable is connected and the link status method doesn't seems to work the way I initially thought.
For me that was detecting if a cable is attached and you have some level of signal on the line.
But it appears that's more to detect if you have an active connection, after having an ethernet.begin call.
Is that the case or it should detect the cable without the call for the ethernet.begin?
For example the link-status example doesn't work apart if you add the ethernet begin before testing for the link.
Particularly annoying when we want a static IP and the library doesn't have a timeout on the begin function...
Added that on my fork if interested.
 
Hi Tarqunio could you share the code you were using?

Best,

Andrá

Hey bamos.

I'm currently also doing a project with teensy 4.1 and led strips controlled via UDP direct messages. I am controlling 300 RGB leds using the octows2811 library and sending UDP messages 50 times a second. It's working perfectly, never had any issue with both things working in parallel. I had do increase the UDP_TX_PACKET_MAX_SIZE constant in the file NativeEthernet.h since the buffer size defines was much smaller than my data size. Just doing that made it all work.
 
Teensy 4.1: Webserver crashes on submit (using NativeEthernet library)

I have a webserver sketch that worked fine on a Teensy 4.0, however, it is crashing on the Teensy 4.1 using the latest NativeEthernet library.

The webserver (code attached) displays a Table and a Submit button. The Table reads and displays variables stored on the micro. That part works fine as before with any browser.

The part that does not work is when I press the submit button on the page. The request received by the Teensy 4.1 is never completed and the server crashes well before it reaches the rest of my code.

I would appreciate the community's help is to what may be causing that?

Thanks in advance.
 

Attachments

  • TTC_WS2.zip
    4.2 KB · Views: 88
  • webserver.jpg
    webserver.jpg
    43.9 KB · Views: 111
First of all, thank you vjmuzik for this library, it works great.

I am using the library in a closed loop control application. I am listening to the commands by polling and parsing the packet in the main loop. Once the packet size has the right size, I read it and process it.

Code:
 int packetSize = Udp.parsePacket(); 
 if (packetSize==40){ 
Udp.read(recvbuf, UDP_TX_PACKET_MAX_SIZE);
/*decodes the message and respond*/
}

This works fine, but I am experiencing slight jitter in the roundtrips, that I attribute to this polling.
I wonder however, is there a way to fire the interrupt whenever the packet arrives, instead of constantly polling and parsing the packets?
 
Due to the nature of this wrapper library the performance will never be fully optimal. If you need more precision over what’s going on you will have to learn FNET and make a service for what you want to do. FNET services are handled automatically in the background pretty much as soon as a packet arrives. So from within your service when a packet arrives you just have it use a callback function that triggers your interrupt. In the future when I start doing more Ethernet things I may make an addon to NativeEthernet that simplifies the process of a making a service. But, the caveat is people will have to relearn how to make Ethernet sketches since any tutorial for Ethernet.h wouldn’t be valid when you are making it non-blocking.
 
Thank you for your explanation. Please keep us posted if you make any progress on that, I am pretty sure many of us would be interested!
Relearning how to use such a library is the least of a problem.
 
Have 2 Teensy 4.1 connect via Ethernet crossover cable. One transmitting UDP multicast packets and the other receiving. Using a scope on persistence to measure jitter and it works as expected. Packet time on wire plus about 30 usec to get data via parsePacket and read. The scope shows about 5 usec of jitter. However after 2-3 minutes will get 40-50 usec jitter excursions every 200 packets. Have tried changing packet sizes and time between packets but the same effect occurs. Goal is to have less than 10 usec of jitter a 1400 byte packet sent every millisecond. Any thoughts about what is causing this?
 
As a shot in the dark I would think either other interrupts could be causing it or just the nature of how NativeEthernet is working. If you work direct with FNET you don’t have to poll for the packet like you used to have to with a W5500 that’s being mimicked here. Here’s this from earlier today:
Due to the nature of this wrapper library the performance will never be fully optimal. If you need more precision over what’s going on you will have to learn FNET and make a service for what you want to do. FNET services are handled automatically in the background pretty much as soon as a packet arrives. So from within your service when a packet arrives you just have it use a callback function that triggers your interrupt. In the future when I start doing more Ethernet things I may make an addon to NativeEthernet that simplifies the process of a making a service. But, the caveat is people will have to relearn how to make Ethernet sketches since any tutorial for Ethernet.h wouldn’t be valid when you are making it non-blocking.
 
Thanks to @vjmuzik for making this lib! It's saved me a lot of time, but has also caused me some grievances so I thought I'd share what I've learned to help others.

I have a very simple machine to machine setup (T41 to Win10 pc). For a whole day, the setup worked flawlessly, but suddenly it stopped working. The code was looping at this point and never returned:
https://github.com/vjmuzik/NativeEt...2fed8bded1cd73a69/src/NativeEthernet.cpp#L293

Since this is a tight loop, it caused a "hang" that forces you to click the Reset/Program button on each upload. To me this seems to be an incorrect way to do this. How can "link_status" be updated if the Micro is stuck in that loop? I would suggest that this while-loop is removed and that one rather change the example files (such as UDPSendReceiveString.ino) from this:

Code:
  if (Ethernet.linkStatus() == LinkOFF) {
    Serial.println("Ethernet cable is not connected.");
  }

to something like this:

Code:
  while (Ethernet.linkStatus() == LinkOFF) {
    Serial.println("Ethernet cable is not connected.");
    delay(100);
  }

Now why did this work initially and then start to happen? It seems the PHY needs to be initialized right away. My code had a 3 second delay at the start to allow for my OPENCAN setup to wakeup & sync before starting the Ethernet interface. Turns out this won't work and it will prevent the PHY from ever starting. Initializing Ethernet first solves this problem.
 
Just getting going with NativeEthernet on T41. So far I seem to be figuring it out....if slowly.

Here's a hopefully easy question related to Ethernet.begin() calls:

If I use this (passing mac only), everything is fine:

Code:
  if (Ethernet.begin(mac) != 0) {
    IPAddress myIP = Ethernet.localIP();
    Serial.printf( "IP Address %u.%u.%u.%u\n", myIP[0], myIP[1], myIP[2], myIP[3] );
}

however, if I call Ethernet.begin(mac, ip) - adding the static IP address, the compiler throw errors:

Code:
  if (Ethernet.begin(mac, [B]ip[/B]) != 0) {
    IPAddress myIP = Ethernet.localIP();
    Serial.printf( "IP Address %u.%u.%u.%u\n", myIP[0], myIP[1], myIP[2], myIP[3] );
}

I get this compiler error (that I don't understand):
Arduino: 1.8.13 (Windows 10), TD: 1.53, Board: "Teensy 4.1, Serial, 600 MHz, Faster, US English"

LED_Side_T41_v3: In function 'void setup()':

LED_Side_T41_v3:59: error: invalid operands of types 'void' and 'int' to binary 'operator!='

if (Ethernet.begin(mac, ip) != 0) {

^

invalid operands of types 'void' and 'int' to binary 'operator!='


I was expecting Ethernet.begin() to return Success/Failure regardless of the number of arguments, but clearly I'm not understanding something.

I also realize that in my second example I'm asking for the IP address back when I just set it explicitly, I'm doing that just to check that it worked correctly.

What have I missed?
 
When you provide a static IP there is no return function, therefore when you try to != 0 it throws an error since there is no value to compare. When you only give it a MAC address it does provide a return value because that shows whether or not it obtained an IP address.
 
When you provide a static IP there is no return function, therefore when you try to != 0 it throws an error since there is no value to compare. When you only give it a MAC address it does provide a return value because that shows whether or not it obtained an IP address.

Understood. Thanks!
 
When I send a html page which size is more than 2000 bytes, my Teensy 4.1 gets stuck. Reducing the page to below 2000 bytes work ok. I'm not sure if it because of the Native Ethernet library or coming from another part. Do you guys know if there is a buffer somewhere I can configure to have more than 2000 bytes?
To store the html data, I'm using: const char* document = R"rawliteral(data ... data)rawliteral";
 
Hi,

Trying to have a way to detect if a cable is connected and the link status method doesn't seems to work the way I initially thought.
For me that was detecting if a cable is attached and you have some level of signal on the line.
But it appears that's more to detect if you have an active connection, after having an ethernet.begin call.
Is that the case or it should detect the cable without the call for the ethernet.begin?
For example the link-status example doesn't work apart if you add the ethernet begin before testing for the link.
Particularly annoying when we want a static IP and the library doesn't have a timeout on the begin function...
Added that on my fork if interested.

xoxu, I'd like to see your fork, can you point me in that direction?
 
I have code that runs on a Teensy 3.2 with Wiznet via SPI and wanted to run the exact same thing on a Teensy 4.1 with the mag jack.
The Udp Data I am sending is a structure complete with 0s, so I have to use write(data, size)
This code works fine with the teensy 3.2 and I have

#ifdef ARDUINO_TEENSY41
#include <NativeEthernet.h>
#include <NativeEthernetUdp.h> // UDP library from: bjoern@cs.stanford.edu 12/30/2008
#else
#include <SPI.h> // needed for Arduino versions later than 0018
#include <Ethernet.h>
#include <EthernetUdp.h> // UDP library from: bjoern@cs.stanford.edu 12/30/2008
#endif

In my header file.

short ethsend(char *output, short size)
{
short wrote = 0;
unsigned short i;

//sprintf(text, "Packet Out size %d", size);
//Debug.println(text);

// send a reply to the IP address and port that sent us the packet we received
Udp.beginPacket(Udp.remoteIP(), FlairPort);
//wrote = Udp.write(output); // Works but stops at the first 0
wrote = Udp.write(output, size); // Works maybe one or twice and then freezes

//for (i = 0; i < size; i++)
// Udp.write((uint8_t)output); // Also not working as above


Udp.endPacket();

return wrote;

}

Also I asked before about running 2 Ethernet Jacks but no replies. How about one 4.1 magjack and also an SPI one? Would the 2 libraries conflict?

Thanks,

Simon
 
Back
Top