Teensyduino 1.30 Beta #4 Available

[Paul]

Here is a fourth beta test for Teensyduino 1.30.


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



Changes since Teensyduino 1.30-beta3:

• Fixes for Teensy 3.5 & 3.6
• Update libraries: SPI, FastLED
• Optimize analogRead

[Wozzy]

Is it OK to run this over top of Beta3, or is a new installation recommended?

[defragster]

Wozzy: I've never had a TD beta that didn't essentially freshen all that is Teensy, just always put on top unless the IDE had to change.

[PaulStoffregen]

Yeah, it's ok to install over the top of 1.30-beta3.

One thing the installer does not handle well (or at all really) is the case where files are deleted from the new version. This issue is pretty rare, especially since I tend to avoid deleting files because I know this issue exists. But when a library like FastLED reorganizes and moves or deletes files, it's possible to end up with the new files plus the old one which should be gone.

[defragster]

Using remote desktop to update my Teensy WIN10 Desktop from my laptop.

Started install and went to local machine. On return the DONE screen looked like this. Done button worked to EXIT installer:


IDE 1.6.11 shows correct version. Three open editor files with changes were flagged as changed.

Compiled okay the new sdFat_SDIO_beta code, but left the ksT_3.6 in an odd state. Will have to go down and reset and investigate.

Tried TYQT integration - it wasn't able to communicate with that T_3.6, but showed online. Recompiled for ksT_3.5 and it went offline. Removed TYQT - going down to start over.

[defragster]

Paul I got to my machine and restarted the devices and all seems well without TYQT in the picture.

Posting this on T_3.5 thread I saw the T_3.6 is showing the wrong number of PWM's at 20 not 22?
The code is printing this:: Serial.print( "CORE_NUM_PWM ="); Serial.println( CORE_NUM_PWM );

Also why does Serial.print( "F_MEM ="); Serial.println( F_MEM ); show such an odd number >> F_MEM =25714286?

for T_3.6::

CPU is T_3.6
F_CPU =180000000
ARDUINO =10611
F_PLL =180000000
F_BUS =60000000
F_MEM =25714286
NVIC_NUM_INTERRUPTS =100
DMA_NUM_CHANNELS =32
CORE_NUM_TOTAL_PINS =64
CORE_NUM_DIGITAL =64
CORE_NUM_INTERRUPT =64
CORE_NUM_ANALOG =23
CORE_NUM_PWM =20

[defragster]

Paul one other question:
The Teensy bootloader is on the secondary processor. Is that ever changed once it leaves your hands? That is can you reprogram that chip with a TeensyDuino update?

I ask because TYQT was working better it seems before the TD1.30b4 install. I'm wondering if there are ever changes to improve bootloader behavior that might explain why TYQT is not looking right when it was just before.

[KurtE]

I installed the new beta, which pretty well matched my core stuff, except I see Paul fixed a few comments and the like in Analog so sunk up...

The one thing I brought back in was the outstanding Pull request: https://github.com/PaulStoffregen/cores/pull/166
That grabs the Serial number before going into HSRun mode. As when I tried building the TeensySDIODemo program after the install for the T3.6 at 240mhz, when it finished, it changed Comm Ports, and when I loaded in the latest TyQt it showed the problem of no serial number.

So I patched to the two files and ran it again and now back to the right Comm Port and TyQT knows it is serial #: 2055....

Kurt

P.S. - Defragster as you mentioned there not sure about NUM_PWN being same?

if no one else looks at it, I will take a look in morning.

[defragster]

I did my single file mk20dx128.c patch - just hitting the request before HSRUN - and everything after that goes fine with TYQT.

With Ethernet being a thing I'd vote for PJRC getting and storing ser# and MAC across the realm as needed - for USB and general purposes.

So that works - like yours Kurt across 120+ HSRUN and so does Frank's using the startup_early_hook() call. A single uniform solution would be cool, PJRC does it anyhow - then just one or two static 32 bit values and a macro or function?

[defragster]

Looking at KS - I'm not sure how "25 Analog Inputs" squares with "CORE_NUM_ANALOG =23", are the two ADC's analog inputs too?:

62 I/O Pins (42 breadboard friendly)
•25 Analog Inputs to 2 ADCs with 13 bits resolution
•2 Analog Outputs (DACs) with 12 bit resolution
•20 PWM Outputs (Teensy 3.6 has 22 PWM)

[KurtE]

Looking at KS - I'm not sure how "25 Analog Inputs" squares with "CORE_NUM_ANALOG =23", are the two ADC's analog inputs too?:

I put in Pull Request: https://github.com/PaulStoffregen/cores/pull/172
To separate the two sets of counts, and updated PWM to 22 on K66 and update Analog counts on both (25 and 27)

Not sure if Paul needs/wants to pull this in for this release or not...


On Other issue (T3.6 Serial #):

Will try your single file change for getting the serial number. Personally don't care which approach is taken, but would be nice if one was, as without it, I get random Serial ports on the different platforms, especially if you plug in two of them.

Edit:
Tried out the single file change and it appears like the serial number is working updated comments on pull request. Can either change/do other Pull or ....

[PaulStoffregen]

We really need this long-overdue release to support Teensy 3.2, LC and older boards.

I'm freezing all updates for Teensy 3.5 & 3.6 in Teensyduino 1.30. Stuff like the eeprom & serial number in HSRUN will get merged after 1.30 releases, hopefully very soon. I'll begin betas for 1.31 in just a couple weeks, so there won't be a long wait. My general plan is a non-beta 1.31 release in mid-October around the time most people have received their 3.5 / 3.6 boards.

For now 1.30, I want to focus on stable for 3.2, LC and older.

[PaulStoffregen]

Has anyone tried this with FastLED using hardware SPI and APA102 LEDs?

If not, I'll dig my APA102s out of a box later today.....

[defragster]

I have my dotstar strip and a prop for T_3.1 and the T_3.5/T_3.6. Just need to find a quick sample to setup.

I just noticed a bare TEENSY® 3.1 on my desk - so teensy compared to the hulking KS units!

I posted an HSRUN edit for serial# - harder to do the PULL than the code - that was T_3.6 ifdef specific. Doing this read before HSRUN as far as I saw made the value usable thereafter the old ways, including USB usage for TYQT and other.

	// if we need faster than the crystal, turn on the PLL
   #if defined(__MK66FX1M0__)
    #if F_CPU > 120000000
	*(uint32_t *)&FTFL_FCCOB3 = 0x41070000;
	FTFL_FSTAT = FTFL_FSTAT_CCIF;
	while (!(FTFL_FSTAT & FTFL_FSTAT_CCIF)) {}
	SMC_PMCTRL = SMC_PMCTRL_RUNM(3); // enter HSRUN mode
	while (SMC_PMSTAT != SMC_PMSTAT_HSRUN) ; // wait for HSRUN
    #endif

[defragster]

IDE 1.6.11 installed with TeensyDuino 1.30 beta4 on Windows 10 Pro

DOTSTAR #30 count strip runs from Prop shield on T_3.2:
> Prop shield 9DOF tracking sketch
> Cylon sketch modified to my strip on Prop.

Cylon sketch Works on second Prop_LC shield:
> T_3.1
> T_3.5
> T_3.6 beta3

#include "FastLED.h"

#define NUM_LEDS 30
//#define DATA_PIN 7
#define DATA_PIN      11
#define CLK_PIN       13

CRGB leds[NUM_LEDS];

void setup() { 
	Serial.begin(57600);
	Serial.println("resetting");
//	LEDS.addLeds<WS2812,DATA_PIN,RGB>(leds,NUM_LEDS);
  pinMode(7, OUTPUT);
  digitalWrite(7, HIGH);
  FastLED.addLeds<APA102, BGR>(leds, NUM_LEDS); // PJRC
	LEDS.setBrightness(84);
}

// rest unchanged

[Frank B]

For now 1.30, I want to focus on stable for 3.2, LC and older.

Sounds like a good plan

[Frank B]

Paul one other question:
The Teensy bootloader is on the secondary processor. Is that ever changed once it leaves your hands? That is can you reprogram that chip with a TeensyDuino update?

Tim, I *think* I have read a long time ago that the teensyloader.exe updates that chip sometimes. I'm not sure, wether i'm remember that correctly or not..

[Frank B]

Paul, did you include the serial-# for HS_RUN ?
This would be good as a *last* import to the current version.
The problem is, if you change between <=120MHz and >120MHz, then Teensys get a new COM-Port, at least with windows.... that's a bit annoying... esp. for users who don't use TYQT.

[defragster]

Frank - Paul noted above he didn't want to do any changes to TD_1.30 other than stabilizing the already shipping models.

I agree with you that the failed Serial number makes using the HSRUN T_3.6 a real bother, and I proposed what I found to be a minimal K66 specific edit for this case only and post #14 above from some days back. It results in the current way of reading that area to work as it seems to pre-read that before the voltage wall goes up and the read seems to persists - if not forever - at least until the usb_init completes and some time after in typical sketches.

In fact the only avoidable trouble in the whole Beta test process to be honest was shipping the T_3.6 PROTO boards with no serial number set. Had they had at least a placeholder number this could have been resolved sooner to better effect. And with less trouble in using them.

[KurtE]

We really need this long-overdue release to support Teensy 3.2, LC and older boards.

I'm freezing all updates for Teensy 3.5 & 3.6 in Teensyduino 1.30. Stuff like the eeprom & serial number in HSRUN will get merged after 1.30 releases, hopefully very soon. I'll begin betas for 1.31 in just a couple weeks, so there won't be a long wait. My general plan is a non-beta 1.31 release in mid-October around the time most people have received their 3.5 / 3.6 boards.

For now 1.30, I want to focus on stable for 3.2, LC and older.

Sounds great. Would be good to have a released version that supports the current released version of Arduino.

As for when you take in new pull requests, makes complete sense. For example the one about reporting the wrong number of PWM or Arduino pins, while the change is probably safe (ie. change a few #defines that really are not used anywhere), no reason to hold up getting this release out the door.

[defragster]

Paul:
In July I took an older machine with virgin HDD with Win7 Pro upgraded to Win10 PRO and JUST put on IDE 1.6.11 and TD 1.30b4 and using '# pragma message "FastLED version 3.001.001"' sketch of CYLON and BLINK compiled and uploaded and ran with no issues one each on the Beta 1&3 K66's I got.

So on a fresh Win 10 machine with those Arduino tools - including FASTLED - all seems well. { whine - since I didn't need to use the Serial USB to debug with no serial # /whine }

NOTE: on first plugging in a SERIAL running Teensy, Windows 10 did interrupt for 'Installing USB Serial', so that hasn't changed.

[PaulStoffregen]

I've (finally) released Teensyduino 1.30.

http://www.pjrc.com/teensy/td_download.html

[KurtE]

- Any changes from beta 4?

[PaulStoffregen]

Just a minor fix in TimerOne & TimerThree. Otherwise it's pretty much identical to beta4.

[KurtE]

FYI - I updated to this release, then merged in my later changes and everything is happy!

Also installed Arduino 16.11 Plus TeensyDuino 1.30 on Odroid and so far looks like it works

I plugged in T3.6 beta board in to it, and was able to program Blink. First compile took maybe 15-20 seconds, but 2nd compile took about 5, which is not to bad when it is sitting maybe 15 feet from me and no cable connected from here...

Here shows picture of my desktop with Arduino running on it, plus VNCViewer to Odroid XU4 desktop, with Arduino running.



Forgot to mention: I coppied my latest version of sources in Teensy3 over to Odroid and rebuilt blink and now lsusb -v shows proper serial #