Developing remotely on a Mac?

jim lee

jim lee

Well-known member
All of my development is done on Macs. A bunch of it is done far away from civilization. Back in the day with Arduino IDE 1.x and Teensyduino, this was not an issue. But it seems that the Teensy4.0 wants to use IDE 2.x and 2.x demands an internet connection before I can talk to the Teensy. I'm sure I'm not alone in doing off the grid development. How have others solved this? Can the 2.x IDE be set somehow to not require a connection? Is there a better solution?

Thanks!
 
IDE 1.x works fine - on supporting operating systems. Problem was, IIRC, on newer MAC OS's where the build and security changes got in the way of release and use for the 1.x?

IDE 2.x does look for Auto Update and slows down start up, and may be blocking? I rarely use the 2.x - but I did disable the auto update checks and that may be where the unconnected start gets stuck?
 
Starting with version 1.60, we're only supporting use of IDE 2.x.x on MacOS.

Use with IDE 1.8.19 is still supported on Linux and Windows, at least for now. But the old Java JRE is having more and more issues on newer Linux distros, so the future Linux support for old IDE is uncertain. Microsoft is the king of backwards compatibility, or least they traditionally have been. But if (when?) the old Java JRE breaks on Windows, nobody will be coming to save it.

Backwards compatibility on MacOS is difficult. The next major issue on the horizon is Apple has said they will drop support for running X86-64 binaries in the next version of MacOS (after Tahoe). That alone isn't a big issue, but it becomes a problem combined with the gcc toolchain. We're running version 11 now, which is built only for X86-64. The build published by ARM dropped support for running on Intel-based Macs back at version 13. So if we update to version 14, we lose support for compiling Teensy code on Intel-based Macs, even though everything else supports both Intel and Apple silicon. Unless someone wants to take on the task of rebuilding the latest toolchain for older Macs, seems pretty likely we'll be dropping support for Intel-based Macs soon.
 
On the question of using Arduino IDE without internet connectivity, that's a question for Arduino's forum.

All the Teensy stuff runs locally after Arduino IDE has installed it.
 
Good lord, what a bloody nightmare! I do feel for you on the Mac backwards compatibility issue. They been obsoleting my machines at a horrendous rate for about a decade now. It's tough when you build a business system you rely on with them. Pretty quick time moves on and your system only lasts 'till something breaks. There's no fixing it when the support is gone.

I'll ask the Ardunino people about running 2.x offline. We'll see what they say.

Thanks!
 
Well I talked to them. As long as you have all your bits together and can compile & load code on your selected hardware. You're good to go. I was able to test it, and it seems to work. Whew!
 
PaulStoffregen said:
Backwards compatibility on MacOS is difficult. The next major issue on the horizon is Apple has said they will drop support for running X86-64 binaries in the next version of MacOS (after Tahoe). That alone isn't a big issue, but it becomes a problem combined with the gcc toolchain. We're running version 11 now, which is built only for X86-64. The build published by ARM dropped support for running on Intel-based Macs back at version 13. So if we update to version 14, we lose support for compiling Teensy code on Intel-based Macs, even though everything else supports both Intel and Apple silicon. Unless someone wants to take on the task of rebuilding the latest toolchain for older Macs, seems pretty likely we'll be dropping support for Intel-based Macs soon.
Click to expand...
Version 14.2.1 is supported on Intel Macs. It's what I use, sometimes even with C++20. 14.3.1 is where they (ARM) stopped building them for Intel Macs.

Ref: https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads
 
shawn said:
Version 14.2.1 is supported on Intel Macs. It's what I use, sometimes even with C++20. 14.3.1 is where they (ARM) stopped building them for Intel Macs.
Click to expand...
On my old and only Mac (Mac Book Pro early2013), there were things that I could not install on it, including Arduino App-lab (Uno Q).
Apple dropped support for these on later OS...

I am trying to remember what I did, but used a utility to allow me to install Sequoia 15.7.3,
So I am now able to run App lab... Will see how long that lasts.
 
Looks like the latest toolchain is now up to version 15.2.

An ideal solution would be to figure out how to rebuild the entire 15.2 toolchain from source for MacOS on X86-64. When I last messed with the toolchain at version 11.3 (which we're still using today) the published scripts were only for Linux. I did see a cross compile option for Windows. But how do build it all for MacOS... I'm just glad I didn't have to do that.
 
Today I'm attempting to build the 15.2.1 toolchain for Intel-based Macintosh (host=x86_64-apple-darwin) and 32 bit Raspberry Pi (host=arm-linux-gnueabihf). It's a long slow process...

While searching for info, I found this site which appears to have already done it, at least for MacOS.

github.com

Release xPack GNU Arm Embedded GCC v15.2.1-1.1 · xpack-dev-tools/arm-none-eabi-gcc-xpack

Version 15.2.1-1.1 is a new release of the xPack GNU Arm Embedded GCC package, following the Arm release. Continue reading »
github.com github.com
 
I'm using ARM's build-baremetal-toolchain.sh script, with a few minor edits to work around issues.

I also added custom cflags with "-mmacosx-version-min=10.13", to hopefully allow it work on older versions. I was originally aiming for 10.10 (Yosemite) backwards compatibility, which how Teensy Loader and other tools are built, but I ran into an issue within binutils which depends on stuff Apple added in 10.13. I'm actually building on an Intel-based Mac running MacOS 12.7.6 (Monterey).
 
Well, the toolchain build last night doesn't work.

Apparently I had installed zstd on that old machine. It survived an update from Mojave to Monetery. Then the toolchain build appears to have found zstd and built a linker which depends on it. But of course Apple doesn't ship zstd, so the toolchain doesn't work when copied to a different Mac. :(

screen.jpg
 
You must log in or register to reply here.
Back
Top