Teensyduino 1.26 Beta #1 Available

Status
Not open for further replies.
Paul

Paul

Administrator
Staff member
Here is a first beta test for Teensyduino 1.26.

The main changes are fixes for Macintosh. USB Serial is fixed for El Capitan.

The installer and Teensy Loader should now work if you have Security & Privacy configured to only allow applications from the mac store and identified developers (which is the default setting). However, you *must* run Arduino at least once before the Teensyduino installer modifies it.


Edit: old beta test linkes removed. Full non-beta release is here:
http://www.pjrc.com/teensy/td_download.html



Here's a complete list of the changes since 1.25:


  • Fix USB Serial on Macintosh 10.11 El Capitan
  • Partially fix Mac signatures (still must run Arduino once before installing)
  • AnalogWriteFrequency supports extremely low speeds (thanks Theremingenieur)
  • Improve tone() changing frequency while running
  • Update libraries: AltSoftSerial, FastLED, ILI9341_t3
  • Add XPT2046_Touchscreen library
  • Improve Ethernet library W5200 reset handling
  • Update SD library examples
  • Add I2S 2-port register bitfield names
  • Initial work on MTP Disk (incomplete)
 
Install and quick compile test went without problems (Mac OS X 10.11.1 El Capitan).

Thank you for mentioning my tiny contribution to analogWriteFrequency(), but I'd prefer to be mentioned with my forum pseudo (Theremingenieur), rather than with the github name (universpharmacie). That github account belongs to my day job's employer and I had to use it for the pull request since the github GUI tool for OS X is not capable to handle more than one single account...

If I find a few minutes during the upcoming weekend, I will still write a little about the extended functionality, so that the table on the website which relates analogWrite frequencies and resolution can be extended.
 
Installing 1.26b1 on 2nd Win10 machine - both okay - but the second I closed the IDE's and left Teensy open - then after all the clicks to get there is just aborts - would be nice if it detected open Teensy Loader up front and said to close before it got all fatal like - or if it gave a back button to retry.
 
mjhilger said:
I know I'm behind the curve, but what version of Arduino IDE will the new software work with?
Click to expand...

1.0.6, 1.6.1, 1.6.3 and 1.6.5.

Every installer always shows a list of the Arduino versions it knows. Admittedly, that info is hidden in the middle of the intro page nobody reads.... but it's always there if you know where to look.
 
Support was dropped for Arduino 1.6.0, 1.6.2 and 1.6.4, because those versions had serious bugs.

1.6.0 and 1.6.2 were quickly replaced by 1.6.1 and 1.6.3, because the bugs were so serious.

1.6.4 was available for quite some time, but it had a really unpleasant bug where libraries using templates and other advanced C++ features wouldn't compile. FastLED was one of the popular libraries impacted.
 
HELP!!

My mac can't even see any Teensy 3.1 on USB since El Capitan update on friday to 10.11.1.
I have a important test goning on in 1 our with some prototypes buld up with the Teensy and I can't load anything on the Teensy right now!!!
 
So far, all El Capitan problems have been related to USB Serial mode. I personally tested 1.26-beta1 with El Capitan. It works.

If your Teensy is already programmed as USB Serial (from an older Teensyduino before this issue was fixed), first unplug it. Make sure Teensy Loader is running. Use the Teensy > About menu to make sure it's 1.26-beta1. Turn off auto mode. Then hold the button while plugging the cable back in. Holding the button will prevent Teensy from running any code that was previously loaded. When you release the button, you should see Teensy Loader recognize the Teensy. If you turned off auto mode, it won't immediately reprogram. Then you can run Arduino with the new Teensyduino and program it with the updated USB code that works properly with El Capitan.
 
Did this with one Teensy and afterwards all others got recognised, too.
Thank you for your always fast answers!!!
 
Hi Paul. Thanks. The verify/upload process is definitely working better now, under 10.11, with this. I have a slightly different issue, but I believe it is 10.11 (10.11.2, specifically) related. When I upload the standard firmata sketch... I get the customary blinky-blinky.. but am unable to connect via firmata to the board... coincidentally, after that first connection attempt, all usb/serial communication stops working (although I do see the device listed under dev, ie. /dev/tty.usbmodem935591)! The board stops responding, regardless of pushing reset, disconnecting, etc. and the entire USB system goes to heck. At this point I can't even view the USB section in System Profiler (see below). My only option at this point is to restart. Once back up, everything is fine, i believe, until again trying to connect to the firmata device (a teensy 3.1 in my case). Any advice?

Screen Shot 2015-10-29 at 12.35.06 PM.png
 
Teensy3.1 USB serial no response after multiple connection in El Capitan 10.11.1.

PaulStoffregen said:
So far, all El Capitan problems have been related to USB Serial mode. I personally tested 1.26-beta1 with El Capitan. It works.

If your Teensy is already programmed as USB Serial (from an older Teensyduino before this issue was fixed), first unplug it. Make sure Teensy Loader is running. Use the Teensy > About menu to make sure it's 1.26-beta1. Turn off auto mode. Then hold the button while plugging the cable back in. Holding the button will prevent Teensy from running any code that was previously loaded. When you release the button, you should see Teensy Loader recognize the Teensy. If you turned off auto mode, it won't immediately reprogram. Then you can run Arduino with the new Teensyduino and program it with the updated USB code that works properly with El Capitan.
Click to expand...

Hi Paul, I reinstalled 1.26-beta1, and programmed 'EchoBoth' firmware to teensy3.1 according your method. Then I use CoolTerm to test. I clicked 'Connect' button, sent '81' and can receive 'USB received:129', it is great！But I do many times like 'Disconnect' - 'Connect' - sent ‘81’， sometimes USB serial no response just after I 'Connect' then sent '81'. The funny thing is if I sent '81' three times, USB serial will give me a correct response, then data transfer is normal. I test many times, if usb serial no response after I 'Connect' and sent '81', always sending '81' three times will activate usb serial. I test this for the self test of my EKG system, the code in OS X Yosemite is fine, but in El Captain, it can not go through. I do not know what was wrong? Could you please give me some advice?

Screenshot 2015-10-29 20.57.52.jpg
 
USB Serial reading on El Capitan

Hi Paul,

Here's another El Captian serial issue:

When I run the code below on 10.11.1 using Arduino 1.6.6 and Teensyduino 1.26, and watch the console, I get the occasional clobbering in random places - some data gets overwritten by data following it.

/dev/cu.usbmodem does not appear to have this problem, but pyserial (2.7) with python (2.7.10) show a similar same loss of data. Previous OSX versions did not do this noticeably. Any suggestions?

The output:
Code: 
123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCD
123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCD
123456789:;<=>?@[B]123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCD[/B]
123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCD
123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCD

The sketch:
Code: 
void setup() {
   Serial.begin(9600);
}

byte count = 0;

const byte BUFSIZE = 64;
byte buffer[BUFSIZE] = {0};

void loop() {
  count = '1';
  for(int i = 0; i < BUFSIZE; i++) {
    buffer[i] = count++;
    if (count > 'Z') {count = '0';}
  }
  buffer[63] = '\n';
 // while (!Serial.available()) {};
  Serial.write(buffer, 64);
}
 
Does this problem appear if I just watch the data arrive in the Arduino Serial Monitor? Or do I have to use pyserial somehow?

I guess my main question is what exactly do I actually run with El Capitan to see the problem?

How frequently does this occur? Should I expect to see it within seconds, or do have I to collect data for hours, days, or weeks?
 
FYI - in case it relates - the SerialMon of IDE 1.6.6 is worse than ever on Windows 10. It is Ctrl-R de-activated during compile and never comes back.

After each compile the IDE (USB) SerMon window must be closed and re-opened on my system as the old one sits there 'grayed' out showing nothing.

It probably doesn't relate as not only is this windows but the above issues don't seem to call out the IDE SerMon - but just in case. I'm going back to TYQT to see if it has developed any new odd behavior. Besides I've got two active Teensy display units and SerMon is one port only.
 
It shows up randomly, about once a second, in the Arduino Serial Monitor.
They are easy to spot because the lines stick out (all the ones I've seen so far).
I can make a PySerial test as well, if that helps.

PaulStoffregen said:
Does this problem appear if I just watch the data arrive in the Arduino Serial Monitor? Or do I have to use pyserial somehow?

I guess my main question is what exactly do I actually run with El Capitan to see the problem?

How frequently does this occur? Should I expect to see it within seconds, or do have I to collect data for hours, days, or weeks?
Click to expand...
 
Still dropping data on El Capitan

Hello Paul,

I've written a little sketch and a python program to easily demonstrate this problem.

On El Capitan, I get 14-15% of dropped/mangled 64 byte blocks consistently.
On Yosemite, I get 0% dropped consistently.
I am using Teensyduino 1.26 and Arduino 1.1.6.

I'd be happy to help fix this in any way :)

Output:
Code: 
python ./readbackTest.rb 
Getting Port
Found Teensy at /dev/cu.usbmodem1346771.
Opening port
Starting to read
Last error:
Expected: 444444444444444444444444444444444444444444444444444444444444444
Received: 4444444444444444444444444444444444444444444444444444444[B]666666666666666666666666666666666666666666666666666666666666666[/B]


OK: 8506, Error: 1494, Error rate [B]14.94%[/B]

Sketch:
Code: 
int i = 0;
const int MAXBUF = 10;
const int USB_BUFSIZE = 65; // 64 + 0 termination
char sprintbuf[MAXBUF][USB_BUFSIZE];

bool send_now = false;

void setup() {
  Serial.begin(9600);
  // Prepare some data
  for (i=0; i< MAXBUF; i++) {
    int j = i*111111;
    sprintf(sprintbuf[i], "%06d%06d%06d%06d%06d%06d%06d%06d%06d%05d%04d\n", j,j,j,j,j,j,j,j,j,i*11111,i*1111);
  }
  Serial.flush();
}

void loop() {
  if (Serial.available() > 0) {
    char command = Serial.read();
    if (command == 'b') {
      send_now = true;
    }
    if (command == 'e') {
      send_now = false;
    }
  }
  if (send_now) {
    for (i=0; i< MAXBUF; i++) {
      // Send 64 bytes as fast as possible. 
      Serial.print(sprintbuf[i]);
    }
  }
}


Python script (uses pyserial):
Code: 
#!/usr/bin/python
import serial
import time

# Find the port the teensy is at, for convenience
def getTeensyPort():
    import serial.tools.list_ports as lp
    for portDict in lp.comports():
        if any("VID:PID".lower() in s.lower() for s in portDict):

            #pull out the VID and PID numbers
            start = portDict[2].find('=')
            middle = start + portDict[2][start:-1].find(':')
            end = middle + portDict[2][middle:-1].find(' ')
            VID = int(portDict[2][start+1:middle], 16) #convert hex string to int
            PID = int(portDict[2][middle+1:end], 16)

            if VID == 5824 and PID == 1155:
                print "Found Teensy at {}.".format(portDict[0])
                return portDict[0]

    # If we have found and returned none, it is an issue.
    raise Exception("Unable to find a Teensy board in USB enumeration.")

print "Getting Port"
port = getTeensyPort()
print "Opening port"
ser = serial.Serial(port)
time.sleep(0.01)
ser.write("b\n") # begin to send
ser.flush()
ok_count    = 0
error_count = 0
lastError = "No Error"
print "Starting to read"
while (ok_count + error_count < 10000): #
    line = ser.readline()
    expected = (line[0] * 63)
    if (line.rstrip() != expected.rstrip()):
        lastError =  "Expected: {}\nReceived: {}".format(expected,line)
        error_count = error_count + 1
    else:
        ok_count = ok_count + 1

ser.write("e\n") # finish sending
ser.flush()

print "Last error:\n{}\n".format(lastError)

print "OK: {}, Error: {}, Error rate {}%".format(ok_count, error_count, 1.0*int(10000.0*(1.0*error_count/(error_count + ok_count)))/100)

View attachment serial_speed_straight.ino
View attachment readbackTest.rb.txt
 
Last edited:
I have run the test script on Windows 7 64 bit and I also get 0% dropped. It looks like the issue is with El Capitan
 
I ran the script on a 64-bit windows 10 laptop and got:

Code: 
C:\sourcecode\Sketchbook\serial_speed_straight>ver

Microsoft Windows [Version 10.0.10586]

C:\sourcecode\Sketchbook\serial_speed_straight>python readbackTest.py
Getting Port
Found Teensy at COM5.
Opening port
Starting to read
Last error:
No Error

OK: 10000, Error: 0, Error rate 0.0%

No errors.
 
I ran the test script on Linux, Fedora22 (64bit) with no errors:

Code: 
$ python serialdebug.py 
Getting Port
Found Teensy at /dev/ttyACM0.
Opening port
Starting to read
Last error:
No Error

OK: 10000, Error: 0, Error rate 0.0%
 
I'm working on this now. I've got a Teensy and USB protocol analyzer connected to an El Capitan machine and it's reproducing the problem. Teensy appears to be sending properly. There's no corrupted or incomplete packets, so this is really starting to look like a bug in El Capitan. I have hunch about the bug (based purely on guesswork about what Apple might be doing), and I have a couple ideas for a workaround.
 
Status
Not open for further replies.
Back
Top