Teensyduino 1.43 Beta #2

Status
Not open for further replies.
Paul

Paul

Administrator
Staff member
Here is a second beta test for Teensyduino 1.43.


Old beta download links removed. Please use the latest version:
https://www.pjrc.com/teensy/td_download.html


Changes since Teensyduino 1.43-beta1

Fix for Arduino 1.8.6 startup (Arduino issue #7917)
Fix SerialPlotter for Ports(Teensy)
USBHost_t36 fix for Gigabyte keyboard (thanks KurtE)
OctoWS2811 update movie2serial.pde
Remove BYTE define, previously for pre-1.0 Arduino compatibility
Update WS2812Serial documentation
Improve installer help dialog on Windows
 
Yeah I can’t wait for testing. Downloading now.. 1.43#1 give me pains and mess. Couple libraries broken and no chance to compile any sketch with Teensy 3.2/3.1 on MacBook Pro ElCapitan 10.11.06
Unfortunately I overwritten 1.43#1 and now I cannot get back to 1.42
I had same problems with WS2812Serial and so on
 
I did a simple test with SerialPlotter and it does work as long as u have some sort of delay in the delay in the loop (I used a delay(1) for test. If you don't have a delay it works and eventually hangs the sketch to the point I have to go into task manager and kill the whole java process.
Code: 
void setup() {
  Serial.begin(115200);
}

void loop() {
  Serial.print(1); Serial.print(",");
  Serial.print(2); Serial.print(",");
  Serial.print(3); Serial.print(",");
  Serial.println(4);
  
  //delay(1);
}

One other thing I just noticed (I am assuming by design) though. If I use COMx(teensy 3.x) I can see data streaming on the serial monitor and the plotter. However, if I use COMx(teensy) not it printed to the serial monitor or plotter. Just a note.

Mike
 
I moved the offending libraries back into the libraries directory and arduino-1.8.6_1.43_b2 starts up without any problems, although it is a bit slower.
When I run arduino_debug, it prints out some, but not all, of those plus a few more that it didn't complain about before. Then it prints them all out another 3 times. But under normal startup I don't see that anyway so no biggie.

Pete
 
Diodac said:
Unfortunately I overwritten 1.43#1 and now I cannot get back to 1.42
Click to expand...

You can always just download a fresh copy of Arduino 1.8.5 and install 1.42 into that copy.

The installers don't support downgrading, because each installer has no way to know which files need to be deleted because they were added by future version installers.
 
el_supremo said:
I moved the offending libraries back into the libraries directory and arduino-1.8.6_1.43_b2 starts up without any problems, although it is a bit slower.
When I run arduino_debug, it prints out some, but not all, of those plus a few more that it didn't complain about before. Then it prints them all out another 3 times. But under normal startup I don't see that anyway so no biggie.

Pete
Click to expand...

Teensy 3.2, 1.43.2 on 1.8.6 on OSX El Capitan 10.11.06

Exploration menu
slowly.. slowly like turtle, huge lags, once even close down when I try go through menu.

Compilation
Now all libs is ok, I was able compiled my very complex code witch interrupts, and deep level setting, DMA, Timers, ADC and so on. Couple of Tabs.
I was surprised, because any errors and compilation was around 50% faster than on 1.8.5!!!! :cool:
Much better than 1.43.1 but the lags is weird during menu exploration.
It was the same thing with 1.42 when was beta 7 or so, I don't remember now, exactly but after installation proper 1.42 lagging problem disappear.
I hope get soon beta 3 ;) without lags. But Im happy that now I get it to work.

Thank you Paul, for your hard work for better stuff.
 
Can you help me with a little more info, so I can try to figure out what's causing the lag?

First, if your Mac isn't displaying the time with seconds in the menu bar, click the time and choose "Open Date & Time Preferences". The click the "Clock" tab and check the "Display time with seconds" box. Then you should see the time in your menu bar showing seconds.

When the lag happens again, please write down the time to the nearest second. Or if it happens multiple times, get the time to the nearest second for each lag. Just a few recorded is plenty, and even 1 would tremendously help, with the corresponding verbose info.

A minute or two later, ideally after another upload to Teensy, go into the Teensy Loader's Help > Verbose Info. Please copy all the log from around those times (maybe a minute before and after each) and post it here. Of course, also tell me those times you wrote down, since the verbose info won't actually tell me when the Arduino GUI lagged.

To figure out what's going wrong and causing those lags, I really need you to capture that verbose info so I can see the detailed log of what really was done. The answer is probably buried in all that info, but I can't see what really happened until you capture this verbose info during one the lags.
 
Okay Paul not a problem, I will keep records when happens and what I done in this time.
I remember that the same things happened on 1.42 and when lags get Arduino hang, mac restating itself with kernel panic, it happens also by Java but I’m not 100% sure now. At this time situation looking almost the same. Okay I will collect issues and writing it here.
 
Yikes, there should *never* be a kernel panic! Everything Teensyduino does is user-mode stuff using Apple's published APIs. No kernel driver stuff is ever installed.
 
PaulStoffregen said:
Yikes, there should *never* be a kernel panic! Everything Teensyduino does is user-mode stuff using Apple's published APIs. No kernel driver stuff is ever installed.
Click to expand...

I know that should be, but after reset I got, well know mac users , welcome screen inform me about that.

I also keep attention on others programs, but they working fine
just in case first now I will do some refreshments on my machine, and again installing fresh java and other configuration things.
Because we need be sure that my machine running without any problems. Tracking issues will be more accuracy.
 
I haven't tested this with 1.43 yet, but it appears that teensy 3.2 hardware with the teensyduino 1.42 and arduino 1.8.5 has a USB buffering issue.

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

void loop()
{
	static uint8_t buf[4096];

	for(unsigned i = 0 ; i < sizeof(buf) ; i++)
	{
		while(1)
		{
			int c = Serial.read();
			if (c == -1)
				continue;
			buf[i] = c;
			break;
		}
	}

	// and check for proper pattern
	// every 4 bytes should increment
	uint32_t x = ((uint32_t*) buf)[0];

	unsigned fail = 0;

	for(unsigned i = 0 ; i < sizeof(buf) ; i+=4, x += 1)
	{
		uint32_t y = ((uint32_t*) buf)[i/4];

		if (y == x)
			continue;

		Serial.print(i, HEX);
		Serial.print(" ");
		Serial.print(x, HEX);
		Serial.print("!=");
		Serial.print(y, HEX);
		Serial.println();
		fail++;
	}

	if (fail != 0)
	{
		Serial.print("FAIL ");
		Serial.println(fail);
	}

	// and simulate a flash write delay to force USB buffering
	delay(10);
}

Feed this with serial data from:
Code: 
#!/usr/bin/perl
use warnings;
use strict;

for(my $x = 0 ; $x < 8*1024*1024 ; $x+=1)
{
        print pack("V", $x);
}

After a few megabytes it gets an failure when the previous 64 bytes are replayed:

Code: 
......22C FD88B!=FD8AB
230 FD88C!=FD8AC
234 FD88D!=FD8AD
238 FD88E!=FD8AE
23C FD88F!=FD8AF
240 FD890!=FD8B0
244 FD891!=FD8B1
248 FD892!=FD8B2
24C FD893!=FD8B3
250 FD894!=FD8B4
254 FD895!=FD8B5
258 FD896!=FD8B6
25C FD897!=FD8B7
260 FD898!=FD8B8
264 FD899!=FD8B9
268 FD89A!=FD8BA
2A8 FD8AA!=FD7AA
2AC FD8AB!=FD7FB
2B0 FD8AC!=FD7FC
2B4 FD8AD!=FD7FD
2B8 FD8AE!=FD7FE
2BC FD......

With 1.6.8 and an ancient teensyduino this error never occurs. What's interesting is only that 64 byte block is in error; the stream re-synchronizes afterwards.
 
Last edited:
Just to confirm, I run this and did manage to reproduce the error. Will investigate soon...

sc.png
 
hudson said:
With 1.6.8 and an ancient teensyduino this error never occurs.
Click to expand...

The regression definitely started with version 1.36.

1.36 didn't change anything significant in the USB serial code, but we did jump from gcc 4.8 to 5.4.

The other thing I've discovered is the bug only happens (using 1.43-beta2) with -O2 optimization, which is "Faster" in Tools > Optimize. With -O1, -O3, -Os or -Og, the bug doesn't happen.

I've tracked it down to usb_dev.c. Putting a pragma at the top to force that file compiled with different optimization "solves" the problem. But I've put hours into trying to compile individual functions with different optimize attributes, with very little success learning which function is responsible. When almost any of the functions use -O2, the bug happens.

I'm not ready to conclude this is a bona-fide compiler bug. It may be some very subtle bug in the code which just hasn't mattered.

At this point, I'm still undecided on what best thing to do for a 1.43 release. Maybe just put a pragma in the file? Or maybe change the default optimization to -O3, just in case this really is a subtle compiler bug with -O2?
 
I briefly confirmed it happens on 3.6, but otherwise I've done all my testing on 3.2.

This test takes quite some time to send as 32 megs of data, due to the inefficient receive code and the 10 ms delay for buffering, plus 12 Mbit/sec USB bandwidth limit. When the problem is present, I found a single run usually but not always reproduces the problem. Doing 2 or 3 runs per test makes this a very slow process. I ran it hundreds of times last night...
 
Paul, not sure if you have run across this yet but out of curiosity i installed arduino as a windows app and as a result teensyduino was, for me, impossible to install. there was no suitable path listed in the teensyduino installer. as a matter of fact arduino as an app was not even listed in windows "programs and features" as uninstallable. i guess this is the next phase as i had never seen arduino as an app before. anyway, by right clicking on arduino as listed in the windows menu i was able to uninstall and then just download arduino and install the old way.
 
defragster said:
Paul - about your text in :: https://forum.pjrc.com/threads/53380-Issue-w-Teensyduino-1-42-install?p=186104&viewfull=1#post186104

...
Click to expand...

dkryder said:
Paul, not sure if you have run across this yet but out of curiosity i installed arduino as a windows app and as a result teensyduino was, for me, impossible to install. there was no suitable path listed in the teensyduino installer. as a matter of fact arduino as an app was not even listed in windows "programs and features" as uninstallable. i guess this is the next phase as i had never seen arduino as an app before. anyway, by right clicking on arduino as listed in the windows menu i was able to uninstall and then just download arduino and install the old way.
Click to expand...

@dkryder - follow link in the post above - this is a known issue and attempt to detect and provide notice is underway. What installer was used and what was shown on failure?
 
dkryder said:
installed arduino as a windows app and as a result teensyduino was, for me, impossible to install
Click to expand...

Did you run this 1.43-beta2 installer? Or were you using 1.42 or any prior version?

I ask because the help dialog (which shows when you click the "?" button beside the "Next" button that won't enable) was redesigned. Still a big unanswered question is whether this new design is effective at informing people about the Windows App version. So I'm asking if you ran this beta, or any prior version before the help dialog redesign.
 
yes, i was using 1.43-beta2 linked at the top of this page. and i had just fresh installed the arduino as a windows app which was installed by the windows app store. additionally, it was the only arduino copy installed on this machine.
 
Maybe we need to find another way to make this info more visible to Windows users? Any ideas? (and don't say to document on the first screen.... experience has shown *nobody* using Windows reads anything on the first screen)
 
Status
Not open for further replies.
Back
Top