Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Teensy support? #700

Closed
SebCanet opened this issue May 10, 2020 · 45 comments
Closed

Teensy support? #700

SebCanet opened this issue May 10, 2020 · 45 comments
Assignees
Labels
conclusion: resolved Issue was resolved topic: code Related to content of the project itself type: enhancement Proposed improvement

Comments

@SebCanet
Copy link

Hi,
I don't know if it's the right place to ask it, but is there any support for Teensy board?
I did not find any information for this kind of board.
Many thanks.

@jmchiappa
Copy link

Hello @SebCanet ,
Teensy support is provided by the board vendor. Refer to the web site : https://www.pjrc.com/teensy.

It seems that teensy doesn't follow the right 3rd party install. It hacks the arduino folder by adding teensy board directly in the arduino root folder hardware\teensy instead of using an additional url.
Consequently, arduino-cli core list will not show teensy core as it is placed in the arduino IDE root folder. By copying manually the whole hardware/teensy folder into arduino15/hardware/packages/ , you will be able to list it.

The most straightforward way is probably to ask to PJRC to provide an URL that publishes the teensy platform instead of an executable file.

You agree, it is not related to arduino-cli ;-)

@rsora
Copy link
Contributor

rsora commented May 20, 2020

Hi @SebCanet, @jmchiappa,

The Arduino CLI do not support Teensy at the moment, there are 2 reasons:

  1. CLI side Teensy support can be done after the implementation of the "Pluggable Discovery" feature, that will enable usage of other board discovery mechanisms beside USB/Serial.
    This will also allow us to add support for features like OTA (Does OTA work in arduino-cli? #69).

  2. Core side, we will interact with the Teensy creator (PJRC/PaulStoffgren), to see what is missing to finalize the support (as @jmchiappa pointed out).

Thanks for the heads up!

@SebCanet
Copy link
Author

Hi,
many thanks for your answers, it's much clear now.
I already tried to contact guys from PJRC and ask them for inforation about their product, but still have no response yet.
That would be great, thanks a lot @rsora for adding features. I hope this can be done easily, it seems Teensy boards are used in many coutntries in workshop for kids, and as I create software for this I'll implement it as soon as it's available.

Many thanks.

@rsora rsora added the type: enhancement Proposed improvement label May 21, 2020
@AndrewCapon
Copy link

Hi Guys,

Was there any progress on this?

Cheers

Andy

@ubidefeo
Copy link

ubidefeo commented Jun 28, 2020

hi @AndrewCapon
we’re working towards implementing Pluggable Discovery which is a requirement for a series of features needed by 3rd party developers.
Once that is done it’s on said developers to implement features, and we hope Teensy will jump onboard quickly :)

@AndrewCapon
Copy link

Hi @ubidefeo

Thanks very much for the info, I will keep an eye out.

Have a nice day.

Andy

@benjamin-kirkbride
Copy link

Any update?

@ubidefeo
Copy link

hi @Beefy-Swain
The path to implementing good support for Teensy in a way that both us and the PJRC team would be happy about requires a few more things to be in place, and we're actively working to make them happen.
Both Pluggable Discovery and a Pluggable Monitor are part of the infrastructure required to have Teensy working the right way and could be useful to other 3rd party platform developers to correctly implement data exchange not just via UART but through other protocols.

You can probably hack your way into supporting Teensy for your own needs but I'd wait for something that is well thought of by Paul Stoffregen in order to make sure his User Experience is preserved.
Our efforts will be in offering platform developers the tools and infrastructure they need to bring their product into Arduino, but the last part will have to eventually be made by them following the platform specification documentation which is allowing more and more developers to bring their boards inside of Arduino.

A bit more patience might be required, just know that we're not sleeping on this one :)

@gannaramu
Copy link

I have made a small workaround for teensy based boards. https://github.com/gannaramu/Teensy-Github-Action. It does not use the arduino-cli, but hope it helps someone.

@PaulStoffregen
Copy link

@ubidefeo - Is any info or specification published regarding your plans for Pluggable Monitor?

As I'm sure you're already aware, Teensyduino adds patches to the Java IDE to implement a pluggable monitor using stdio/stdout/stderr, using only very simple status messages on stderr. I seem to recall a conversation in 2019 about plans to use localhost networking and maybe RPC? Is that still your plan? If you have any sort of preliminary spec, I would really like to begin migrating Teensyduino to use that approach on the Java IDE, so I am ready to fully support arduino-cli and the Pro IDE when you add pluggable monitor.

@PaulStoffregen
Copy link

I should also mention, serial monitor performance is critically important for Teensy 4.x. Here is a simple USB Serial.print() speed test. Very easy to run this on any board, just copy into Arduino, upload, and open the serial monitor to watch the result.

https://github.com/PaulStoffregen/USB-Serial-Print-Speed-Test/blob/master/usb_serial_print_speed.ino

I ran this yesterday on Portenta. It prints just over 10000 lines/sec.

Teensy 4.0 can print ~700000 lines/sec to Linux desktop systems, and about 500000 - 600000 to Windows. Very efficient serial monitor code is needed to keep the IDE from crashing with sustained incoming data at that speed. I rewrote the serial monitor's internal data storage, and even then Java struggles to keep up with this speed.

If you are still in the process of choosing the pluggable monitor approach, I hope we can work together as it evolves.

@ubidefeo
Copy link

hi @PaulStoffregen

thank you for taking the time to reach out.
We have indeed still plans to bring in pluggable monitor, and your input would be very welcome.
Pluggable discovery has moved forward with a working PoC (we need this also for networked devices) but in order to concentrate on the Pro IDE we had to reroute some efforts.
@cmaglie is taking a well deserved xmas break and is back next week, I think the two of you can have a chat then, he'll be able to share more information on the current status.

I have recently found out that the current monitor we're using in the Pro IDE is dropping packets (which is better than crashing the host app) so that will need some serious rework.

We're more than interested in having Teensy support, as you know, and I think the work done on the CLI over the past few months has been laying the foundation to make this work, we just need a bit more time. Unfortunately we only have 2 developers on CLI, but development has been moving forward pretty steadily.

Let's reconnect in a week, I'll ask Cristian to email you.
I really want to see Teensy in the new IDE :)

@PaulStoffregen
Copy link

@ubidefeo - Do you have any Teensy boards for testing? If not, please email me directly and I will arrange to send you some. I'll pre-load that USB speed test on them so you can just plug it in and open the serial port. Even if all features are implemented, long-term the Pro IDE needs to be able to handle incoming serial data at high speed, so please let me send you some hardware you can use for performance tests.

@ubidefeo
Copy link

@paulrnash
thank you for the offer, but I think I bought every board you made except the AVR ones :D
I also sent a couple out to the team members.

If you can send us that USB speed test code (or binary we can upload with teensy_loader) we can start testing.
This won't happen before end of January for sure, we have our hands full after the holidays.

Also today I was chatting with @facchinm and he pointed me at some serial handling code that already needs patching.
The Go part is supposed to be extremely fast, but we're a bit concerned with how JS will handle the flood.
We won't know until we dig :)

I really look forward to the team being back from the holiday so we can keep hammering 🔨 🔨 🔨

@PaulStoffregen
Copy link

Here's the speed test code.

https://github.com/PaulStoffregen/USB-Serial-Print-Speed-Test/blob/master/usb_serial_print_speed.ino

And here's a copy right in this message! It's just a very simple sketch. Just copy into the IDE and upload to any board.

uint32_t count, prior_count;
uint32_t prior_msec;
uint32_t count_per_second;

// Uncomment this for boards where "SerialUSB" needed for native port
//#define Serial SerialUSB

void setup() {
  Serial.begin(1000000); // edit for highest baud your board can use
  while (!Serial) ;
  count = 10000000; // starting with 8 digits gives consistent chars/line
  prior_count = count;
  count_per_second = 0;
  prior_msec = millis();
}

void loop() {
  Serial.print("count=");
  Serial.print(count);
  Serial.print(", lines/sec=");
  Serial.println(count_per_second);
  count = count + 1;
  uint32_t msec = millis();
  if (msec - prior_msec > 1000) {
    // when 1 second as elapsed, update the lines/sec count
    prior_msec = prior_msec + 1000;
    count_per_second = count - prior_count;
    prior_count = count;
  }
}

@ubidefeo
Copy link

straight forward
I was expecting some esoteric black magic of yours :D
Thanks, Paul

Hope to have an update for you soon.
I'm confident we have picked up a much better pace than we used to have ;)

@PaulStoffregen
Copy link

PaulStoffregen commented Dec 29, 2020

Hahaha - all native USB boards have plenty of black magic lurking deep underneath Serial.print()

@kofoednielsen
Copy link

Any update on this?

@silvanocerza
Copy link
Contributor

@kofoednielsen we are currently working on the Pluggable Discovery, that will make it possible to add support for Teensy and lots of other features. Just releasing this new feature won't make it magically work though, the Teensy platform will need to be updated to support this new feature and that's up to @PaulStoffregen.

@PaulStoffregen
Copy link

PaulStoffregen commented Jul 22, 2021

I'm planning to work with the new Pluggable Discovery in a few weeks. Currently working on support for hardware decryption in flash memory, which is turning out to be a lot more work than originally anticipated (easy to do poorly, tough to make actually secure & also simple to use). Hoping to wrap it up soon.

Teensy already implements an earlier version of Pluggable Discovery, so I'm not expecting trouble with Pluggable Discovery.

But Pluggable Discovery alone isn't enough for Teensy to be fully supported by future Arduino software. Teensy will also need Pluggable Monitor, which Teensyduino implements today by a large set of Java patches. Also on my to-do list is a proof of concept pluggable monitor conforming to the draft spec Cristian recently wrote.

@rsora
Copy link
Contributor

rsora commented Jul 26, 2021

For the records, implementation (arduino-cli side) is going on here #1333 🔨

@catkins
Copy link

catkins commented Sep 23, 2021

Hi there, I notice that #1333 is merged now, and the Pluggable Monitor RFC appears to have been merged to (unsure of implementation) - is there a good spec or the like available for folks to add a Teensy plugin?

@Michael2MacDonald
Copy link

It has been 3 months and I can't find any good updates about Teensy support with Arduino CLI / 2.0 IDE. It looks like Pluggable Discovery and Pluggable Monitor have been added but I have not seen much from Paul on whether PJRC is working on it yet.

Are there any updates?

@PaulStoffregen
Copy link

@Michael2MacDonald - Sorry, I've been really distracted by USB MTP recently, and also managing business problems from chip shortages. I don't have any update for you, other than I'm alive (no covid yet, fully vax+boost) and I am working on a lot of stuff, where this is on a long list of higher priority tasks to be worked on "soon".

@Michael2MacDonald
Copy link

Thanks for the update!
I am excited to hear that you are working on MTP. There are a lot of cool things I want to see added to arduino and Teensy but I understand you have limited time and resources but I am glad to hear that you are working hard. I hope covid and the chip shortages end soon for all of our sakes.

@raphaelrk
Copy link

raphaelrk commented Jan 17, 2022

I've been able to get cli-based compilation and upload to Teensy devices with the following on Ubuntu. Change as needed for your use case (e.g. I imagine most people won't want to save things to /tmp):

Setup:

# Set up ability to compile code for Teensy controller
# Downloads Arduino and patches it with teensy support
# https://www.pjrc.com/teensy/td_download.html
curl -sSL https://downloads.arduino.cc/arduino-1.8.19-linux64.tar.xz > /tmp/arduino-1.8.19-linux64.tar.xz && \
    curl -sSL https://www.pjrc.com/teensy/td_156/TeensyduinoInstall.linux64 > /tmp/TeensyduinoInstall.linux64 && \
    curl -sSL https://www.pjrc.com/teensy/00-teensy.rules > /tmp/00-teensy.rules && \
    mkdir -p /etc/udev/rules.d && \
    mv /tmp/00-teensy.rules /etc/udev/rules.d && \
    tar -C /tmp -xf /tmp/arduino-1.8.19-linux64.tar.xz && \
    mv /tmp/arduino-1.8.19 /tmp/arduino && \
    chmod 755 /tmp/TeensyduinoInstall.linux64 && \
    /tmp/TeensyduinoInstall.linux64 --dir=/tmp/arduino

# Note: also copy your custom arduino libraries to ~/Arduino/libraries/
# More info at https://github.com/arduino/Arduino/blob/master/build/shared/manpage.adoc

Usage in python (with two Teensys connected to my computer, both using the same code):

import sys
import serial  # from pyserial
import serial.tools.list_ports

def get_serial_devices():
    if sys.platform == "linux" or sys.platform == "linux2":
        device_string = "ttyACM"
    else:
        # Windows, Mac etc
        raise Exception(f"Unsupported platform detected: {sys.platform}")

    all_devices = serial.tools.list_ports.comports()
    all_devices = [(d.device.replace("cu", "tty"), d.manufacturer) for d in all_devices]
    all_devices = list(set(all_devices))
    serial_devices = [d for d in all_devices if device_string in d[0]]
    return serial_devices

serial_devices = get_serial_devices()
teensys = [
    port
    for (port, manufacturer) in serial_devices
    if manufacturer == "Teensyduino"
]
for idx, port in enumerate(teensys):
    DEVICE, SPEED, USBTYPE, INO_PATH = "teensy41", "600", "serial", "/path/to/your.ino"
    os.system(f'/tmp/arduino/arduino --verify --port {port} --board "teensy:avr:{DEVICE}:usb={USBTYPE},speed={SPEED},opt=o2std,keys=en-us" {INO_PATH}')
    if idx != len(teensys) - 1:
        # Added a 500ms timeout as it seemed to have issues without any sleep between flashes
        # Could be more scientific on what the length of this delay should be
        time.sleep(0.5)

Usage in bash (not tested)

# get ports in bash, from https://unix.stackexchange.com/a/668691:
vidpid_to_devs(){
      find $(grep -l "PRODUCT=$(printf "%x/%x" "0x${1%:*}" "0x${1#*:}")" \
                /sys/bus/usb/devices/[0-9]*:*/uevent | sed 's,uevent$,,') \
         /dev/null -name dev -o -name dev_id |
      sed 's,[^/]*$,uevent,' |
      xargs sed -n -e s,DEVNAME=,/dev/,p -e s,INTERFACE=,,p
}

# "16c0:0483" is for teensy 4.1, find whatever [vendor]:[product] yours is by running lsusb
vidpid_to_devs 16c0:0483 \
 | xargs -I %s -- sh -c '\
   echo "Attempting to program Teensy at %s" \
   && /tmp/arduino/arduino --verify --port %s --board "teensy:avr:{DEVICE}:usb={USBTYPE},speed={SPEED},opt=o2std,keys=en-us" {INO_PATH}
    && sleep 0.5 \
    && echo "Finished with Teensy at %s"'

Basically, using the arduino cli instead of arduino-cli 😛

I do get the following issue when using this though (message seems to come from the teensy_reboot binary), where it doesn't respect the port I selected, so at the moment it doesn't always flash to the correct teensy. Looks like this forum post and this set of tools might be able to fix it but haven't gotten it working yet (for some reason tycmd can't find my teensys when running in docker, nothing else has had issues with that).

Picked up JAVA_TOOL_OPTIONS: 
Loading configuration...
Initializing packages...
Preparing boards...
Verifying...
Memory Usage on Teensy 4.1:
  FLASH: code:91484, data:14232, headers:8596   free for files:8012152
   RAM1: variables:15040, code:88792, padding:9512   free for local variables:410944
   RAM2: variables:12384  free for malloc/new:511904
Uploading...
Found 2 Teensy boards, but using auto-search to find board for upload.
Please use Tools > Ports(Teensy) to select the specific board.

Update, I've gotten uploading to a specific teensy semi-working with a fork of teensy_loader_cli. Weird thing is it seems to work exactly every other time, so I have to run it twice.

# install teensy_loader_cli
apt-get install -y libusb-dev && \
    git clone -b serial_number --single-branch --depth 1 https://github.com/raphaelrk/teensy_loader_cli.git /tmp/teensy_loader_cli && \
    cd /tmp/teensy_loader_cli/ && \
    make

# get teensy serial numbers
apt-get install usbutils
lsusb -d 16c0:0483 -v 2>/dev/null \
| grep iSerial \
| awk '{print $3}'

# run it once, doesn't work
# .hex comes from running arduino's cli above with `--pref build.path=/tmp/embedded_build`
root@ubuntu:/tmp/teensy_loader_cli# ./teensy_loader_cli --mcu=TEENSY41 -w -v -s --serial-number=12345678 /tmp/embedded_build/main.ino.hex
Teensy Loader, Command Line, Version 2.2
Read "/tmp/embedded_build/main.ino.hex": 128000 bytes, 1.6% usage
Soft reboot performed
Waiting for Teensy device...
 (hint: press the reset button)
Found HalfKay Bootloader
Read "/tmp/embedded_build/main.ino.hex": 128000 bytes, 1.6% usage
Programming...error writing to Teensy

# run it again, works
root@ubuntu:/tmp/teensy_loader_cli# ./teensy_loader_cli --mcu=TEENSY41 -w -v -s --serial-number=12345678 /tmp/embedded_build/main.ino.hex
Teensy Loader, Command Line, Version 2.2
Read "/tmp/embedded_build/main.ino.hex": 128000 bytes, 1.6% usage
Found HalfKay Bootloader
Programming..........................................................................................................................
Booting

Update, above error no longer happens. I changed all calls to teensy_write in teensy_loader_cli.c to have a timeout of 1 which fixed it. So everything seems to work now 🎉

@PaulStoffregen
Copy link

PaulStoffregen commented Jan 19, 2022

I'm been working on this recently. Here is an early and very experimental first try. So far only tested in Arduino 1.8.19 portable. Tools are only built for Linux x86_64 so far.

https://www.pjrc.com/teensy/td_156/package_teensy_index.json

Unresolved problems.

1: Upload recipe causes GUI-based Teensy Loader to actually perform the upload. That's probably not going to make command-line-only Arduino CLI users happy. I can't find any predefined property to inform my tools whether to run a GUI-based or "headless" upload process is appropriate. @cmaglie - Any suggestion how I should handle this? Is there any way my upload command can detect whether the upload request came from an IDE or CLI?

2: Boards Manager in Arduino 1.8.19 does not start the Pluggable Discovery process my platform.txt file specifies. A full restart of the Arduino 1.8.19 IDE is needed after installing the package. Also, my discovery utility is older than the Pluggable Discovery spec and speaks the JSON dialect of the Java IDE... still needs to be updated for the new spec.

3: I don't understand how to use discoveryDependencies in my package index JSON, or whether I even need to do so. Currently I have my discovery tool inside a tools package installed by toolsDependencies. If I create a discoveryDependencies section, it is supposed to reference a download from my "tools" section? Or do I need to add something else to the JSON? I seem to be missing some piece of the documentation about how the JSON is supposed to look.

4: Serial Monitor isn't working yet. My serial monitor stuff was created before the Pluggable Serial Monitor spec, and still needs to be converted from stdin/stdout to localhost socket.

5: Teensy has its own size utility. The regex-based size isn't enough for the complicated memory on Teensy 4.x. Currently I'm running it by one of the hooks and it has to print to stderr which appears in alarming red. Still need to try using advanced size feature.

@PaulStoffregen
Copy link

PaulStoffregen commented Jan 20, 2022

More progress. Looks like discoveryDependencies just references stuff in the tools section (which wasn't clear to me from the documentation and so far I could not find any other platforms using this feature to serve as any example). Still need to update Teensy's discovery tool for the new JSON format and require state machine.

But I'm stuck on monitorDependencies. Looks like it might be issue #1564.

@PaulStoffregen
Copy link

More progress, got Pluggable Discovery working on Linux. Had to redesign my old discovery code from the 1.8.x IDE, which ignores stdin and just operates in sync mode. With stdin parsing for the required commands, the "board list" command is finally working.

> /tmp/arduino-cli board list 
Port              Protocol Type              Board Name       FQBN                                    Core                  
usb1/1-1/1-1.4    Teensy   Teensy Ports      Teensy 4.1       teensy:avr:teensy41                     teensy:avr            
usb16/16-1/16-1.4 Teensy   Teensy Ports      Teensy MicroMod  teensy:avr:teensyMM                     teensy:avr            
/dev/ttyACM0      serial   Unknown                                                                   
/dev/ttyACM1      serial   Unknown                                                                   
/dev/ttyACM2      serial   Serial Port (USB) Arduino Uno      arduino:avr:uno                         arduino:avr           
                           Serial Port (USB) CONTROLLINO MINI CONTROLLINO_Boards:avr:controllino_mini CONTROLLINO_Boards:avr

@cmaglie
Copy link
Member

cmaglie commented Jan 22, 2022

Hi @PaulStoffregen, great to see progress on this one!

here some random answers:

1: Upload recipe causes GUI-based Teensy Loader to actually perform the upload. That's probably not going to make command-line-only Arduino CLI users happy. I can't find any predefined property to inform my tools whether to run a GUI-based or "headless" upload process is appropriate. @cmaglie - Any suggestion how I should handle this? Is there any way my upload command can detect whether the upload request came from an IDE or CLI?

Unfortunately no (at least nothing comes to my mind right now). Maybe we can set an environment variable to check like ARDUINO_CLI_VERSION=0.20.0? that would provide two information: 1) that the process is started from a command line and 2) the version of the arduino-cli (of course the variable won't be set if running from IDE/gRPC)

2: Boards Manager in Arduino 1.8.19 does not start the Pluggable Discovery process my platform.txt file specifies. A full restart of the Arduino 1.8.19 IDE is needed after installing the package.

this must be fixed in the Arduino IDE 1.8.x. I've never encountered this bug (because we never had a pluggable discovery platform before...).

Also, my discovery utility is older than the Pluggable Discovery spec and speaks the JSON dialect of the Java IDE... still needs to be updated for the new spec.

yes, I see that you successfully updated it, so I consider this part solved

3: I don't understand how to use discoveryDependencies in my package index JSON, or whether I even need to do so. Currently I have my discovery tool inside a tools package installed by toolsDependencies. If I create a discoveryDependencies section, it is supposed to reference a download from my "tools" section? Or do I need to add something else to the JSON? I seem to be missing some piece of the documentation about how the JSON is supposed to look.

You're correct they must be part of the tools section.
Indeed the documentation is missing this piece of information:
https://arduino.github.io/arduino-cli/0.20/package_index_json-specification/#platforms-definitions

4: Serial Monitor isn't working yet. My serial monitor stuff was created before the Pluggable Serial Monitor spec, and still needs to be converted from stdin/stdout to localhost socket.

Yes, that one is a big chunk of work, let me know if I can help in some way.
Our reference implementation (serial-monitor) is made in golang here:
https://github.com/arduino/serial-monitor
It's based on this library that abstracts away all the pluggable monitor protocol (always in golang):
https://github.com/arduino/pluggable-monitor-protocol-handler
I don't know if those may help or not...

https://arduino.github.io/arduino-cli/0.20/platform-specification/#pluggable-discovery
https://arduino.github.io/arduino-cli/0.20/pluggable-discovery-specification/
https://arduino.github.io/arduino-cli/0.20/pluggable-monitor-specification/

5: Teensy has its own size utility. The regex-based size isn't enough for the complicated memory on Teensy 4.x. Currently, I'm running it by one of the hooks and it has to print to stderr which appears in alarming red. Still need to try using the advanced size feature.

If you can link me your sizer utility I can try to push a patch for you.

@matthijskooijman
Copy link
Collaborator

Unfortunately no (at least nothing comes to my mind right now). Maybe we can set an environment variable to check like ARDUINO_CLI_VERSION=0.20.0? that would provide two information: 1) that the process is started from a command line and 2) the version of the arduino-cli (of course the variable won't be set if running from IDE/gRPC)

Would it really make sense to not set that value when running from gRPC? It would indeed allow distinguishing IDE from commandline usage, but I would be otherwise surprised by this. If somehow the discovery wants to know the arduino-cli version, (e.g. to work around a bug in the discovery protocol implementation maybe), then it would not be able to use this variable in gRPC mode.

TBH I haven't looked much at how the gRPC stuff works, but just from reading this comment I have serious doubts about this approach.

@PaulStoffregen, going one step back here, if there is a headless upload available, why not always use that one? That is consistent with most if not all other platforms. What is the gain of using a GUI for upload here?

@PaulStoffregen
Copy link

if there is a headless upload available, why not always use that one?

The intended user experience for Teensy is to show uploading in a GUI. The GUI also gives users troubleshooting and diagnostic info, and offers additional features which have been a well established practice for Teensy over the last 12 years.

What is the gain of using a GUI for upload here?

User experience matters greatly.

@catkins
Copy link

catkins commented Jan 24, 2022

The GUI also gives users troubleshooting and diagnostic info

Would using a headless uploader be able to provide a roughly equivalent user experience by outputting the troubleshooting & diagnostic information to STDOUT, which would then show up in the console in Arduino IDE?

@PaulStoffregen
Copy link

@cmaglie - Any chance to get that environment variable into a nightly build? I've got Pluggable Discovery and Pluggable Monitor working on Linux x86_64. Today I'm going to work on converting Teensy 4 sizer to JSON and updating the Java patches. So the last major issue should be adding a headless upload mode, rather than always running the GUI as Teensy has always done.

@cmaglie
Copy link
Member

cmaglie commented Jan 26, 2022

It would indeed allow distinguishing IDE from commandline usage, but I would be otherwise surprised by this. If somehow the discovery wants to know the arduino-cli version, (e.g. to work around a bug in the discovery protocol implementation maybe), then it would not be able to use this variable in gRPC mode.

The cli version is already passed in the HELLO command in this sense it's useless to pass the version inside an env variable.

Any chance to get that environment variable into a nightly build?

Let me draft something in a new PR, so we can move the discussion there.

@PaulStoffregen
Copy link

Good news! If you've been following this issue and patiently waiting for me to finally publish a first experimental version, now it has finally come. Well, at least for Linux x86_64.

https://forum.pjrc.com/threads/53548-Arduino-CLI-Alpha-Release-Teensy-Support?p=298914&viewfull=1#post298914

If you install and try this, please share any Teensy-specific feedback on the forum thread. Let's only add more messages on Arduino's issue tracking if problems turn up that might be relevant to actual arduino-cli issues.

@cmaglie cmaglie self-assigned this Jan 28, 2022
@per1234 per1234 added status: in progress Work is in progress on this topic: code Related to content of the project itself labels Feb 1, 2022
@PaulStoffregen
Copy link

Quick update for everyone watching this issue & waiting for better Arduino CLI support. Package version 1.56.1 is now available, with support for Windows, MacOS and Linux x86_64. Details here:

https://forum.pjrc.com/threads/53548-Arduino-CLI-Alpha-Release-Teensy-Support?p=299430&viewfull=1#post299430

Pluggable Discovery and Pluggable Monitor are fully implemented on all 3 platforms. Uploading is still done by launching a GUI program, but support for headless mode is planned for future versions. See the forum post for more detail.

@dattasaurabh82
Copy link

I have managed to run and test a build in Github Actions my using Xserver, necessary for the GUI Teensyloader, even for compilation.
Quick and dirty usage here

@PaulStoffregen
Copy link

In case anyone is wondering, I've been really distracted by semiconductor shortage and production issues for the last several weeks. In that time, Arduino did implement the version metadata needed to distinguish GUI versus headless.

#1640
arduino/arduino-ide#790

But IDE 2.0-rc5 still is not using pluggable monitor. The main issue blocking Teensy support is this:

arduino/arduino-ide#769

In normal times I would probably publish a 1.56.2 package to make use of the version info, and then another 1.56.3 package when the new IDE starts supporting pluggable monitor. Still might do that, but right now focusing on the business side (we ran out of Teensy 4.1 last week - more being made now) and probably going to wait until IDE 2.0-rc6 adds pluggable monitor support to use both features.

@KurtE
Copy link

KurtE commented Apr 22, 2022

@PaulStoffregen - looks like RC6 was released yesterday or the day before, but it so far I have not seen anything that went into
RC6 for this... Maybe RC7? Although so far I don't see that as a Milestone.

@PaulStoffregen
Copy link

Don't see anything I can do, other than wait patiently for Arduino to implement pluggable monitor.

@prutschman
Copy link

Looks like pluggable monitor just landed! arduino/arduino-ide#982

@PaulStoffregen
Copy link

PaulStoffregen commented Jun 9, 2022

@prutschman - Yup, and it's working pretty well with the 1.56.1 package. Or at least the snapshot yesterday was. Haven't run it since (instead worked on a Wire library slave mode high frequency noise sensitivity issue today). If you want to give 1.56.1 a try, this is the preliminary package index to add with File > Preferences (or add to arduino-cli.yaml for Arduino CLI).

https://www.pjrc.com/teensy/td_156/package_teensy_index.json

Some documentation and extra info can be found here:

https://forum.pjrc.com/threads/53548-Arduino-CLI-Alpha-Release-Teensy-Support

On msg 178 of that thread, you can find a solution for using Teensy with both Arduino IDE 1.8.19 and Arduino IDE 2.0-rc.

We're in the early days of beta testing Teensyduino 1.57. As always, latest beta can be found on the forum announcements. Next beta (coming in a week or two) will include that 1.8.19 workaround, and (probably) a new package index to use the latest beta on 2.0 nightly builds, and (maybe) some updates to fix minor issues, plus of course the many new Teensy-specific features of 1.57.

But right now, if you want to use Teensy on the latest Arduino 2.0 nightly builds, the old 1.56.1 package file works fine. It's had pluggable monitor all this time. Now you can really use it with the new IDE.

@per1234
Copy link
Contributor

per1234 commented Jun 10, 2022

Closing as resolved by the completion of support for pluggable discovery and pluggable monitor.

@per1234 per1234 closed this as completed Jun 10, 2022
@arduino arduino locked as resolved and limited conversation to collaborators Jun 10, 2022
@per1234 per1234 added conclusion: resolved Issue was resolved and removed status: in progress Work is in progress on this labels Jun 15, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
conclusion: resolved Issue was resolved topic: code Related to content of the project itself type: enhancement Proposed improvement
Projects
None yet
Development

No branches or pull requests