T4.1 Ethernet Library

The second if statement makes sure you haven’t entered more sockets than FNET is configured to use

Based on this quote, I'd think you'd agree that the conditional of the second if statement has a mistake and should be _socket_num instead of socket_num?



(P.S. Thanks for the contribution of this great library, by the way!)
 
Hi
I tried the example AdvancedChatServer with Teensy 4.1 and Ethernet adapter.
It works OK.
I modify the code to report the remote IP, port and local port and try to connect some clients through TeraTerm:
Code:
EthernetClient newClient = server.accept();
  if (newClient) {
    for (byte i=0; i < 8; i++) {
      if (!clients[i]) {
        Serial.print("We have a new client #");
        Serial.println(i);
        Serial.print("   client IP = ");
        Serial.print(newClient.remoteIP());
        Serial.print("   client port = ");
        Serial.print(newClient.remotePort());
        Serial.print("   local port = ");
        Serial.print(newClient.localPort());
        Serial.println();
        newClient.print("Hello, client number: ");
        newClient.println(i);
        // Once we "accept", the client is no longer tracked by EthernetServer
        // so we must store it into our list of clients
        clients[i] = newClient;
        break;
      }
    }
  }
The response is little frustrated me.
advanced chat session.JPG
Did I miss (do not understand) something?
What also localPort virtual method in EthernetClient class could be?
Thank you.
 
I'm having a strange issue with the Teensy 4.1. My goal is to use the T4.1 to drive ws2812 leds with fastled. The commands will come via E1.31 protocol via ethernet. I have found examples online with this working on T3.1 using both fastled library and the octows2811. I've been trying to port the code to work on the T4.1, but may have to start from scratch. Right now, I have the test sequence working very well if the initTest() is called prior to Ethernet.begin(), or if Ethernet.begin() is never ran. As shown in the code below, the T4.1 will only light the first 33 pixels (99 leds) in the strip. When I place the control code in the loop and send e131 data, I am seeing the same issue that the first 33 pixels respond, but nothing beyond that. Sometimes only the first few leds will respond. It works great without initializing the ethernet, but that defeats the purpose.

I think the issue has something to do with the ethernet interrupt affecting the timing of the light sequence. I tried turning off the interrupts during the led control code, but that isn't making any difference. Does anyone have any ideas as to what else may be causing this? Is this really a fastLED issue? I'm not much of a hardware guy, I understand the concepts, but the nuts and bolts are a bit foreign to me. Thanks for your help.

Code:
#include<NativeEthernet.h>
#include<NativeEthernetUdp.h>
#include <FastLED.h>

#define NUM_LEDS_PER_STRIP 170
#define NUM_STRIPS 2

CRGB leds[NUM_STRIPS * NUM_LEDS_PER_STRIP];

EthernetUDP Udp;
uint8_t mac[6];
IPAddress ip(192,168,1,10);
#define UDP_PORT 4468

void setup() {
  Serial.begin(115200);
  delay(10);
  
  teensyMAC(mac);
  
  Ethernet.begin(mac, ip);
  
  
  LEDS.addLeds<NUM_STRIPS, WS2812, 19, GRB>(leds, NUM_LEDS_PER_STRIP);
  LEDS.setBrightness(100);

  Udp.begin(UDP_PORT);

  Serial.print("Server at IP: ");
  Serial.println(Ethernet.localIP());

  initTest();
}

void loop() {
  //no loop code yet... will process ethernet e1.31 data and control pixel leds accordingly
}



void initTest() //runs at board boot to make sure pixels are working
{
  noInterrupts();
  LEDS.showColor(CRGB(255, 0, 0)); //turn all pixels on red
  interrupts();
  delay(1000);

  noInterrupts();
  LEDS.showColor(CRGB(0, 255, 0)); //turn all pixels on green
  interrupts();
  delay(1000);

  noInterrupts();
  LEDS.showColor(CRGB(0, 0, 255)); //turn all pixels on blue
  interrupts();
  delay(1000);

  noInterrupts();
  LEDS.showColor(CRGB(50, 50, 50)); //turn all pixels off
  interrupts();
   
}
 
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.
 
Tarquinio,

Thanks for the help. I will switch over to the octows2811 library and try that out tonight or tomorrow as time permits. I only need about 30 frames per second, so if you're getting 50, that should work great.
 
bamos,

I am having the same problem as you with the NativeEthernet.h library. I can only control the first 32 leds. Did you find a solution?
 
Alskyline,

I haven’t had much time to work on it in a couple days. I’ve got a test sketch worked up using octows2811. I just haven’t had a chance to get to my bench to test it out. I’ll let you know how it goes, unless you beat me to it and then you can tell me how it goes.
 
Alskyline,

I haven’t had much time to work on it in a couple days. I’ve got a test sketch worked up using octows2811. I just haven’t had a chance to get to my bench to test it out. I’ll let you know how it goes, unless you beat me to it and then you can tell me how it goes.
 
Note what I mentioned previously also... I had do increase the UDP_TX_PACKET_MAX_SIZE constant in the file NativeEthernet.h. The original value on the file was around 30 or something like that. And initially the messages bigger than that size would be capped. That could explain why you are only controlling the first 32 leds. Try changing the variable to a higher number. On a Teensy 4.1 there shouldn't be a problem with low memory. I changed it to 1500 so it would hold a complete ethernet frame and it seems to be working fine.
 
I did make that change to UDP_MAX_PACKET_SIZE, although I was limited to the first 33 nodes (99 leds) even when I wasn’t directly controlling them via Ethernet. I run a test pattern during setup and that was limited also, unless I ran the test pattern before the Ethernet.begin command, then there was no limitation. I do think it has something to do with the interrupts. From what I’ve read, fastled should pause the interrupts while it runs, but it’s not working. I tried placing the fastled code between nointerrupts() and interrupts(), and that didn’t fix it either. I built a sketch last night that uses fastled wrapped around OctoWS2811, and the test sketch operates according to expectations, even when ran after Ethernet.begin. I assume it will work when controlled via Ethernet as well, I just haven’t gotten the code finished up to try it out.
 
I made the change to the UDP_MAX_PACKET_SIZE in the file NativeEthernet.h with no change, I still only get the first 32 LEDs to light up.

bamos, I would be interested how you wrapped the FastLed with OctoWS2811 to make it work.

Here's my test code:

Code:
#include <FastLED.h>
#include <NativeEthernet.h>

// Device Addresses
// MAC address of this device (Use MAC Address Generator app)
byte mac[] = {0x00, 0xAA, 0xBB, 0xCC, 0xDE, 0x4C};
// Unique IP address assigned to device

const IPAddress ip(192, 168, 0, 205);
// Gateway Address
const IPAddress gateway(192, 168, 0, 1);
//Subnet Mask
const IPAddress subnet(255, 255, 255, 0);
//DNS Server Address
const IPAddress dnServer(192, 168, 0, 1);
// IP address of the machine running the MQTT server 

// Global Variables 
// Create an instance of the Ethernet client
EthernetClient ethernetClient;
// Create an instance of the MQTT client based on the ethernet client
//PubSubClient MQTTclient(ethernetClient);
// The time (from millis()) at which last message was published
long lastMsgTime = 0;
// A buffer to hold messages to be sent/have been received
char msg[64];
// The topic in which to publish a message
char topic[32];
// Counter for number of heartbeat pulses sent
int pulseCount = 0;


#define LED_STRIP_PIN             19  // Data for side A LED strip
#define NUMBER_OF_STRIPS          1
#define CHIPSET                   WS2811
#define COLOR_ORDER               GRB
#define LEDS_PER_STRIP             72

CRGB leds_test[LEDS_PER_STRIP];

void setup() {
  Serial.begin(115200);

  ethernetSetup(); //UDP_MAX_PACKET_SIZE 1500 - NativeEthernet.h
  delay(1000);
  
  FastLED.addLeds<NUMBER_OF_STRIPS, CHIPSET, LED_STRIP_PIN, COLOR_ORDER>(leds_test, LEDS_PER_STRIP);
}

void loop() {

  fill_solid(leds_test,LEDS_PER_STRIP, CRGB::Green);
  FastLED.show();
  delay(1000);
  fill_solid(leds_test,LEDS_PER_STRIP, CRGB::Black);
  FastLED.show();
  delay(1000);
  interrupts();
}

void ethernetSetup() { 
  // start the Ethernet connection:
  
  Serial.println("Initialize Ethernet:");
  Ethernet.begin(mac, ip, dnServer, gateway, subnet);
  delay(1500);
 
  
  // print your local IP address:
  Serial.print("My IP address: ");
  Serial.println(Ethernet.localIP());
  delay(1000);
}
 
Hi

I have some issue with DHCPChatServer example of NativeEthernet library.
It works fine with DHCP server however it could not assign the local IP when the DHCP server is not available on network. The LocalIP still left 0.0.0.0.
Does somebody has same behavior or it is just at my configuration?

If I understood correctly the library, when Ethernet.begin(mac, ip, myDns, gateway, subnet); is called in the example the fnet_netif_set_ip4_addr(fnet_netif_get_default(), ip, subnet); {NativeEthernet.cpp, line 288} is never called because the function is returned at {NativeEthernet.cpp, line 285} since the stack already initialized. (https://github.com/vjmuzik/NativeEthernet/blob/master/src/NativeEthernet.cpp)

When I comment out the line 285 the function fnet_netif_set_ip4_addr(fnet_netif_get_default(), ip, subnet) is proceeded and LocalIP is assigned 10.0.0.101. However I sill not connect to it from terminal. This is strange because description of FNET stack said that when fnet_netif_set_ip4_addr() is called the dhcp recourses are released automatically {The DHCP client will be released automatically if an application sets any of the IP-related parameters directly by the fnet_netif_set_ip4_addr() or fnet_netif_set_ip4_gateway() calls.} (http://fnet.sourceforge.net/manual/group__fnet__dhcp__cln.html)

To be able assign local IP the fnet_dhcp_cln_release(fnet_dhcp_cln_get_by_netif(fnet_netif_get_default())); required to call explicitly before fnet_netif_set_ip4_addr(). Only at such way I am able to assign IP address statically after unsuccessful trying to connect to DHCP server.

If somebody else confirm this issue and better understand the library, could one correct the library in such or more elegant way?

Sorry if I misunderstood something and rise false alarm.

Thank you.
 
This library mimics the functionality of the original w5500 Ethernet library so you shouldn’t be using more than one Ethernet.begin function that’s why it returns if you try to call it a second time. There is also already separate functions if you want to manually assign your address after you’ve called begin.

Code:
 void EthernetClass::setLocalIP(const IPAddress local_ip)
{
    fnet_netif_set_ip4_addr(fnet_netif_get_default(), *const_cast<IPAddress*>(&local_ip), subnetMask());
}

void EthernetClass::setSubnetMask(const IPAddress subnet)
{
	fnet_netif_set_ip4_addr(fnet_netif_get_default(), localIP(), *const_cast<IPAddress*>(&subnet));
}

void EthernetClass::setGatewayIP(const IPAddress gateway)
{
	fnet_netif_set_ip4_gateway(fnet_netif_get_default(), *const_cast<IPAddress*>(&gateway));
}

void EthernetClass::setDnsServerIP(const IPAddress dns_server)
{
    fnet_netif_set_ip4_dns(fnet_netif_get_default(), *const_cast<IPAddress*>(&dns_server));
}

If there is an issue with DHCP not being automatically released then I’ll look into it in the next couple of days.
 
This library mimics the functionality of the original w5500 Ethernet library so you shouldn’t be using more than one Ethernet.begin function that’s why it returns if you try to call it a second time. There is also already separate functions if you want to manually assign your address after you’ve called begin.

Code:
 void EthernetClass::setLocalIP(const IPAddress local_ip)
{
    fnet_netif_set_ip4_addr(fnet_netif_get_default(), *const_cast<IPAddress*>(&local_ip), subnetMask());
}

void EthernetClass::setSubnetMask(const IPAddress subnet)
{
	fnet_netif_set_ip4_addr(fnet_netif_get_default(), localIP(), *const_cast<IPAddress*>(&subnet));
}

void EthernetClass::setGatewayIP(const IPAddress gateway)
{
	fnet_netif_set_ip4_gateway(fnet_netif_get_default(), *const_cast<IPAddress*>(&gateway));
}

void EthernetClass::setDnsServerIP(const IPAddress dns_server)
{
    fnet_netif_set_ip4_dns(fnet_netif_get_default(), *const_cast<IPAddress*>(&dns_server));
}

If there is an issue with DHCP not being automatically released then I’ll look into it in the next couple of days.

Thank you vjmuzik.

You did great job with NativeEthernet.

After Ethernet.begin(mac, ip, myDns, gateway, subnet); failed for me.
I tried Ethernet.setLocalIP(ip); before or after server.begin(); statement.
It changed ip reported by Ethernet.localIP(); however something still prohibit PC client to connect Teensy in my case.
 
Make sure you have the Teensy’s IP address set to the same network prefix and subnet as your computer since generally devices won’t connect if they aren’t on the same layer. If you don't have a DHCP server active do you at least have something acting as a gateway so that your computer and the Teensy can locate each other?
 
Make sure you have the Teensy’s IP address set to the same network prefix and subnet as your computer since generally devices won’t connect if they aren’t on the same layer. If you don't have a DHCP server active do you at least have something acting as a gateway so that your computer and the Teensy can locate each other?

Hi vjmuzik

Sorry for long delay for the response

For case when DHCP server is not present I used ASIX AX88179 USB 3.0 to Gigabit Ethernet Adapter with next network settings:
ethernet adapter2.JPG

Thank you
 
Are you connecting the Teensy straight to the USB Ethernet adapter? If so, did you remember to turn on sharing in the Ethernet Properties for that adapter.
 
Are you connecting the Teensy straight to the USB Ethernet adapter? If so, did you remember to turn on sharing in the Ethernet Properties for that adapter.

Yes, I am connecting Teensy directly to the Ethernet adapter. I made isolated network with the adapter and did not allow Internet Connection Sharing in settings. Do you mean this option in your question.
Thank you.
 
Hi vjmuzik

Is the list of suggestion to update the Native Ethernet library?

I would like to ask about two features:
1. When client connect to the server the client’s IP is not set on accept connection (see post 103 in thread). It will be available with first available packet only. Is it possible to have remoteIP available during creating the connection?

2. Is it possible to add ability to choose the server’s port number similar to here: https://github.com/arduino-libraries/Ethernet/pull/39/files

Thank you again for great library.
 
1. I’ll look into it, it’s probably doable if I remember the functions correctly.
2. The change looks simple enough so that should be easy to add, I’ll add it to the list of things to do.
 
Problem using UDP and TCP in the same sketch

Hi. There seems to be an issue when using a TCP and UDP server at the same time. Not sure is this is a known limitation, or a bug... I found it by mistake. I have an application that used a TCP server, recently I changed it to an UDP server, in a different port. I left the TCP server in the code for the time being, even if it wasn't doing anything. But having it there makes many UDP messages I sent to be lost, even if I'm not using the TCP port. I don't need these two servers working for my project, just reporting the behaviour.


Code:
#include <NativeEthernet.h>

byte mac[] = { 0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xED };
IPAddress ip(192, 168, 1, 177);

#define UDP_PORT 4000
#define TCP_PORT 3000

uint8_t packetBuffer[UDP_TX_PACKET_MAX_SIZE];

EthernetUDP Udp;

EthernetServer server(TCP_PORT);

void setup() {

  Ethernet.begin(mac, ip);

  Serial.begin(9600);
  while (!Serial);

  Udp.begin(UDP_PORT);

  server.begin();

}

void loop() 
{
  // if there's data available, read a packet
  int packetSize = Udp.parsePacket();
  if (packetSize) {
    // read the packet into packetBufffer
    Udp.read(packetBuffer, UDP_TX_PACKET_MAX_SIZE);
    Serial.print("Got:");
	for (int i = 0; i < packetSize; i++)
	{
		Serial.print(packetBuffer[i]); Serial.print("  ");
	}
    Serial.println();
  }
  delay(10);
}
 
Hi. There seems to be an issue when using a TCP and UDP server at the same time. Not sure is this is a known limitation, or a bug... I found it by mistake. I have an application that used a TCP server, recently I changed it to an UDP server, in a different port. I left the TCP server in the code for the time being, even if it wasn't doing anything. But having it there makes many UDP messages I sent to be lost, even if I'm not using the TCP port. I don't need these two servers working for my project, just reporting the behaviour.


Code:
#include <NativeEthernet.h>

byte mac[] = { 0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xED };
IPAddress ip(192, 168, 1, 177);

#define UDP_PORT 4000
#define TCP_PORT 3000

uint8_t packetBuffer[UDP_TX_PACKET_MAX_SIZE];

EthernetUDP Udp;

EthernetServer server(TCP_PORT);

void setup() {

  Ethernet.begin(mac, ip);

  Serial.begin(9600);
  while (!Serial);

  Udp.begin(UDP_PORT);

  server.begin();

}

void loop() 
{
  // if there's data available, read a packet
  int packetSize = Udp.parsePacket();
  if (packetSize) {
    // read the packet into packetBufffer
    Udp.read(packetBuffer, UDP_TX_PACKET_MAX_SIZE);
    Serial.print("Got:");
	for (int i = 0; i < packetSize; i++)
	{
		Serial.print(packetBuffer[i]); Serial.print("  ");
	}
    Serial.println();
  }
  delay(10);
}

I'll look into this later on as the issue is probably related to something else I have to fix down the line, but I fear I will have to do a whole redesign of the library that I'm not prepared to do yet. It's something I do plan to do in the future though just because I know there are some adverse effects in certain cases if the library isn't used in an exact sequence or if there are delays that are too long.
 
Back
Top