K64 Beta Test :: Teensy 3.5

Status
Not open for further replies.
Good to see the SSD1306 works for you on T_3.5, I moved it across the various I2C ports with the NOX771 work done on T_3.6 to good effect. I found the same issues you did - having to change the defaults. I think that is the common display, putting those as the defaults would be good.

OT - but why does the F_MEM on T_3.6 have such an odd number? I'll post the T_3.6 numbers elsewhere as the PWM count is WRONG? Should be 22.

Using the TD_1.30b4 on my IDE 1.6.11 I get these numbers - Hey Kurt - look at the digital pin count!::
CPU is T_3.5
F_CPU =120000000
ARDUINO =10611
F_PLL =120000000
F_BUS =60000000
F_MEM =24000000
NVIC_NUM_INTERRUPTS =86
DMA_NUM_CHANNELS =16
CORE_NUM_TOTAL_PINS =64
CORE_NUM_DIGITAL =64
CORE_NUM_INTERRUPT =64
CORE_NUM_ANALOG =23
CORE_NUM_PWM =20
Click to expand...

and 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
Click to expand...
 
manitou said:
I assume snooze will need some K64 mods. I tried duff's K66 mods at https://github.com/duff2013/Snooze_V6_Beta and got the sleep example to work on K66, but example doesn't compile on K64.
Click to expand...

snooze has been updated for K64 (though not tested by duff). Latest compiles on K64 and sleep example appears to be working (1.2 ma), flashes LED every 5 seconds or can jumper pin 21 or 22 to ground to flash LED out of sleep. I didn't try the many other features.
 
defragster said:
Good to see the SSD1306 works for you on T_3.5, I moved it across the various I2C ports with the NOX771 work done on T_3.6 to good effect. I found the same issues you did - having to change the defaults. I think that is the common display, putting those as the defaults would be good.

OT - but why does the F_MEM on T_3.6 have such an odd number? I'll post the T_3.6 numbers elsewhere as the PWM count is WRONG? Should be 22.

Using the TD_1.30b4 on my IDE 1.6.11 I get these numbers - Hey Kurt - look at the digital pin count!::


and for T_3.6::
Click to expand...

Hi Paul and Defragster:

I made a quick update to core_pins.h to take care of the recent changes:
Needed to update K66 to say it now has 22 PWM pins and updated both for Analog pins: K64 has 27 and K66 has 25
Pull Request: https://github.com/PaulStoffregen/cores/pull/172
 
I'm having a little trouble with the "videoplayer" - it does not work on the 3.5, but it works on the 3.6 with 120MHz..
Currently, i have no idea why. Unfortunately.
- DMA to display works
- sdfat works
but not both together.
 
Frank B said:
I'm having a little trouble with the "videoplayer" - it does not work on the 3.5, but it works on the 3.6 with 120MHz..
Currently, i have no idea why. Unfortunately.
- DMA to display works
- sdfat works
but not both together.
Click to expand...
Let me know if there is something that you want some of us to look at...
 
thank you :) ..at the moment, it is too much fiddling.. :)
But I want to post the whole code anyway, in a few days.

edit:
I think i have found the reason.. I'll check this tomorrow, it's too late now.
 
Last edited:
Looking at the back of the T_3.5 card I see my Pre-Order units have the corrected card text for : ' Do not apply more than 3.3v to A...'

Did all the cards go out like that?
 
by "Pre-Order units" I guess you mean kickstarter units?
Unfortunately no: back of mine says "Do not apply more than 5V to A10, ..."
 
Last edited:
I've installed teenyduino 1.30 and connected my 3.5 to PC and the led is blinking very nicely :)
The teeny boards are listed in the IDE OK but no COM port appears so I can't connect to my 3.5 ... yet.
Being a teensy newbie I've been hunting around for next steps ...
I've read Getting Started, this thread and K66 Beta Test thread but not sure what I should do next.
Perhaps I have to install teensy3 CORES ?

Hoping someone can point me in right direction ...
 
ninja2 said:
by "Pre-Order units" I guess you mean kickstarter units?
Unfortunately no: back of mine says "Do not apply more than 5V to A10, ..."
Click to expand...

'Pre-Orders" were those ordered first outside the KS. I only got the big batch of T_3.6's in KS so I got T_3.5's after those shipped ( the next day)

There was a printing issue on the cards regarding that text ( noted in post#1 ) - I'll leave it there as there seems to be a mix where the wording changed after initial printing to the appropriate 3.3V notice

ninja2 said:
I've installed teenyduino 1.30 and connected my 3.5 to PC and the led is blinking very nicely :)
The teeny boards are listed in the IDE OK but no COM port appears so I can't connect to my 3.5 ... yet.
Being a teensy newbie I've been hunting around for next steps ...
I've read Getting Started, this thread and K66 Beta Test thread but not sure what I should do next.
Perhaps I have to install teensy3 CORES ?

Hoping someone can point me in right direction ...
Click to expand...

The shipping Teensy Blink does not have 'USB Serial" support - by design to reduce Windows power up confusion over driver installs for new users (pre Win_10). Until you install a fresh "USB Aware" sketch it won't have a USB presence as a COM port.

It will show up if you set USB Type Serial - as noted at this link with a sample sketch.

That sketch will appear as USB and get a COM# port assigned - and then print. I've just considered a trivial update it to add ECHO back of typed characters to show complete function it there.

Something like this untested code added to the bottom of that sketch after and outside of loop() - anything arriving USB will be ECHO'd back out USB:
Code: 
void serialEvent() {
  while (Serial.available() ) {
    Serial.write( Serial.read() );
  }
}
 
OK I'll give that a go, but can you clarify this bit in that linked thread:
"Tools /CPU Speed - make sure chosen speed is not marked (No USB)"
For the 3.5 my IDE lists about 9 CPU speed choices from 120MHz and working down, and choices from 16MHz to 2MHz include "(no USB)". Should I choose one of these? Which speed is best for first attempt?

UPDATE #1: success :) .... I have comms using basic sketch even with CPU speed: 120Mhz.

UPDATE #2: backward step :( ... to see if I could do a simple update to the sketch, I made some trivial additions, verified, then pushed the progam mode button to instigate upload, but no luck. Now even Windows10 does not beep when I plug the t3.5 in. Seems I don't have the sequence right yet ?


(PS: happy to branch this discussion out to a separate "getting T3.5 or T.3.6 going - newbie queries" thread if you'd prefer)
 
That note was to say choosing a speed with (No USB) support ( the slowest speeds ) will override the selection of USB Serial, so don't pick those and expect it to show on USB.

Any faster speed is designed to work with USB Serial selected. On the T_3.5 the default speed is 120 MHz so that is the 'normal' choice.

It should just work - the other notes in that linked post are for when it doesn't. Though the notes should be accurate to scan the settings to see it work in any case if a working sketch was previously uploaded. It is possible the alterations you made made it non functional, or that Windows USB is confused from your efforts and giving you a time-out. Re-plugging the Teensy with the button held details there to upload a working sketch may clear that up to repeat.
 
yes now it's working fine again. thanks again

In experimenting with that simple test sketch it seems to take a "long" time before the 3.5 can output on serial, to extent some output never appears. For example with the modified code below only line2 and line3 are output, but not line1 even with a 100ms delay just before.

Code: 
#define CJ_ID "teensyTest01.a"
/* see
https://forum.pjrc.com/threads/31518-Can-t-communicate-with-Teensy-3-2-through-Teensyduino?p=88073&viewfull=1#post88073
*/

#define qBlink() (digitalWriteFast(LED_BUILTIN, !digitalReadFast(LED_BUILTIN) ))  // Pin13 on T3.x & LC

#include <Streaming.h>

void setup() {
  Serial.begin(115200);
  delay(100);
  Serial << "\nline1: *** " << CJ_ID << " ***" << '\n';
  pinMode(LED_BUILTIN, OUTPUT);
  digitalWrite(LED_BUILTIN, HIGH);
  while (!Serial && (millis() <= 4000)) { qBlink(); delay(50); }
  Serial << "line2: Setup() OK :: millis()==" << millis() << '\n';
  Serial << "line3: *** " << CJ_ID << " ***" << '\n';
}

elapsedMillis emilBlink;  // Teensy way to delay action without delay()
int8_t loopCount = 0; // Print a NewLine periodically

void loop() {
  if ( emilBlink > 1000 ) {
    qBlink();
    emilBlink = 0;
    Serial.print(".");
    loopCount += 1;
    if ( 40 < loopCount ) {
      loopCount = 0;
      Serial.println("X");
    }
  }
}

Here's the output I get on Serial monitor:

line2: Setup() OK :: millis()==850
line3: *** teensyTest01.a ***
.........................................X
.........................................X
...

Any suggestions?
 
If you have the serial port being monitored, and then you upload code, it will catch the display earlier in the cycle, and should show the first line of code.

Most of us have code similar to this in our setup function:

Code: 
  Serial.begin (9600);
  delay (1000UL);

  // wait up to 3 seconds for the Serial device to become available
  while (!Serial && (millis () <= 3000))
    ;
 
The code above waits 4 seconds and then starts with or without a connection from the SerMon. If it starts without the output can be lost.

This is why you are not seeing any sign of the "line1:..." text - it is before that "while (!Serial && (millis() <= 4000))" statement.

In fact your Serial is online very quickly at 850 milliseconds!

Here is a revised version of my sketch - you will see a FAST blink for up to 4 seconds as it waits for serial to come online. In this version I also turned on USB ECHO - anything sent in over USB will echo back showing you it is working bi-directionally.
Code: 
// https://forum.pjrc.com/threads/31518-Can-t-communicate-with-Teensy-3-2-through-Teensyduino?p=88073&viewfull=1#post88073
#define qBlink() (digitalWriteFast(LED_BUILTIN, !digitalReadFast(LED_BUILTIN) ))  // Pin13 on T3.x & LC
elapsedMillis emilBlink;  // Teensy way to delay action without delay()
int8_t loopCount = 0; // Print a NewLine periodically

void setup() {
  Serial.begin(38400);
  pinMode(LED_BUILTIN, OUTPUT);
  digitalWrite(LED_BUILTIN, HIGH);
[B]  while (!Serial && (millis() <= 4000))[/B]
  {
    if ( emilBlink > 100 ) {
      if ( ++loopCount % 2 ) emilBlink = 50; else emilBlink = 0;
      qBlink();
    }
  }
  Serial.print("\nSetup() OK :: millis()==");
  Serial.println(millis());
  emilBlink = 1000;
  loopCount = 0;
}

void loop() {
  if ( emilBlink > 1000 ) {
    qBlink();
    emilBlink -= 1000;
    Serial.print(".");
    loopCount += 1;
    if ( 40 <= loopCount ) {
      loopCount = 0;
      Serial.println(millis());
    }
  }
}

void serialEvent() { // Arduino supplied function called when data arrives
  while (Serial.available() ) { // ECHO and USB input back to terminal
    Serial.write( Serial.read() );
  }
}
 
OK so a teensy needs a second or two (or 4) to get Serial port running. I can live with that, although it's interesting that's not required on Uno, Mega or Due.

I've updated my teensy test sketch using your enhancements ... thank you
 
Last edited:
ninja2 said:
In experimenting with that simple test sketch it seems to take a "long" time before the 3.5 can output on serial, to extent some output never appears. For example with the modified code below only line2 and line3 are output, but not line1 even with a 100ms delay just before.
Click to expand...
I'm not at all convinced that Teensy is slower. It behaves differently from Arduinos. While the USB serial connection is not established, Serial.write doesn't accept your data and returns a '-1' as result value. The "while(!Serial) ;" code mentioned above waits for the USB serial connection to be established.

Teensy uses the standard Windows USB drivers (USB CDC or USB HID depending on the configuration), the standard Arduinos use FTDI drivers for their FTDI USB -> serial converter.
 
As noted by tni the Teensy is faster at getting online. difference is that a uno and mego (unsure how due is running) have the FTDI chip already running and connected to your PC as a USB device that is static during reprograming. So a rebooted Teensy heads off through the startup code and the serial monitor will not show anything until your PC decides to notice it's there. The delay code above forces a halt until USB enumeration has happened, and software on the PC (normally the serial terminal) has started listening. Also worth noting that opening a new serial terminal reboots a uno/mega but doesn't do anything to a Teensy, though the window is much better behaved about connecting now.

Common failure mode for example code is to not make it 'or' in the delay logic and they hang forever if for any reason there is no serial device connected.
 
Last edited:
ninja2 said:
OK so a teensy needs a second or two (or 4) to get Serial port running. I can live with that, although it's interesting that's not required on Uno, Mega or Due.
Click to expand...

I'm going to guess you're using a pre-10 version of Windows?

Arduino Uno, Mega & Due's programming port have a dedicated USB-serial converter chip. From your PC's point of view, the USB serial remains plugged in and connected the entire time.

Arduino Due's native port, and Teensy, and Arduino Leonardo & Micro, and Arduino MRK101 and others use native USB. From your PC's point of view, the USB cable disconnects after uploading is completed. Then it reconnects when your sketch begins running. When the USB reconnects, your PC goes through a process called USB "enumeration" where it reads info about which USB device was just connected. This process takes time. Older versions of Windows (before version 10) are particularly slow. Mac, Linux and Windows 10 do it quickly, but the process still takes about a second.
 
thanks tni, Gremlin and Paul, all your inputs are a great help in my oh-so-gradual teensy-ization.

My PC's are all Windows 10. Maybe that's why I'm seeing Serial startup times of only 850 - 1000ms

Given opening a new serial monitor doesn't reset a teensy, and there's no reset button - is there a way to reset a teensy when it's PC connected?

I'm still hoping someone can point me to the schematic diagrams for 3.5/3.6 ...
 
bump ...

1) how can I (soft) reset a teensy when it's PC connected?

2) can someone point me to the schematic diagrams for 3.5/3.6 ... or let me know if they don't exist yet (or never will?).
 
Status
Not open for further replies.
Back
Top