Search results

I’m going to bookmark this thread and point to it in the future because it’s a perfect example of why including some code in one’s question will very possibly lead to a solution much more quickly.

I was suggesting to not use the threading library. Please clarify one point: did you want blocking behaviour or not? I’m unclear from the description.

What happens if you don’t use threads? I.e. call functions one after the other, and if any need to be done periodically, use time measurement.

I was making a PR for the Arduino_ConnectionHandler project (https://github.com/arduino-libraries/Arduino_ConnectionHandler/pull/128), and the build complained (just a warning) that AVR platforms aren't supported. That finally pushed me to write this post because I've been thinking about this...

I’ve seen these once or twice too over my Teensy dev lifetime.

One basic thing I noticed is that you're accessing client.operator bool() from several different contexts. The state may be indeterminate, especially since you're copying into the object from outside the ISR with client = server.accept();, and the ISR may get triggered in the middle of that...

Fun fact: I've added a way in the QNEthernet library to redirect stdout and stderr. There shouldn't be a need to follow the mentioned link above (https://forum.pjrc.com/index.php?threads/how-to-stdio-printf-scanf-stdout-stderr-stdin-fgetc-etc.68846/). Here's how: 1. Set QNETHERNET_CUSTOM_WRITE...

Here's a minor-fix PR: 1. Make some minor fixes to CrashReport CFSR messages #716 Here's some fixes discovered with "-Wextra": 1. Fix some "cast between incompatible function types" warnings in usb_midi #694 2. Fix an "implicitly-declared copy assignment operator" warning #693 3. Fix a couple...

Hello. Just seeing if there are any Teensy LC’s out there.

I think I’ll start a new thread… I did see that you had run out, per post #4. For some reason I thought using this thread would be more efficient.

I could use a few Teensy LC’s if anyone has any more.

I meant <cstdio>, not <stdio.h>.

The printf() functions should normally warn you when the parameter type doesn’t match, for example “%lu” and time_t, which should be “%llu”. However, the Teensyduino implementation of the Print interface (which contains a printf(), and is the one called by Serial.printf()) doesn’t enable this...

Here's a version without the VLAN processing: // C++ includes #include <algorithm> #include <QNEthernet.h> using namespace qindesign::network; // VLAN EtherType constants constexpr uint16_t kEtherTypeVLAN = 0x8100u; constexpr uint16_t kEtherTypeQinQ = 0x88A8u; // Tracks the received frame...

See this thread where I post how to use the QNEthernet library to do raw frame processing without an IP stack: https://forum.pjrc.com/index.php?threads/thoughts-about-extremely-low-overhead-and-low-bitrate-communications-on-teensy-4-1.75719/post-349254

Good news is that you shouldn't have to do all this work yourself. I've designed the QNEthernet library to work without an IP stack, and with an "EthernetFrame" API similar to the "EthernetUDP" API. In other words, you can easily use the library with just raw frames. Here's how: 1. In...

First point is that the following will also work, without the use of #ifdef's: bool poll() override { yield(); return static_cast<bool>(server.available()); } EthernetServer::available() returns an instance of EthernetClient. EthernetClient defines a bool operator (see...

Did you mean to use elapsedMillis in your code instead of elapsedMicros? Update: it was changed.

Side question: do you happen to have a fuse connected to the LEDs? It’s good practice. See:

The API should practically be the same. I made QNEthernet follow the Arduino-style Ethernet API. Can you show an example of some compile errors? Sounds like, however, you’ll be switching to UDP… Check out the BroadcastChat example.

The inline specifier allows a definition in a header included in multiple places, and the compiler will ensure there’s only one defined.

If you put inline in front of the variables then you can leave them in the header: inline TransmitPacketType transmitPacket; inline ReceivePacketType receivePacket;

When I have a chance, I can show you how to force 10Mbps in the PHY.

The Teensy should be able to auto-detect the connection. Some questions: 1. What happens in summary point #1 if the PC is set to 100Mbps? This will indicate whether “over robot wiring” is doing something to the signal. 2. What does “over robot wiring” mean exactly? For example, is there a...

See the new SimpleHTTPClient example (via GitHub) for a client example, and one of the server examples for a server example. Note that the examples may be a little more complex than you need, but they still illustrate some good points.

I’d actually suggest a bunch of changes, but I think you could get it working minimally by replacing those three includes (SPI, Ethernet, EthernetUdp) with <QNEthernet.h>. And then install the QNEthernet library.

I’m glad you figured it out. I rely on things like what I put in post #5 to get the actual sizes of objects. The teensy_size output only gives you a rough idea.

Serial.println(sizeof(KBindex));

Can you show your program? I don’t know how you’re getting the size. Are you using the sizeof operator?

Try uint16_t for the type.

I just added a "SimpleHTTPClient" example.

I’m not sure what it is that “routers do”. I’m not aware of things other than arp and maybe IGMP things. If you could find that out, maybe I can help. Try version 0.29.1 and see if it makes a difference.

Post #21 describes how the main system calls your setup() and loop(). It’s a description of what’s happening under the hood; it’s not what you need to do, nor might it be exactly the same as what’s actually there. The gist is that your setup() is called once and your loop() is called repeatedly...

See this post: #21 You don’t need to call yield() at the end of loop(). Can you define these terms: invisible in the network, isn’t visible on the clientlist. For example, what does it mean for a connected device to be “visible”? Do you mean a DHCP list? An mDNS services list? Something else...

Some more ideas I’m thinking about: 6. A set of functions that do the things that are very repetitive when starting, and creating, an Ethernet-based app. (I have many thoughts about this for better Arduino app development too.) (Remember Borland’s OWL framework?) (I don’t want to get too far...

Sure, I can include an HTTP client. I’ll probably do it a little differently, though. Other changes I’m planning: 1. Decouple the driver initialization from setting the MAC 2. Add a small capabilities API for determining what the driver supports 3. Not sure when or if — support for a more...

I just released v0.29.1. Here's the Changelog: ## [0.29.1] ### Fixed * Fixed being able to process more than one incoming frame in a row in the driver. Highlights: * Fixed a throughput problem. Link: https://github.com/ssilverman/QNEthernet/releases/tag/v0.29.1

I believe I’ve fixed the throughput problem. Thanks to @bicycleguy for helping me diagnose. I’ll be spinning a new release soon.

I think this discussion might be better moved to a QNEthernet library issue on the GitHub repo. (Or a different thread here. Reason being findability, one-thing-per-discussion, etc.)

What happens if you connect the Teensy to your computer directly (and assign a static IP or something) instead of going through a router?

In fact, just to be sure the library isn’t there after removing it, try to compile your program and observe that it doesn’t compile, for each uninstall of the library.

@bicycleguy I'm still having trouble duplicating the issue. I have a request: Can you provide a small program that demonstrates the problem with UDP? (#224) On the subject of receiving the "Host:" header, the close request might not be complete, and the Arduino-style client API can still return...

Thanks for the additional info. I’ll have a deeper look at this when I have a chance.

@bicycleguy what happens if you use client.close() instead of stop()? stop() waits until closed.

Thanks for that clue. At first glance, the “Host:” line should be there because HTTP 1.1 clients are supposed to send that. I’m just surprised that “Host:” line isn’t there for the 0.28.0 version. I wasn’t looking closely at the serial output before, just the timing. Your program prints the...

Just to clarify, I’m not saying you’re wrong, just that I haven’t yet figured out a way to duplicate the issue on my network.

The underlying link appears to be broken. Here’s the correct link: https://forum.arduino.cc/t/teensyduino-error-library-arduino15-packages-teensy-hardware-avr-tools-arm-bin-arm-none-eabi-g-no-such-file-or-directory/1160214/2

I changed to 24MHz for the same curl tests I did above, and v0.29.0 is a hair faster than v0.28.0. I'm seeing approx. 40-something milliseconds on v0.28.0 and 30-something milliseconds on v0.29.0.

I also just ran the test suite (pio test -v -e teensy41-test -f test_ethernet). The results: 1. 0.29.0: 40.905s, 27.365s, 26.836s 2. 0.28.0: 41.173s, 27.210s, 27.721s I'm seeing that 0.29.0 is just a smidgen faster from this and from timing the curl test above.

I did some rudimentary testing: 1. Copied the code into the Arduino IDE (2.3.2) and made no modifications 2. Installed QNEthernet 0.28.0 3. Ran this a bunch of times: time curl http://192.168.1.10 (replace with your Teensy address) 4. Saw times between 30 and 50 milliseconds, with the occasional...