Teensyduino 1.58 Beta #2

[PaulStoffregen]

Usually I delete the beta versions some time after each stable release.

Before 1.56 each copy took about 700M on the server. Now with packages for Arduino IDE 2.0.0, each copy is close to 1GB. The new toolchain in 1.58 beta is also larger.

Our current website hosting service provides 80GB space. Right now we're running 86% used. Eventually PJRC will upgrade the hosting to a service which gives 480GB space. The main reason to upgrade isn't disk space, it's bandwidth. We currently use about 1.7TB/month. I believe the plan has a 5TB limit. Newer services allocate 20TB.

You'd think disk drive space is cheap these days, but it's one of so many features where hosting companies give you a pretty meager size and then offer to increase, but not for a 1-time charge to cover the hardware, it adds on to the monthly bill. Same for RAM. They make a lot of money that way.

But with the 80GB service we use right now, keeping all the betas online would take a lot more disk space than we have available. If you *really* need a specific beta, just ask. I have them all archived. It's easy enough to just put one back on the server for a while. But usually once a stable release is made, pretty much nobody ever wants or downloads the beta tests that led up to it.

[shawn]

Is there any chance there'll be at least one Mac beta version before the final 1.58 release? I'm aware that it's a lot of work to put together, so fingers crossed.

[defragster]

Is there any chance there'll be at least one Mac beta version before the final 1.58 release? I'm aware that it's a lot of work to put together, so fingers crossed.

At some point would be expected. With the updated toolchain the first were just alpha sniff tests to make sure it was worth moving forward or seeing that it needed reverting. The Mac version is a tougher build with security and not a 3rd of the user base AFAIK form prior comments.

[PaulStoffregen]

Yes, there will be several more betas. We're nowhere near close to 1.58 release yet.

Indeed, MacOS requires more work than the other systems. I will get it done, but can't promise any specific time frame at this point.

FWIW, I have one M1 Mac just yesterday updated to Ventura. It's currently stuck on asking me to agree to Apple iCloud new terms and conditions, but can't seem to load that junk. Not a great Ventura start for me...

[PaulStoffregen]

On Macintosh, I'm also seriously considering dropping support for very old systems. Currently we support all the way back to the last couple versions when Apple was naming them after big cats! Part of the reason MacOS takes so much more work is I build the software using a very convoluted process on 3 different Macs, to achieve that compatibility all the way back to MacOS 10.7.x (Lion). It wasn't ever meant to be this way... but every time new Apple build tools broke compatibility with older MacOS, I kept finding workarounds where I'd do part of the build on the old tools and part on newer tools, to keep compatibility. It always seemed like a good idea at the time, but when Catalina started requiring Apple Notarization, complexity of my build process really started to spiral out of control.

I've been considering just buying a brand new Mac Mini to dedicate for building the software, so I can start fresh with the latest tools (I don't dare update much on the 3 fairly old Macs currently used for the build) and just accept that the resulting new build won't work on old MacOS. But the rumor mill keeps saying now isn't a good time to buy Mac Mini, that a M2 refresh is supposedly coming soon....

[Garug]

Regarding USB Host, what would be the best version to use. The SteamDeck HID interface I got working with your help on the other thread, using 1.57 (the official)

With Serial I am having some issues with Loupedeck Just can not get Loupedeck responding as it should. Suspect some driver issue, maybe some missing lower level USB handshaking,

The first 130 bytes long ASCII message without any header works and it gets initialised and starts providing messages on button press, but after trying to send any binary Web Socket type messages (over Serial) the device goes to sleep. I suspect the Loupedeck would want to get some underlying handshakes to detect the WS header. Otherwise the long messages would be difficult to parse.

But just guessing, the problem could be also how I try to communicate with Loupedeck, But that has been commented looking ok, by some other developers that did computer SW for it.

WARNING: there were a couple of updates to the USBHost code with this beta.

One was to make the keyboard objects no longer top level objects, but more like Mouse where it always goes through a HIDParser for it's inputs and outputs.
The code was extended to support more N-key rollover keyboards, like the Gigabyte from before.

This removed the need for this keyboard and hopefully others to not need to be forced into BOOT keyboard format.

However, I screwed up some and had the Keyboard HID Claim code in the USBHost code and it was grabbing reports meant for Joysticks and Mice. So they are not working very well
if your sketch also has one or more Keyboard objects in it.

I have fix for it, that appears to be working better: I have tried it with a few devices now:
Gigabyte K83 - the original problem child (still causes other issues)
ReDragon K552 - newer N key rollover keyboard
Logitech wireless combination K350 M705
Logitech Pro G wireless mouse
Sony PS3 controller (plugged in)
Did not test the Bluetooth stuff yet, as none of that changed.

Pull Request: https://github.com/PaulStoffregen/USBHost_t36/pull/98
From new branch: https://github.com/KurtE/USBHost_t36...nt_claim_mouse

[KurtE]

Regarding USB Host, what would be the best version to use. The SteamDeck HID interface I got working with your help on the other thread, using 1.57 (the official)

With Serial I am having some issues with Loupedeck Just can not get Loupedeck responding as it should. Suspect some driver issue, maybe some missing lower level USB handshaking,

The first 130 bytes long ASCII message without any header works and it gets initialised and starts providing messages on button press, but after trying to send any binary Web Socket type messages (over Serial) the device goes to sleep. I suspect the Loupedeck would want to get some underlying handshakes to detect the WS header. Otherwise the long messages would be difficult to parse.

But just guessing, the problem could be also how I try to communicate with Loupedeck, But that has been commented looking ok, by some other developers that did computer SW for it.

Note, the above comments about Keyboard have nothing to do with the Serial code. As mentioned in the comments, those changes had to do with Keyboard object changes, and converting it to use HID instead of being its own lower-level object.

As for best version to use... I am not sure. As I don't think there are any changes that have happened that might impact this. But I would tend to use the most recent, probably from master branch.

A couple of us our working off of a different branch right now, but that is for Bluetooth related stuff.

As for loopedeck not responding the way you think it should. Probably should continue on other specific thread.
As for why it is not working this can be very elusive and subtle issues. For example, with some of our BT work, we are trying to get some more game controllers to work over
bluetooth. And for example, with XBox One controllers, we have it working with earlier versions of their controller's firmware, and maybe even some later versions, although the later versions, for example changed things like the order the buttons are reported. But the code won't work with the controllers that are updated to the current version, as they changed them to work using
Bluetooth Low Energy (BLE) which we don't have support in for.

Likewise, with Ninetendo Switch controllers, we have stuff working with the official Pro controller, and some Clones, but not others. Why, each one's firmware works differently.

So maybe your Loupedeck is expecting something very subtle, that is not being satisfied.

Should continue on other thread.

[Garug]

It is already in here https://forum.pjrc.com/threads/70143...513#post315513

So there is no updates on 1.58 for USB Host serial? I am using Mac M1, so no point to test on some Windows machine the 1.58.

I do think it is some driver handshaking issue (Descriptor 36 = ??? etc.), but yes, very much possible something Loupedeck related.

[Garug]

The Loupedeck issues I got solved, but in general, where to find the latest teensyuino for Mac (Ventura M1)

[PaulStoffregen]

where to find the latest teensyuino for Mac (Ventura M1)

Here:
https://forum.pjrc.com/threads/71693...no-1-58-Beta-3