Search results

Just to close the loop, the sentence, "While looking at the initialization code in Entropy.cpp I noticed that the library explicitly overrides the value of TRNG_DEFAULT_ENTROPY_DELAY" made it sound like @Karol found it already present in the Entropy library. Perhaps there's some older or newer...

A while back, when I was writing my own take on using the TRNG to avoid having to include the Entropy library in the QNEthernet library, I encountered two sets of parameters: the one in the Entropy library and in older versions of the NXP SDK, and different parameters in newer versions of the...

Individually addressed.

All the files are up for the latest Teensyduino 1.60 release. (It often takes the PlatformIO folks a little time to get the latest release up, so I'm providing this as a convenience.) All the platforms are listed below; just copy & paste into your platformio.ini file. I like to put it just...

May I suggest trying it with the QNEthernet library and see if you can connect? Happy to provide some guidance if you need. Note that I'm not suggesting permanently switching, because the regular "Ethernet" library is probably a little faster. (It just doesn't have as many features. 😝) If...

You can get ARM builds of later toolchains. That's what I use. I'm on 14.2.1. (Not a later one because they're not providing versions past that for Intel Macs.) https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads Look for "macOS (Apple silicon) hosted cross toolchains". It looks...

Similar to the betas I've been hosting, I made a version for the latest 1.60 release. See this post (#22), and remove the "-beta6" parts: https://forum.pjrc.com/index.php?threads/how-to-add-a-teensyduino-beta-release-to-platformio.71730/post-364847 Note: for the tools, I only added the Mac...

If I'm not mistaken, I believe there's special chips you can get that adds jitter to the output. I know of at least one company that did this in their LED driver product so that they could pass noise certification.

@Karol where are you seeing the TRNG_DEFAULT_ENTROPY_DELAY modification in Entropy.cpp? Here's a copy of the latest version, from Teensyduino 1.60: https://github.com/ssilverman/teensy_betas/blob/teensy_1.60/framework-arduinoteensy/libraries/Entropy/Entropy.cpp

I saved about 21GB! Thanks, @KurtE!

Thanks, @jshaw3. Welcome to the thread! :) Here's an update: So I got all the equipment I thought would cause the issue, but I couldn't reproduce it. So I reached out to my customer and he said that the "Ethernet drop" happened when the sACN packet transmission was stopped. I tried this by...

@thomj I just added driver_reset_phy() to the latest in GitHub. Could you try that instead of driver_restart_auto_negotiation() and see if it solves the problem?

There’s a small spelling mistake here: “One unfortunately side effect is we had to discontinue” I believe this should be “unfortunate” instead.

Try calling flush() on the client after writing data if you’d like it to get sent immediately. There’s no need to delay() or yield(). TCP buffers will get sent either after a timeout, about 250ms, or after a flush. See also...

What about adding an implementation of __gnu_cxx::__verbose_terminate_handler() somewhere for reduced code size when using non-smallest build options? Then again, it's not really a "serious bug". Here's what I do in the QNEthernet library: #if QNETHERNET_PROVIDE_GNU_VERBOSE_TERMINATE_HANDLER...

[...two days later...] [again, in a French accent] I believe I've solved it this time. I'm now seeing speeds greater than 19Mbps over the "direct" link (Belkin Ethernet USB-C adapter). I'm using much more aggressive buffering. Also, I'm leaving the interface's MTU at 1500. The text below is...

Could you try setting your Ethernet port’s MTU to 1400 and see what happens? And then 1280.

@PaulStoffregen I changed the MTU for the network the Teensy is attached to (Belkin adapter) to 1280 and then to 1400, down from 1500. The speeds are dramatically improved, like by a factor of 10. Would you be willing to try that? I also tried some other experiments where I lowered the MTU on...

Another issue I'm experiencing is that ping doesn't work. I haven't dived too deeply using Wireshark or anything, but I'm just not seeing ICMP Echo Reply packets after sending multiple pings out the Teensy/W5500.

I wonder if restarting the PHY is the solution, rather than just restarting auto-negotiation. Once I can duplicate the problem, I'll experiment with that too.

A Friday update: I'm still in the process of acquiring parts to duplicate the setup. (The setup that was experiencing problems was already shipped to the show.) I have the same 24V power supply, same WS2814 24V LEDs, and same 12/24V-to-5V voltage converter. Now I'm waiting on some other parts...

For posterity, here were my results from yesterday with the Teensy->W5500 (WIZ850io)->eero node->wireless->Mac laptop: ------------------------------------------------------------ Client connecting to 10.0.0.21, TCP port 5001 TCP window size: 128 KByte (default)...

Was this W5500 measurement with the latest on github?

Interesting. Thanks for having a go at that. I think I was seeing upwards of ~11-14.7Mbps with the Teensy->Wiznet->eero->wifi setup, and about the same speeds as you’re seeing when using the wired adapter. Both tests with 30MHz SPI. Something’s up with the Wiznet module and wired Ethernet...

I finally found the issue!! :) Well, issues. ...five days later... [In French accent] I tried everything I could think of, from different Ethernet-USB-C adapters to a multitude of adjustments to the code, to different packet sizes, to examining the iperf protocol (the iperf2 code is hard to go...

I use it very frequently (for both commercial and non-commercial projects) and it’s very stable. There are lots of additional features in the QNEthernet library that other Arduino-style libraries don’t have. It can be installed via the Arduino IDE, but my preference is to use PlatformIO. The...

…but they both require at least one or two register reads (without an actual interrupt line): either just the size available or, with interrupts, the interrupt register and then the size register. We probably have the same W5500 module; I’ll see if the interrupt line is connected…

Polling. I should try out the interrupt approach…

Here's an update with the QNEthernet W5500 driver: I've been trying to improve it by focusing on receive buffering. Instead of reading one frame at a time from the chip, I'm now reading and buffering the chip's whole RX buffer, which may contain multiple frames. This requires fewer accesses over...

Definitely update to Teensyduino 1.60-beta6. There were lots of fixes. I’m not actually sure if it will impact your project, offhand, but try it.

Yep. Paul’s Ethernet library is the way to go for speed, with a W5500. I think the reason the QNEthernet library’s W5500 driver is so slow is because it uses that MACRAW mode. I use it for raw frames only and provide the TCP/IP stack on the CPU, as well. (I’m still going to dig in some more...

Agreed. Probably due to the raw frame processing, would be my best guess.

Some additional guidance: If you happen to look at driver_w5500.c: 1. PHY initialization in driver_init() (and then low_level_init()) 2. driver_proc_input() polls for input frames 3. driver_poll() is called regularly to check link status 4. driver_outputl() is used to send frames (sendFrame())...

Steps: 1. Uncomment QNETHERNET_DRIVER_W5500 in qnethernet_opts.h 2. Change any parameters you need in qnethernet/drivers/driver_w5500_config.h 3. Build and run the IPerfServer example as normal Depending on your setup (for example, my tests were done with a direct connection to my laptop via an...

I'd like to report absolutely dismal performance with QNEthernet/W5500/IPerfServer example (note: the driver uses MACRAW mode): I'm seeing about 350 Kibps. That's at 30MHz SPI. At 14MHz, < 200 Kibps. I tried with both interrupts enabled (not the default) and without (kSocketInterruptsEnabled in...

I can have a look more tomorrow. Do you feel like trying out the original version with QNEthernet plus its W5500 driver? You should only need to uncomment “QNETHERNET_DRIVER_W5500” in the qnethernet_opts.h file.

Just another reminder that something changed with the iperf 2 protocol so, for example, the “-r” feature doesn’t work anymore. It’s on my to-do list to figure out.

I got it compiling. There were two issues: 1. ntohl(), et al, may already be defined somewhere, so I wrapped those in #ifndef/#endif pairs. 2. I don't quite understand why yet, probably something to do with sometimes-weirdness of Arduino.h internal #defines or includes or reordering or forward...

@PaulStoffregen, working on it now...

Sorry, what I meant was what protocol did you use? Iperf has its own protocol that needs to be parsed. I was wondering where you got details on parsing the iperf stuff.

@istrateandrei26 I'm curious which code you used to handle the iperf protocol when you were testing?

Thanks! Yes, it works quite well, but over the last year or two, something changed in the iperf (v2) protocol, so a few features that used to work when I wrote it have changed somehow. Also, the documentation I had to work with was the source code, which kind of sucked. The unidirectional tests...

May I suggest trying to duplicate their results? That may provide insights on what they’re doing.

Apparently, I posted about this before: https://forum.pjrc.com/index.php?threads/add-option-to-teensy-loader-to-set-utc-time-and-not-local-time.77042/ The salient link: https://pubs.opengroup.org/onlinepubs/9699919799/functions/gettimeofday.html It specifies that gettimeofday() should return...

When Teensy Loader uploads some firmware, it also sets the Teensy's clock. The value it's sending is incorrect. It looks like it gets the current system time from the computer and then adds the time zone offset. For example, it's about Wed Feb 4 9:40AM GMT-08:00 now, which corresponds to...

Which Ethernet library are you using? Because you’ve done some iperf measurements, I’m guessing QNEthernet? (IPerfServer example.) Assuming that’s true, the reason may be due to how the W5500 driver is written. It uses raw frames and the lwIP stack handles everything. Other W5500 drivers...

The updates through the Arduino IDE don’t usually propagate for a day or so.

I just released v0.34.0. Here's the Changelog: ## [0.34.0] ### Added * Added tests for some of the print utility functions and classes. * Added the `QNETHERNET_ENABLE_PING_REPLY` macro to disable ICMP echo replies. * Added a "Requirements" section listing some library requirements to the...

I just realized that all the driver functions are included in <QNEthernet.h>. There’s no need to do that forward declaration.

Update: It's been a few days, and I haven't seen the Ethernet freeze since implementing the renegotiate-on-link-down fix. It seems to be working. Here's some sample code (with a bonus abortAll() call): #include <QNEthernet.h> using namespace qindesign::network; // Forward declare this extern...