Teensy 4.0 First Beta Test

Status
Not open for further replies.
Is the ON/OFF Pin located on the end or bottom of the board? I can't tell from this pinout post.

I tried to clarify that with this yesterday :: (bottom side view - ref note the VBAT/3V3/GND/PGM end pins are in same order as on T_3.x)

Code:
          (bottom side view - ref note the VBAT/3V3/GND/PGM end pins are in same order as on T_3.x - [B]With ON/OFF as the end pin[/B])

   ON/OFF - o    26 - o   o - 25     
  Program - o    24 - o   o - 27     
      GND - o    32 - o   o - 28
     3.3V - o    30 - o   o - 29
     VBAT - o    31 - o   o - 33

it is a PIN beside those pins where the Reset/DAC was on prior boards - :)
 
Cool. I'm PCB dyslexic/unpracticed when it come to flipping it over so I referenced it to the T_3 cards

Though - it seems the On/Off pin isn't supported yet?
 
I just powered up LedControl on the T_3.1 with this Amazon shipped me a board with eight of 8 Segment displays - two boards for $6.59 - uses MAX7219.

LedControl is running on T4 for the 8 digits!

ERROR >> shiftOut_msbFirst: HOWEVER - the code for this is not in the tree

extern void shiftOut_msbFirst(uint8_t dataPin, uint8_t clockPin, uint8_t value) __attribute__((noinline));

Prototype is in the header file:: ...\hardware\teensy\avr\cores\teensy4\core_pins.h

But I'm not sure where to find the T4 analog file for ? :: ...\hardware\teensy\avr\cores\teensy3\pins_teensy.c
... <since the prototype exists I just dropped the T3 source into the Sketch and the linker finds it>

Shout Out to FRANK_B - Thanks for the (Windows) Compile.cmd!

With T4 running on the Beta 1.46 I can use my prior system to build and upload through TyCommander and no second IDE confusion! - from within SubLimeText! Like putting the ECHO on the debug T_3.6 - though it would be better to move that back to the T_3.1 so I can test against the T_3.6. And I need TyCommander open anyhow for SerMon to the DEBUG Teensy.

Of course this is made REALLY easy with Tset selector to Custom build the Compile.cmd with Board choices. Just put up the new copy that shows path of output file, can be Board## folder.
 
Looks like msg #6 has several old items. Many more say "testing needed", meaning I'm pretty sure it's fixed but nobody else has confirmed.

If you have a moment, please take a look at some of these. If you're sure something is fixed, please just edit msg #6 and delete that row.

I'd like to specifically ask about the first line, "virtual function problems". Did the linker script & startup code changes in beta5 fully resolve this? If not, I need a test case. This is probably the highest priority problem to resolve, since so many Arduino libraries depend on proper C++ virtual function support.
 
Some have Post## links, I added links to things I noted for tracking - not that we want to recall bugs - but those embedded links are an index to posts of working code and usage details.

For K66 beta that was like the managed list of working things and history that may help with future issues and be very helpful as the number of thread pages grew - this is #14 in 5 days since they shipped on page #2 and tonton81 got his?

I guess my helpful 'Make Work' suggestion - would be to FLAG the DONE in RED - or Mark as 'Confirmed' - and maintain a second post on the thread where I or other Sr+ members could migrate them into a useful index for those worthy?


BTW: I have not yet rebooted my Windows machine almost 10 days - I'll do that soon and confirm the Serial Blocking problem just in case it is related to that. Pushing 1.5MB/sec from T4 in the one test does affect the system. I've had a few JAVA memory errors like the one posted prior - and had to restart the IDE a couple times - and pull the Teensy 4 USB to let the IDE recover. It keeps coming back fine so I'm letting it ride to know there is nothing fatal. Note: The USB overload slowdown is NOT new to T4 - but I usually just use TyComm that doesn't take out all of JAVA when it does go bonkers.
 
Please move the working stuff to msg #4. Or re-add it... I've already deleted many rows from #6. I'm using msg #6 as the list of stuff needing my attention, so my hope is to make that list smaller!
 
OK, thanks. I updated the dsp.zip file (ref post #204)

Paul, it looks like beta5 has the new arm_math.h, but boards.txt is still using -larm_cortexM4lf_math instead of -larm_cortexM7lfsp_math. And there were a couple more .h files needed as noted by mjs513 (post #228), and i had updated my dsp.zip. There is a README in the dsp.zip
 
Paul, there are some places with #if F_CPU== or others with F_BUS or F_PLL. Some are for timeouts, for example.
How do you want to handle them? A standardized way would be good, and would help to port all these things. Can you please post a short snippet as example - I know this needs at least a minimal api for the clocksettings, but this has to be done before release anyway - and the sooner the better - then we can use it. I could have helped with porting some things, but thought it was better to wait for a "official" way.

Or is it just F_CPU_ACTUAL ? If it's just that -OK, but a short confirmation would be good.
Edit:
Can you add nanos() to be used for timeouts, for example? Or is micros() good enough?
 
Please move the working stuff to msg #4. Or re-add it... I've already deleted many rows from #6. I'm using msg #6 as the list of stuff needing my attention, so my hope is to make that list smaller!

Agreed! better for your focus - but when admin deletes we can't recover or view - thus my suggestion. Moving to #4 is by your design. If I see it flagged with a unique Solved entry like 'msg4' I'll try to keep after that - hopefully with help it will keep 6 clear and build 4. By this thread title I assume plan is 1062/next beta as it evolves may start fresh thread.

Table format copied into post #4 for cut and paste
 
Paul, there are some places with #if F_CPU== or others with F_BUS or F_PLL. Some are for timeouts, for example.
How do you want to handle them? A standardized way would be good, and would help to port all these things. Can you please post a short snippet as example - I know this needs at least a minimal api for the clocksettings, but this has to be done before release anyway - and the sooner the better - then we can use it. I could have helped with porting some things, but thought it was better to wait for a "official" way.

Or is it just F_CPU_ACTUAL ? If it's just that -OK, but a short confirmation would be good.
Edit:
Can you add nanos() to be used for timeouts, for example? Or is micros() good enough?

A simple uint nanosToNumberOfCycles(uint nanos) or micros would perhaps very helpful and very flexibl and easy to use in most cases.

Or even more simple a global variable NS_CPU that gives the nanoseconds per cycle, and is set when changing the CPU clock. This way the division has not be done every time when it is needed.

just. some. thing. :)
 
A simple uint nanosToNumberOfCycles(uint nanos) or micros would perhaps very helpful and very flexibl and easy to use in most cases.

Handy - That would be an extension/refinement of what these did - where only F_CPU won't work as written for T4.

b) I'd delete the lines
Code:
#define clockCyclesPerMicrosecond() ( F_CPU / 1000000L )
#define clockCyclesToMicroseconds(a) ( (a) / clockCyclesPerMicrosecond() )
#define microsecondsToClockCycles(a) ( (a) * clockCyclesPerMicrosecond() )
from wiring.h ...
 
Will future/final T4's ship with same micro USB connector? Doesn't USB3 require those extra lines? USB-C?

Is there a range for the onboard supply expected power mA output?
 
Last edited:
.... places with #if F_CPU== or others with F_BUS or F_PLL. ...How do you want to handle them?

On a case-by-case basis. ;)

Many are leftovers that will be removed in the next 2 weeks. Especially in the USB are many of these. I'm going to re-write all that stuff soon, (probably) removing all those #if checks on CPU speed.

thought it was better to wait for a "official" way.

I hear what you're saying, but I'm not that good. I really haven't thought out every detail like this. My usual approach is to try to keep an open mind at first, and learn what works best as I go. Usually when I try to make rigid decisions too early, the results end up not so great.


Or is it just F_CPU_ACTUAL ? If it's just that -OK, but a short confirmation would be good.

So far, the general idea involves the cycle counter with F_CPU_ACTUAL for very short timing, and millis() / micros() for long duration.


Can you add nanos() to be used for timeouts, for example? Or is micros() good enough?

Good enough for what? I like to talk about specific usage.

I'm a little worried about adding nanos() to the public Arduino API. Well, unless Arduino does it officially for all Arduino boards. 2 concerns. This is a short name, so conflicts are more likely. Also not confident this is a good idea to give to novice users as a public API.
 
Will future/final T4's ship with same micro USB connector?

Near term plan is (currently) to stay with Micro-B. But don't take this as a promise or any sort of commitment from PJRC about future products. We could change course at any time for any reason, or even for no reason at all.

But I can tell you I'm not ever planning to make another product with the all-SMT Micro-AB connector we still use on Teensy LC & 3.2. ~7 years ago those were the most common. No longer. The newer type with the 4 tabs that fit into through-holes is so much better, far stronger and more durable. All the PCB vendors have become much better about slots. The new types is also slightly less expensive now (wasn't always the case), and our contract manufacturer reports much better yield with them, compared to the old type. I never want to design another board using the old one with only SMT tabs.

Long-term, USB-C does appear to be the one connector to rule them all. ;)
 
opps - to answer my own question/lapse :: USB 2.0 speed of 400 Mbit/s - doesn't need the extra connector … carry on.

It looks like the LedControl can update 8 digits in under 47 us with its SPI like bus bit banging.
 
Yup, unless you have a rare USB1 hub, everything with these new boards should be at 480 Mbit/sec speed.

You already measured 1.5 Mbyte/sec speed, which is over the 1.218 Mbyte/sec theoretical best speed of 12 Mbit USB when factoring in USB protocol overhead (but not the data-dependent bitstuffing overhead, which in practice makes about 1.1 Mbyte/sec the fastest possible).

When I rewrite the USB code (likely next week) my hope is to get the Serial.print() throughput into the 35-50 Mbyte/sec range. Well, at least when benchmarking with a C native program which just discards the data. How fast we'll get with the overhead of Arduino's GUI remains to be seen, but I'm going to be pretty surprised if it goes faster than 10 Mbyte/sec. Eventually I'll work more on the Arduino side, but probably not until well after the product is released.
 
Yeah - as noted a lapse on my part … was looking at ordering a powered hub to use for the test board and thinking of the USB 3 enhanced power I conflated the two - which is what made me ask about the board's power, still 500 mA total max per connector. Hopefully the $17 Amazon Basics USB 3 powered unit has good (TT?) controller - says it is good for 5 Gbps and comes with 2.5 Amp supply.

BTW - TyComm with it's non-JAVA is within some small # iterations of data writes of the T_sermon as tested assuming that PC receive is what limits that - so screen scroll and handling is the real limiter - though TyComm buffer is adjustable - it also records it in disk log file. I didn't use the IDE SerMon to compare if T_sermon gets more. I'll try to adjust TyComm buffer down to see if that changes it.

About to shutdown machine with 10 days 1.3 hours uptime … will try that Serial blocking to confirm last simple test - and on another machine. But - AFAIK that is new to the current TD beta 5where I didn't see it on #4 - unless the machine is balled up.
 
tone() tested
With beta5 I tested tone() and noTone() with various pins, frequencies, durations. checked with scope. looks good to me. i marked it as Done in post #6
 
So far, every USB3 hub I've purchased as turned out to be cheap Single-TT on the USB2 side.

USB3 hubs, data-wise, are actually 2 separate hubs in 1. You might intuitively expect a USB3 hub would translate 1.5, 12, 480 speeds up to 5000. But that's not how they work. The 5000 data is its own separate hub. There's no connection at all between the 5000 stuff and the USB2 480/12/1.5 stuff. The data is literally handled by 2 separate hubs. The cables too have 2 twisted pairs for the 5000 data, and a 3rd twisted pair for the USB2 stuff.

I've only tested about half a dozen USB3 hubs. So far all have turned out to be Single-TT on their USB2 hub. There are never any TTs on the 5000 side.
 
Sorry I have been a bit slow here, hopefully will have a PR today that has some of the HardwareSerial stuff working...

Finally got Serial1.read() to work :D So far only in the test program. I need to build some more stuff into the hardware structure for init, in particular
The Serial1 (LPUART6_RX) pin is not the default pin the system wants to use for it.

In order to use this pin, you need to set: IOMUXC_LPUART6_RX_SELECT_INPUT = 1;
Page 861 in the PDF file. Not sure how many others will need to be set as well.

But happy
 
Hardware Serial - Created a PR with current WIP - so you can try it out. At least I have Serial1 working with Loop back test.

Lots more work to go!

Kurt
 
PWMServo and Servo Libraries - WORKING

Would say you can cross these two off your list.

Tested both on a T2++, T3.2, T3.5 and the T4 all worked identically to each other using the same servo of course. I also tweaked my servo limits to make sure I got 0-180 (was getting 0-200 with default max). Heres the sketch I used for testing:
Code:
//fix for analogres: https://forum.pjrc.com/threads/54711-Teensy-4-0-First-Beta-Test?p=194334&viewfull=1#post194334

//#include <PWMServo.h>
#include <PWMServo.h> 

//PWMServo myservo;
Servo myservo;  // create servo object to control a servo 
                // twelve servo objects can be created on most boards
 
int pos = 0;    // variable to store the servo position 
 
void setup() 
{ 
  // pulse length for 0 degrees in microseconds, 544uS default
  // pulse length for 180 degrees in microseconds, 2400uS default
  //25 for 2.0++ 9 for T3.x/T4
  myservo.attach(9, 544, 2000);  // attaches the servo on pin 9 to the servo object 
  myservo.write(0);
  Serial.printf("Angle Read %d\r\n", myservo.read());
  delay(5000);

} 
 
void loop() 
{ 
  for(pos = 0; pos <= 180; pos += 1) // goes from 0 degrees to 180 degrees 
  {                                  // in steps of 1 degree 
    myservo.write(pos);              // tell servo to go to position in variable 'pos' 
    delay(15);                       // waits 15ms for the servo to reach the position 
  } 

  Serial.printf("Angle Read %d\r\n", myservo.read());

  delay(1000);
  
  for(pos = 180; pos>=0; pos-=1)     // goes from 180 degrees to 0 degrees 
  {                                
    myservo.write(pos);              // tell servo to go to position in variable 'pos' 
    delay(15);                       // waits 15ms for the servo to reach the position 
  } 

  delay(1000);

}
 
Last edited:
ADAFRUIT BME280 LIBRARY - WORKING

Just retested the BME280 Library and it is working fine now (fix for C++ constructors and I2C work). Can now come off the list. Sample output below:
Code:
Temperature = 24.89 *C
Pressure = 1010.96 hPa
Approx. Altitude = 19.11 m
Humidity = 40.24 %

Temperature = 24.88 *C
Pressure = 1010.93 hPa
Approx. Altitude = 19.35 m
Humidity = 40.42 %
 
Hardware Serial testing -
Loop back test:
Code:
#define SERIALX Serial2
void setup() {
  while ( !Serial && millis() < 4000 ) ;

  pinMode(13, OUTPUT);
  pinMode(2, OUTPUT);
/*
  pinMode(3, OUTPUT);
  pinMode(4, OUTPUT);
  pinMode(5, OUTPUT);
  digitalWrite(2, LOW);
  digitalWrite(3, LOW);
  digitalWrite(4, LOW);
  digitalWrite(5, LOW);
*/
  for (uint8_t i = 0; i < 5; i++) {
    digitalWrite(13, HIGH);
    delay(250);
    digitalWrite(13, LOW);
    delay(250);
  }
  digitalWrite(2, HIGH);
  SERIALX.begin(115200);
  digitalWrite(2, LOW);
}

uint16_t loop_counter = 0;
void loop() {
  delay(500);
  digitalWrite(2, HIGH);
//  Serial1.setRX(0); // debug right now prints stuff
  SERIALX.print("Loop ");
  SERIALX.println(++loop_counter, DEC);
  //delay(100);
  if (SERIALX.available()) {
    digitalWrite(13, HIGH);
    while (SERIALX.available()) {
      int ch = SERIALX.read();
      Serial.write(ch);
    }
    digitalWrite(13, LOW);
  }
  digitalWrite(2, LOW);
}
The loop back testing is working for: Serial1, 3, 4, 5
Not working on Serial2 - (Pins 6, 7) Investigating... Also will try to get in read in more using fifo...

Update: Serial2 fixed and updated on GitHub
 
Status
Not open for further replies.
Back
Top