Teensyduino 1.42 Beta #4

[Paul]

Here is a fourth beta test for Teensyduino 1.42.

The main new feature is a "Teensy" section in the Tools > Ports menu
which tries to show Teensy in all modes, not just Serial. New native
(no Java serial library) serial monitor code is also with these ports.


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


Changes since Teensyduino 1.42-beta3

Teensy 3.5 now supports use of 256K RAM
EthernetClient fix for forced connection close
Small speedup to analogWrite for DAC pins
Fix DMAChannel transferSize() on Teensy LC
Fix FTM_CONF register bitfield defs
Update ADC library (Pedro Villanueva)
Audio: Add freeverb mono & stereo
Audio: Granular pitch shift & freeze effects (Bleep Labs)
Audio: envelope status functions
Audio: Fixes to waveform object
Audio: Add variable triangle waveform
Audio: Add modulated waveform, support for freq & phase modulation
Audio: Add simple amp/switch object
Audio: Add PDM input
Update OneWire, very minor changes
PS2Keyboard: add UK & Spanish layouts
TimeAlarms: minor fixes
USBHost_t36: Joystick fixes (KurtE)
Macintosh build now uses 64 bits

[manitou]

Here is a fourth beta test for Teensyduino 1.42.


Changes since Teensyduino 1.42-beta3

Teensy 3.5 now supports use of 256K RAM

OK, 256KB RAM available on T3.5!! I successfully re-ran tests described at
https://forum.pjrc.com/threads/49522...ve-256K-of-RAM

[PaulStoffregen]

@Defragster - Please let me know if you can still get multiple instances of teensy_ports.exe on Windows 10? I'm hoping this bug is gone... but if not, I'll need a little help with reproducing it and testing possible fixes.

[defragster]

@Defragster - Please let me know if you can still get multiple instances of teensy_ports.exe on Windows 10? I'm hoping this bug is gone... but if not, I'll need a little help with reproducing it and testing possible fixes.

I have installed this Beta4 - only done minimal single Teensy code so far but no problem. So nice that recurring callback debug spew in the IDE window is gone. (though I see it filling TLoader Verbose)

I was getting some severe new grief yesterday when I was testing the faulting RAM cross boundary checking. System was hung 'app not responding', but I couldn't get feedback to show what the system was doing - and that code is old news now. Will need to rewrite that to the new core to test again. I did have twin IDE's up - one on T_3.6 and the other to a T_LC - and the JAVA system got twisted.

I just opened a second IDE to T_3.6 - ( First on T_LC ) - hitting "Tools" menu takes some ~8 seconds to display! With TLoader Verbose output in the process. Of course I set the TeensyPort to T_3.6 Com8 - then hit Compile before I opened the teensy_Sermon … but then I opened T_sermon during compile … waiting now for compile to complete to see what happens . . . nothing good:

Teensy did not respond to a USB-based request to enter program mode.
Please press the PROGRAM MODE BUTTON on your Teensy to upload your sketch.

It will not get back in sync. It will program on Button or compile - but never get output to the T_sermon? Quick test with TyCommander shows it to work as expected. Closing that and open T_sermon ( also takes 8 seconds ) - then it never displays anything?
Here is what I have for Verbose - as ZIP since it is 1.44MB:

td142b4_post4.zip

To those on Win 10 - the new Release Version 1803 is out - the new 6 month update from ~May 30. I did not have to manually unblock download on install - but the system did pop up a cute page that I could just hit 'Run' on:

It ran fine with no intervention from Windows Defender ( or my Malwarebytes program ).

[defragster]

Ide's T_sermon's were busted even after closing TLoader - closed IDE's and found these lurking … I count 32 copies of teensy_ports.exe:


My repro steps if not clear above - this is same as I stumbled into on B#3 as a secondary issue :
IDE #1 on T_LC - T_sermon open.

Open IDE #2 : Change to T_3.6, start compile on same sketch, during compile open T_sermon to T_3.6, compile completes and this is where I am.

T_Loader should tell T_sermon to drop the port again before programming?

[defragster]

Trying to do a clean and proper start:
I closed the teensy_ports down and restarted IDE's - some other residual part in memory - Tools menu still 8 second to open - but Tools / Ports does not show 'Teensy' - just "Serial ports".

TaskMan shows this:


Closed Teensy.exe and did end task on the two instances of JAVA - no Windows restart.

Opened IDE #1 to T_3.6 - Teensy_Port is correct [COM8] - compile and upload!

Opened IDE #2 to T_LC - Selected Teensy_Port first [COM11] - change to T_LC - compile and upload!


So far problem seems to only occur when teensy_sermon holds the port open when TLoader attempts to program.

'Tools' Menu item now Instant - not 8 second delayed.

Problem only on initial compile? I can Close T_sermon - start compile - open T_sermon and that works … though it had switched the T_3.6 to IDE_SerMon not teensy_serialmon. And now with two IDE's only one has teensy_ports.exe associated.

Operation seems good - except that oddity:
td142b4_post6.txt

<edit>: Just noted that while still sitting open as above - both IDE's and Teensy's are online. Only these two messages have been added since the attached snapshot just above when I saved the log:

20:19:25.174 (loader): Log saved to the file 'C:\tmp\TD_142\b4\td142b4_post6.txt'.
20:21:29.841 (ports 1): got command: "list"

i.e. :: there are no recurring '(ports...:callback...' messages.

[defragster]

Came back to just the T_LC and it was working - still in the broken state above.

Closed the T_3.6 IDE to get current code as I'm using IDE to edit just now. Re-opened 2nd IDE to get to T_3.6 and the T_LC T_sermon stopped working. The 8 second wait for 'Tools' was back and there was no 'Teensy' under Ports.

I had cleared the TLoader verbose log after prior post - but it was still open. Here is the log since then in case it shows where the crossing IDE's got lost - had to zip as it is 418KB.
td142b4_post7.zip

Closed both IDE's and there are 7 orphaned teensy_ports.exe again in TaskMan.

I cleared log and TLoader was still open - this seems to show where I closed those:

01:16:26.404 (loader): remote connection 3024 closed
01:16:28.050 (loader): remote connection 2280 closed
01:16:29.741 (loader): remote connection 3212 closed
01:16:30.838 (loader): remote connection 2792 closed
01:16:31.829 (loader): remote connection 1652 closed
01:16:32.615 (loader): remote connection 3224 closed
01:16:33.405 (loader): remote connection 1348 closed

> I saved the rest of this 7b log [can provide] - but I need to reboot as T_LC code running differently now and the recurring '...callback...' is still not showing as it did for post #4, though otherwise properly re-opened 2 IDE's and compile/upload/T_sermon working.

The sketch is trapping Memory Fault isr()'s - so USB may be going ODD and I have to Button push to upload. Simple ugly sketch if it matters/helps: MemFault.ino

[brendanmatkin]

MacOS 10.13.3, Arduino 1.8.5, Teensy 3.6, USB Type: Serial, Teensyduino 1.42-beta4

Serial Monitor no longer skips prints but it stops responding after an apparently random number of loops (or time?). After anywhere from 30 to around 2000 loops it stops. The teensy is not crashing - but serial monitor output just stops and will not start again until power cycle or upload new code.

USB Type: Raw HID still prints to serial monitor as expected (that is, it works).

void setup() {
  Serial.begin(9600);
  delay(2000);
  Serial.println("welcome");
  pinMode(LED_BUILTIN, OUTPUT);
}
int i = 0;
bool led = false;
uint32_t counter;
void loop() {
  i++;
  Serial.println(i);
  delay(10);
  digitalWrite(LED_BUILTIN, led);
  counter++;
  if (counter%10==0)led = !led;
}

[defragster]

Windows 10 can run for hours with T_sermon getting 8-9+ MB's in a 10 second interval from BOTH T_LC and T_3.6 with a 5 second pause between those 10 second runs. It seems very fast and robust and no dropped data or issues apparent.

I've moved the two Teensys from hub to port and hub to hub and I need to reselect the Tools/Port and re-open T_sermon - even though the COM# doesn't change. But no problems.

The only way I see a problem is {posted above}: Open IDE, Select Board, Start Compile … while waiting … open T_sermon before compile completes.

<edit> Just to confirm after running both units with high USB output for hours they ran fine and when both IDE's/TLoader were closed there were no sticking teensy_ports parts.

[KurtE]

Started playing with this new release with the T3.5 with more memory.

Trying out my ili9341_t3n with frame buffer. It runs on the T3.5, but there is an issue when I try doing Async (DMA updates).

Looks like I need to do some debugging! Also I already knew there would be issues with SPI1/SPI2 on T3.5 due to only one DMA Source per each of these... May have to refer back to the work I did on SPI library to remember differences on how T3.6 worked from T3.5...

Should also mention: TyCommander does not work with the T3.5 new expanded memory.

[defragster]

Paul Looking after an AnalogWrite question I saw the code in this post

In case of MAX value on Teensy3 analogwrite the value is set digital HIGH … then the pinMode is set to output - it seems that won't work the first time?


Frank B gave a Pull request for swapping this in 3 places : https://github.com/PaulStoffregen/cores/pull/276

[bicycleguy]

iMac macOS 10.13.4, Arduino 1.8.5, T3.6, TL 1.42-beta4

no more 64bit macOS nagging Ya!

No problems so far with lots of Arduino terminal stuff.

[vladn]

Something happened to the analogRead() in the beta4 - reads zeroes (works fine under beta3). I need to investigate further.

[vladn]

analogRead() is OK, there is some memory corruption that did not show up in the previous versions (41 42.b3), still need to investigate...
I think I narrowed it down to sprintf not accepting %.2f spec for a floating number in the beta4. If I do explicit integer conversion and then call sprintf - things work OK.

[KurtE]

Should also mention: TyCommander does not work with the T3.5 new expanded memory.

Fixed , can download latest version (now about 3 hours old) from: https://bintray.com/koromix/tytools/tytools#files

Thanks Niels!

[vladn]

sprintf not accepting %.2f spec for a floating number in the beta4.

Could someone please verify this simple sketch on 3.5 on beta4 with expanded RAM. It works just fine on my 3.6 and 3.2, but fails specifically on 3.5:

void setup() {
  Serial.begin(115200);
  delay (100);
}

void loop() {
  float v = 4.98;
  char buf[64];
  sprintf (buf, "%.2f", v);
  Serial.println ("---");
  Serial.println (v);
  Serial.println (buf);
  delay (1000);
}

[tonton81]

on Teensy 3.5 I get:

---
4.98
4.98
---
4.98
4.98
---
4.98
4.98
---
4.98
4.98

EDIT, nevermind im on 1.42 beta3....

[KurtE]

T3.5 with current beta...

---
4.98
0.00
---
4.98
0.00
---
4.98
0.00
---

Ran same code on T3.6... Current beta..

---
4.98
4.98
---
4.98
4.98
---
4.98
4.98
---
4.98
4.98

[vladn]

This code fails only with a combination of beta4 and T3.5. Every other combination of software version and Teensy type give the correct result. Something to do with a memory expansion ?

[defragster]

Odder still - with IDE 1.85 and TD1.42b4. As noted - works on T_3.6 but I see the same fail on my T_3.5.

I made a simple edit looking to find a way to the issue ... it gets odder still moving the locals to global:

4.98
2.48
---
4.98
2.48

Using this code - the T_3.6 give same expected result and the T_3.5 shows the above:

float v = 4.98;
char buf[64];
void loop() {
  sprintf (buf, "%.2f", v);
  Serial.println ("---");
  Serial.println (v);
  Serial.println (buf);
  delay (1000);
}

<edit>:
Making this const :: const float v = 4.98; takes it back to the Zero display result instead of '2.48' above.

Also this prints 0.00 :: sprintf (buf, "%.2f", 42.3);

These two buf mods print properly:
dtostrf(42.3, 10,4, buf);
dtostrf(v, 10,4, buf);

[PaulStoffregen]

Confirmed, I'm also getting this on Teensy 3.5.

---
4.98
0.00

Very strange. Will investigate soon....

[KurtE]

Could new memory size have issue of location of stack vs heap? Maybe sprint uses heap?

[Frank B]

I get the same results with T3.5.

I wonder why - the same compiler, same libraries, same sprintf..

[tonton81]

In beta3 it works, so you don't need to look too far back to find the problem at least
It's confirmed working here on beta3 of 1.42

[Frank B]

Fix: https://github.com/PaulStoffregen/cores/pull/278
Ram-length / end needs to be 8-byte aligned.

Edit:
Remember to edit boards.txt:
teensy35.upload.maximum_data_size=262136