Dogbone06

Understood. But using the PICO 2W as a test to understand the driver is half the battle. It sounds like once you get the real board to test with it should go alot faster than you would have if you were starting from scratch. Probably should...

@mjs513 - Just to be clear, I have not created the driver yet because I need a CYW43439 board setup to use SDIO. The PICO 2W uses SPI 1 wire comms. Hopefully we will have a board available soon to work with or even better a verified working...

Nice job - anxious to try it out - hope it all works with the hardware. 🤞

Update: Setup to compile and run the picowi library on the PICO 2W. It uses an SPI interface instead of the SDIO interface we use with T41. The SPI initialization is similar to the SDIO initialization after the low level hardware setup is done...

If @wwatson had one that might be the fastest way to know. @Dogbone built his minimal boards and other than possible sanity hardware checks AFAIK they shipped for forum testing. Software is known ready for chip change and @wwatson seems to have...

Gotcha, thanks for the clarification! Would like to know what was done to test both chips, I'd love to do the same to prove that there's no hardware problems before shipping the boards out.

I never tested any of the original two chips, I just had them made an dispatched. So what you said is correct.

@Dogbone06 can answer - but his goal/effort was building the test boards then forwarded just the first boards to forum members. He acquired a batch of both chips but only the first was shipped out AFAIK.

We've completed our internal design review and are ready to order prototypes. Want to make sure I have allocations correct: @shawn 2 for you @wwatson 1 for you @defragster 1 for you @Dogbone06 @PaulStoffregen @KurtE @mjs513 I haven't seen...

I'd love one, so fun to see your improvement work on the hardware I started! How do we proceed? I have you on email, I can send the details there. :D Being named by Dogbone06 would be amazing, if I may. I think the other names should be there...

If anybody is interested in playing, I have gone through the QNEthernet_WIFI library and cleaned it up. This is just until @shawn decides if and when he is going to do his updated API. This is a list of the major changes: - Converted all files to...

Reworked the WIFI scan API. It no longer hangs up intermittently. It now uses an event handler that fires a scan callback when it recognizes a scan result packet. The event handler still needs to be polled but the results are much more stable...

Thanks for that, @sparkfro. In addition to the pinout, I'm just wondering how everything would physically fit together with an OctoWS2811. For example, how would we physically connect the pins? Does it need another stack? How many double-high...

Looks good :D I see the slight change to the pinouts so once it is tested and confirmed I will add this pinout to the documentation. I have one of Paul's three tier breakout boards and I agree with you that is probably the best thing to use, at...

Apologies for my delay, I had another project taking up all of my time for the last couple weeks, but I'm working on this again! I've updated the design based on feedback here, and polished it up. Please let me know what you think! We'll do an...

Is the 1DX module power consumption always low enough to run from Teensy's 3.3V output? When I looked at the 1XK module almost 1 year ago, I was worried it might need more current than Teensy 4.1 can provide, especially if also powering a SD...

I missed all these updates, been running around all kinds of places the past week. I am sooo happy to see that the project is alive and well. This is really engaging the people of this community. Absolutely wild, great work everyone! :love:

Very helpful, thank you! Ok, here's a quickly-put-together schematic and board layout. Haven't yet done any controlled impedance or length matching for traces, and definitely need more GND vias. Will do that later, want to first get feedback to...

Note with Zephyr, potentially a lot of this is already done... That is there are already a couple of boards with Zephyr support like: https://github.com/zephyrproject-rtos/zephyr/tree/main/boards/nxp/mimxrt1170_evk...

They're not, he designed the board in the video and explained his plans. Which are to write the base drivers to blink LED's and such. With the amount of work to write drivers and such - if one wants to utilize all the bells and whistles. I don't...

The voltage adjustments for the industrial MCUs were reverted in the core though, so beware of random issues.

TD 1.62 beta 3 is working with Devboard 4 & 5 devices. I have tested 8080 parallel displays and several other devices with success. The following is the repo README.md instructions for installation found here. 1. Install arduino-1.8.19 and then...

That was the first that caught attention and nothing else was a problem - but SDRAM test was priority with focus. Been a while now ... If there were other 'low voltage' issues they didn't present as significant before voltage was raised and...

Correct - two separate posts. Only known use of SDRAM is the @Dogbone06 boards with Industrial MCU. But if somebody wanted FLASHMEM code - it was there and seen to work on LOCKED (and unlocked) STD MCU's It was just an idea to prove on the fly...

Years passed. How I wish PJRC offered this now. Teensy with 1GHz RT1170. Pretty please with sugar on top 🙏

I wish this was made by PJRC years ago. Would have been a perfect upgrade to the T4.1

I just saw this Uses RT1170, 1Ghz, dual core, ....

I have some Teensys in the field that will probably never get the new bootloader because I only upgrade them via OTA methods. Will EHEX files generated with Teensyduino 1.61 still work with those Teensys?

All I should have to do is replace the teensy_secure.exe correct? That would solve it, without having to upgrade to 1.61 completely?

Let's see if I understand this right: Bootloaders bought today would ship with 1.09. So they would not work with Teensy Loader version 1.60 or below? Need to use 1.61? I run 1.58 in a few projects that I don't touch, they work. Will they work...

@wwatson - Thanks for the detailed breakdown and history of this project. It is and will be a great help for our team at SparkFun! While we can't be sure of all the details in the final product, starting with something that is working and can...

HI All - First - this is a awesome project with great results. Not the easiest hardware/software problems to solve! We were contacted recently by @Dogbone06 about this project and if SparkFun would be interested. Our answer is absolutely...

The BT pins were never routed but that an easy task for Sparkfun to do on their design. From what we saw the 1DX and 1YN are identical at least for the WiFi pins. I made the chips with both of them and they seem to work the same. It's truly...

I was testing an FTP driver for the TEENSY41 with QNEthernet_WIFI I was getting intermittent crash reports for a null pointer. I add code to the SDIO driver "cyw43_T4_SDIO.cpp" at about line# 372. An update...

I'm not following. I seem to be missing context.

@shawn - I was getting intermittent crashes when I was testing some buggy FTP software for the Teensy41. Turns out that it was sending a null pointer to the SDIO driver "cardCMD53()" which did not catch it. I added a test for it. It returns a...

@wwatson you've inspired me to add a note to the SNTPClient example with alternative hosts.

Ok, thanks...

It's often the case that local routers have a time server. Some do not. This might be the reason.

@shawn - I could not get the SNTPClient sketch to work on either WIFI or native Ethernet. If I change: udp.send(Ethernet.gatewayIP(), kNTPPort, buf, 48)) to: const char timeServer[] = "time.nist.gov"; udp.send(timeServer, kNTPPort, buf, 48) It...

Also on my mind is multi-interface support, but that's later. (No promises and no target dates.)

Just noticed that in simplePing.ino and ping.ino I did not change the ping destinations back to arduino.cc. Now fixed. simplePing.ino line#33 should be: constexpr char kHostname[]{"arduino.cc"}; and ping.ino line #38 should be: constexpr char...

Updated from github - cyw43_ping working: > note: the code checked in with ..\QNEthernet_WIFI\src\qnethernet_opts.h :: ARDUINO_TEENSY41_CYW4343W 1 Looking up "arduino.cc"... IP = 18.238.238.4 Round-trip time 18.6 ms Round-trip time 6.5 ms...

Glad to see you have it working. No, secret.h really does not have to be that far into the depths of QNEthernet:) I just had not got around to moving it yet. A person could also add the contents to the beginning of each sketch except the file is...

There's some stuff I need to refactor, design-wise, so that Wi-Fi fits in better. I intend to start with a new "WiFi" class (or similar) for Wi-Fi-only things. I'm currently in the process of working on converting everything to C++ plus...

I am going to leave everything alone for now until you are finished with refactoring. That will minimize any confusion that might happen...

One other thing I forgot to mention is that cyw43_scan.ino has issues still. It will perform one or maybe two scans perfectly but will intermittently fail after that. I am looking into it. It has something to do with not resetting after each...

Just saw that secrets.h is manually included in sketch - so local copy could replace that. NOTE: FAIL :: "\libraries\QNEthernet_WIFI\examples\cyw43_scan\cyw43_scan.ino" Setup/begin Code of scan not the same as in ping? Code starts and seems...