Teensyduino 1.54 Released

Status
Not open for further replies.
Something may be limiting your network connection, like I said I’m pretty much directly connected to my laptop and see no issues. If I remember right Apache Benchmark said it was doing about 300 requests per second. The only oddity on my end was that very rarely the benchmark itself wasn’t sending out a request until 20-30 seconds from the previous one. Though I’ve confirmed with Wireshark that that had nothing to do with the Teensy side of things.
 
I'll do some more testing tomorrow. Seems odd, but really I have no idea what Apache Benchmark is doing. Can you tell us what you are testing, and how this test relates to the problems that NativeEthernet users have been experiencing?
 
There was a problem with the TCP Server code in NativeEthernet running out of sockets and effectively making the Teensy lock up eventually. A partial solution for that has been sitting on the back burner for awhile because it didn’t really solve the underlying problem that was causing it in the first place. Basically when a Client connected to the Server the initial data was being lost where it shouldn’t have been so it stopped the Server code from returning with the connected Client and the socket being opened forever. I finally found the part in FNET where the data was being lost though I couldn’t find why it was triggering it to throw it out. So as an experiment I just got rid of that specific check and it seems to have fixed it, though I don’t know if there are any side effects. What I am testing for is whether or not this fix is really a fix or if it’s causing any unforeseen side effects and if I need to dig further. The provided sketch was just the fastest way that would trigger the fail condition, but I know others have experienced it with their own TCP Server sketches and have reported as such.
 
Okay, but is the problem specific to HTTP, or could it be a simple TCP server? I did a comparison between the FNET stack in butok's repository versus the one in TeensyDuino, and I was surprised there were so many differences. Are the differences all related to supporting the standard Arduino API, or is it more complicated than that? My simplistic assumption was that since FNET supports iMXRT, the changes required to the FNET stack would be smaller than they are.
 
This isn’t specific to HTTP, though the first note of it happening was when someone wanted to stress test HTTP with Apache Benchmark. It does happen with any TCP Server as Paul and some others have tested before. The changes to FNET are relatively small, a lot of stuff that was unnecessary was deleted (mostly support for other processors). The core code is pretty much untouched as far as I remember, for the Teensy support most of it consisted of stripping out code that would overlap the Teensyduino core and cause issues. I may have made some minor changes when I was working on USB Ethernet, but I don’t remember doing anything significant.
 
Thanks very much for the info. The reason I ask about changes to FNET relative to butok is Paul's comment that the crash issue was "deep within FNET". That struck me as odd, given that FNET is used by a lot of platforms other than Teensy, so if there was a fundamental problem in FNET, it seems like it would get fixed. Did I understand correctly? If there are problems in FNET, do you think they are in butok's repository, or are they related to Teensy-specific changes to FNET?
 
Yes I think, if there is a problem, butok is the one who should/can fix it.. but that's unlikely if nobody tells him about...
 
It’s a weird problem since it happens at random, even with the exact same data, in FNETs examples those particular sockets with no data were closed so if you were to make your own example based off of those you wouldn’t really notice them. Most of the time this doesn’t cause issues since programs should just try to connect again, but I’ve ran into a particular program that would refuse to connect again since this is seen as an error. Before I made NativeEthernet I did run into it, but I couldn’t figure out the specific issue since my example was based off of one of FNET’s and so the problem socket was closed. Based on Wireshark I could see the TCP socket got the data but it never arrived at the sketch level. I didn’t look into it much at the time since it was such a rare occurrence I had no way of repeating it and more so wrote it off as some kind of error with the USB Ethernet driver I made. So being that FNETs examples have a specific check for this kind of error I’m inclined to believe it’s a problem in FNET. Though like I said it’s a really weird issue that seems to arise with a corrupt TCP frame of sorts, normally the socket receive is closed and that frame discarded. Being that the socket receive was being closed off that was what was causing issues so I commented out the lines that would do that, but left the part where it discards the corrupt frame.
 
vjmuzik, can you point me to an FNET example that checks for the error? I would like to help if I can. For myself, I wouldn't feel good about going to butok with this problem because I know so little about how FNET was modified for Arduino/Teensy. I've tried to review the differences between butok's latest code and the latest FNET for Teensy, but the differences are too great to get my arms around it. I've starting thinking about a new port of FNET to Arduino/Teensy. Do you think that would help? I would be willing to give it a try, or at least get the ball rolling. Famous last words.
 
The example I mainly used is the HTTP Server example here, I'll try to explain the check that is done there in short order since it is rather long to follow without knowing what to look for.

After a client connects it will first try to read the data that a HTTP client sends(since a client is expected to send the first data and not the other way around) and check if it received any data.
Code: 
                        if((res = _fnet_http_srv_recv(session, ch, 1u) ) != FNET_ERR)
                        {
                            if(res > 0) /* Received a data.*/
                            {

In the case that it doesn't receive any data it then will check against a timeout to see whether or not it should close the socket for taking too long, if it's not time yet it will try to read for data again until it is time.
Code: 
                            /* No data.*/
                            else if((fnet_timer_get_ms() - session->state_time_ms) /* Time out? */
                                    > FNET_HTTP_SRV_WAIT_RX_MS)
                            {
                                session->state = FNET_HTTP_SRV_STATE_CLOSING; /*=> CLOSING */
                                FNET_DEBUG_HTTP("HTTP: Timeout.");
                            }

This timeout is what would catch the problem sockets and close them, it's the same thing I tested and implemented in NativeEthernet when first trying to solve this issue and is what's in the newest commit. Being that NativeEthernet is blocking in nature this timeout would stop your sketch while waiting for data to hopefully arrive and based on my own testing anytime the timeout was triggered nothing would ever arrive. This didn't really sit right with me as a decent fix so it was never committed at the time I first tried to find the issue and based on Wireshark I could see that the data was making its way to FNET so there should've been no reason that the socket would say no data was received. Although the timeout shouldn't be necessary anymore if the fix for FNET works without issues it's still in NativeEthernet just in case.

I also see no reason to make a new port, despite what GitHub may lead you to believe there aren't as many changes to the core code as it seems, a significant amount of the deletions are from removing unnecessary support for non-Teensy products and a good chunk of the additions are from a folder rename that it didn't properly match all the files to.
 
Thanks for taking the time to explain. Since it's in one of the FNET examples, and you understand it well, what do you think about Frank's suggestion to ask butok about it?
 
@vjmuzik
Downloaded your latest NativeEthernet and FNET libraries. Some server code that attempts to load a bunch of j-script and pictures now works much better. It was having problems where it seemed to miss requests from the client. A page with a bunch of large pictures would load fine but a page with a bunch of small thumbnails would miss half of them.

Now sometimes there is a pause and a 'No data available , closing socket' message at the terminal, but then the missing files will appear. Before they would never show up.

Now, however, when TLS is enabled it hangs. None of the T4.1 examples work with TLS enabled. I had already enabled insecure browsing (because I don't have a valid certificate) on that IP from when it was working so I don't think that's why but who knows? Have you tried TLS?
 
Last edited:
So I installed the TD1.54 release with the IDE 1.8.15. Installed the latest version of the MTP library.

Made the modification to the core.

Selected the MTP disk from the pull and compile/downloaded the mtp-test.

But there is not serial support.

I thought the point of the modification was to have serial support but I do not see this pop up on the pull down menu to select?

Am I missing something?

Thanks

Bruce
 
If by you mean that you don't have the option to have MTP with Serial ...

If that is the issue you need to follow the instructions in the readme file:
Code: 
- If you wanted to use USB_MTP_SERIAL  
   - T4.x edit teensy/avr/cores/teensy4/usb_desc.h with content of 'modifications_for_cores_teensy4' (insert after USB_MTPDISK)
   - T3.x edit teensy/avr/cores/teensy3/usb_desc.h with content of 'modifications_for_cores_teensy3' (insert after USB_MTPDISK)
   - edit teensy/avr/boards.txt with content of 'modifications_for_teensy_avr' (copy to end of file)

Note with the boards.txt - I follow an alternate way and that is to copy the contents of that file mentioned into a new file (same location as boards.txt)
And name that file: boards.local.txt
 
Ahh...missed that part. I know I was missing something from what I did before but thanks for the reminder and quick reply.
 
BOBILLIER said:
It will be easier if previous versions links are directly on website.
Click to expand...

Maybe, but it would probably have to come with a bunch of caveats... Like it might not fully undo the effects of undoing what was changed/added by a later install.

That is for example if this release puts in a new library, it will likely still be there after you install an older version of TD...

@Paul/@defragster - Wondering if maybe the thread: https://forum.pjrc.com/threads/6497...hread-Subscribe-for-notice-of-future-releases
Should in addition to having links to the download page, maybe should have copies of the links for that release...
That is The thread still shows stuff about 1.54, but the link takes to to 1.55...
 
@Paul/@defragster - A wish too: It was good if the installer include the version in the file name : Ex Teensyduino_1.55.exe
 
I'm not planning to change the software filenames or build process or website structure, at least not anytime soon.

The reality we face today is a huge backlog of important software work that languished during the pandemic, which came on the heels of having already put off a lot of important software features while developing Teensy 4.0 in 2018 & 2019 and Teensy 4.1 in late 2019 to just as the pandemic hit (Teensy 4.1 started shipping in May 2020).

Teensyduino has a pretty complex build process, using many scripts and manual steps across 4 computers, 2 SBCs and 3 virtual machines. The website also has many hidden quirks built up over its long history. Seemingly simple changes might actually be simple, but run a risk to turning into deep rabbit holes.

I have to prioritize where to spend dev time. Finalizing the lockable Teensy & its bootloader and bringing the filesystem integration work into 1.56 are where I'm planning to focus my attention in the immediate future. Looking into NativeEthernet bugs is also high on my list. Sadly, that list has a pretty incredible number of other worthy goals which will wait. There are only so many hours in every day.

Defragster can update that announcement thread however he believes is best.
 
Status
Not open for further replies.
Back
Top