Teensy 4.0 First Beta Test

Status
Not open for further replies.
I've ported the TimerOne library, and added the cache functions.

Merged Frank's shift functions and Kurt's work on hardware serial.

Going to do a little testing, then package up installers for 1.46-beta6.
 
Ok, I've uploaded 1.46-beta2 to msg #2.

It has Kurt's work-in-progress on hardware serial, Frank's shift functions, a bug fix to the undocumented patchcord disconnect() function in the audio library (affecting Teensy 3.x boards - fix from El Supremo), libraries Servo, OneWire, Encoder, CapacitiveSensor, TimerOne, analogReadResolution (and PWMServo working), PWM fixed on pin 9 (Manitou), Adafruit_NeoPixel (maybe working?), delayNanoseconds (from Frank), and cache functions.
 
Sounds great:

Another generic question maybe already answered?

I would like to finish putting in the RS485 support into HardwareSerial. So the question is how to do the digitalWrite HIGH and LOW...

Obviously I could simply use digitalWrite...

But wondering if I should instead somehow map the pin number to the PINs PORTSET and PORTCLEAR registers as well as the MASK?

Wondering how best to do the mappings?
Probably can use the digitalPintoBitMask for the mask
For the Set and Clear could probably get the port register and offset to the appropriate one?

Should we do this? Should there be new macros for this?

Kurt
 
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

DSP updates didn't make it into beta6 ??
dsp.zip
 
SHARP 10-80 cm Test
Did a quick and dirty test of a sharp ir distance sensor that uses analog read. Used analogread(14)*(3.3/1023) to get voltage and measured a few points against the sensor calibration curve in the spec sheet. Pretty much follows the curve but a little bit lower than the published curve - not unexpected. Typically do my own for these sensors anyway.
 
Last edited:
Something Odd? Forgot to shutdown as planned - so installed TD1.46b6. Teensy_ports won't see/show my T4 - though IDE Serial does? It does program on button and AUTO, but after startup the last SerialBlocksTest starts up with LED HIGH and then nothing to IDE SerMon. Developing as I reboot ...

I see that USB Ping is gone from Verbose log! Here is what I have :: View attachment 146b6_LOST_log.txt

After 6 td 1.46 Beta installs and a few uploads and IDE restarts :: There are NO Orphaned Teensy_ports or other when IDE was closed to install Beta 6!

I see this got added ::
T:\arduino-1.8.8T4_146\hardware\teensy\avr\cores\teensy4/digital.c:142: multiple definition of `shiftOut_msbFirst'
 
That is showing a FIX by Paul! >> "I see this got added ::"

I don't see this multiple definition.

There was in my sketch because per prior post because I copied it in as it was missing from T4 tree - I copied that to show that teensy4\digital.c is the place where it was :: teensy3\pins_teensy.c

That was so I wouldn't forget it - but I have a BIGGER ISSUE ...
 
Something Odd? Forgot to shutdown as planned - so installed TD1.46b6. Teensy_ports won't see/show my T4 - though IDE Serial does? It does program on button and AUTO, but after startup the last SerialBlocksTest starts up with LED HIGH and then nothing to IDE SerMon. Developing as I reboot ...
...

Okay did a full WINDOWS shutdown and then repowered.
Here is the TD Verbose :: View attachment 146b6_Stalled2_log.txt
Updated to longer version with added uploads

T4 is now back as COM20 on the Teensy_ports. But so far I am not getting into loop()?

wondering … Do I have a conflict with Serial4 usage and new hardwareSerial code?

Overnight I ran the "LCDemo7Segment.ino" - no problem! Rebuilt and uploaded … Now my T4/code seems to DIE after BEFORE Setup()? In setup I did a 10,000 write loop to the calc/display for timing of 8 digit writes. The TEST runs. That is never displayed and setup does not exit - there is no "Serial" output in this sketch - it is using Serial4:
***********IMXRT Startup**********
test 1 -1234567 3 // ...
analogInit
before C++ constructors
after C++ constructors
before setup
usb_cdc_line_coding, baud=0

Switching to "BlinkMin.ino" it leaves setup but only USB output is from setup:
371
571
571
574
574
574
578
581

T:\tCode\T4\BlinkMin\BlinkMin.ino Jan 3 2019 11:49:05
Serial First millis=584
while Count ii=336537

But Debug Serial4 oddly ends repeatedly with a missing "a":: "fter setup"
Code:
***********IMXRT Startup**********
test 1 -1234567 3
CCM_ANALOG_PLL_USB1=80003000
  enable USB clocks
CCM_ANALOG_PLL_USB1=80003040
Increasing voltage to 1250 mV
need to switch to alternate clock during reconfigure of ARM PLL
USB PLL is running, so we can use 120 MHz
Freq: 12 MHz * 100 / 2 / 1
ARM PLL=80002042
ARM PLL needs reconfigure
ARM PLL=80002064
New Frequency: ARM=600000000, IPG=150000000
ARM PLL = 1200 MHz
ARM divisor = 2
AHB divisor = 1
IPG divisor = 4
USB reset took 5 loops
analogInit
before C++ constructors
after C++ constructors
before setup
status = 00020080
status = 0002008usb_cdc_line_coding, baud=0
0
status = 00020080
status = 00020080
status = 00020080
status = 00020080
status = 00020080
status = 00020080
status = 00020080
status = 00020080
status = 00020080
status = 00020080
status = 00020080
status = 00020080
status = 00020080
status = 00020080
status = 00020080
status = 00020080
status = 00020080
status = 00020080
status = 00020080
status = 00020080
status = 00020080
status = 00020080
status = 00020080
status = 00020080
status = 00020080
status = 00020080
status = 00020080
status = 00020080
status = 00020080
status = 00020080
status = 00020080
status = 00020080
status = 00020080
status = 00020080
status= 020080
status = 20080
status = 00000
status = 000200
status = 0002008status = 0002000
tatus = 000200
satus = 000200
status = 00020080
status = 00020080
status = 00080
status = 00080
status = 00080
status = 0002000
tatus = 000200
satus = 000200
status = 0002008status = 00020080
status = 00020
status = 000080
status = 00020080
status = 00020
status = 00000
status = 000080
status = 0002008status = 0002000
tatus = 000200
satus = 000200
status = 00020080
status = 0002000
status = 00008
status = 00080
status = 000280
status = 0002000
tatus = 000200
satus = 000200
status = 00020080
status = 00020080
status = 00080
status = 00080
status = 00080
status = 0002000
tatus = 000200
satus = 000200
status = 0002008status = 00020080
status = 00020
status = 000080
status = 00020080
status = 00020
status = 00000
status = 000080
status = 0002008status = 0002000
tatus = 000200
satus = 000200
status = 00020080
status = 00020080
status = 00080
status = 00080
status = 00080
status = 0002000
tatus = 000200
satus = 000200
status = 000200status = 00020080
status = 00020
status = 000208
status = 00020080
status = 00020
status = 00000
status = 000080
status = 0002008status = 0002000
tatus = 000200
satus = 000200
status = 00020080
status = 00020080
status = 00080
status = 00080
status = 00080
status = 0002000
tatus = 000200
satus = 000000
status = 0002008status = 00000000
status = 000200
status = 00000
status = 00020080
status = 00000
status = 00000
status = 000000
status = 0002008status = 0000000
fter setup
 
Indeed there is a conflict with :: #define HW_SERIAL Serial4 // pin 17 debug Tx only

I made a version :: BlinkMinNOser4.ino that uses :: #define HW_SERIAL Serial

All prior debug output now goes to Serial and my code is working.

Do I need to do a proper : Serial4.begin( 115200 ); now?

<UPDATE>
Indeed with :: void setup() { Serial4.begin( 115200 );

The LedControl is now working but 'after setup is still clipped?

before C++ constructors
after C++ constructors
before setup
usb_cdc_line_coding, baud=0
elapsed micros=460850
count=10000
er setup
 
Maybe it is interacting with my changes to HardwareSerial.

Also there is/was problem with the SerialX.flush() function, as I was not properly looking at TC status flag.

Fixed in my current branch I just pushed up, which also has support the the Transmitter Enable.

Question is, should I issue PR yet or continue to fill out and fix issues in hardware serial, before doing another PR?

Changes in branch: https://github.com/KurtE/cores/tree/t4-HardwareSerial-Transmitter_enable
 
Looks like something's going wrong with the USB. The documentation for "status = 00020080" it in Table 41-63 on pages 2313-2314 of the RT1050 ref manual rev 2 (11/2018). The top part "0002" means 2 bytes remain in a buffer on the Teensy side, not yet sent to your PC. The "80" in the LSB means the transfer is still active, not halted, no errors. But obviously your PC isn't trying.

Without the ability to put the protocol analyzer between that Teensy and your PC, there's not much more I can do to guess. No idea what changed or how you can recover. Sorry, just don't have the ability to see.

I am going to rewrite the USB serial code next week. What we have now is merely a quick kludge to get *something* running so we could start testing.
 
I put a giant list of libraries and core library APIs on msg #4. Anyone who wants to keep a list of what's working, please edit.

My main goal is crossing stuff off the list on msg #6. Many of the issues are probably fixed, but needing testing or confirmation. If you see anything on msg #6 that you're confident is now working, please just delete it.

Early on, a variety of problems with digitalRead where reported, around msg #128 time frame. A bug was fixed some time ago where the pin couldn't be read back while the pin was configured for output mode. I'd like to ask anyone who had those digitalRead issues to please check with beta6. If all digitalRead problems are fixed, I want to get it off msg #6. If there still is any bug with digitalRead, please tell me what you're seeing so I can work on it tomorrow morning.
 
Just confirmed this now works :: digitalWrite( LED_BUILTIN, !digitalRead( LED_BUILTIN ) );
> also tested with Fast() versions - removed from #6

Looks like something's going wrong with the USB. The documentation for "status = 00020080" it in Table 41-63 on pages 2313-2314 of the RT1050 ref manual rev 2 (11/2018). The top part "0002" means 2 bytes remain in a buffer on the Teensy side, not yet sent to your PC. The "80" in the LSB means the transfer is still active, not halted, no errors. But obviously your PC isn't trying.

Without the ability to put the protocol analyzer between that Teensy and your PC, there's not much more I can do to guess. No idea what changed or how you can recover. Sorry, just don't have the ability to see.

I am going to rewrite the USB serial code next week. What we have now is merely a quick kludge to get *something* running so we could start testing.


Paul - likely not an issue - just a test for problems during startup with early Serial.print(). That Status Spew is during this code showing "while Count ii=336537" being a rather large number!::
Code:
void setup() {
   //...
  while ( !Serial ) {
    Serial.println( millis() );
    ii++;
  }
   //...
[B]  Serial.print( "   while Count ii=" );[/B]
  Serial.println( ii );
 
Last edited:
Paul ( others test? ) :: After machine reboot and seeing other sketches working with Serial4.begin on my Windows machine USB Serial.print() still BLOCKS T4 while T_sermon is closed::

...
Below is a sketch. Upload to T4. When SerMon presents Serial it will begin and print. Watch the prints and see the LED blink on output - watch the digit after the @ symbol - it is a counter.

Close SerMon - LED will stop blinking - confirm watching a couple of seconds … no blink [ ON WINDOWS ]

Open SerMon - blinking resumes and the SerMon output picks up where it was when SerMon disconnected.

PROBLEM: T4 blocks sketch execution when Serial.print is used and SerMon goes away. Similar issues when the setup() { while ( !Serial ); is commented out

Code:
void setup() {
  pinMode(LED_BUILTIN, OUTPUT);
  while ( !Serial );
}
int ii = 0;
bool flip = true;
void loop() {
  if ( !(millis() % 1000) ) {
    Serial.print( "123456 @" );
    ii++;
    Serial.println( ii );
    digitalWrite( LED_BUILTIN, flip );
    flip = !flip;
    delay( 5 );
  }
}
 
If someone wants to know how to switch the IMXRT off completely, mail me.. tested, works... but I don't write that here, because if you have no long delay before that, there is currently no way to switch it on again, as it will immediately switch off when it runs the program with the command ... :) so..it's risky. have not tried if the 13-seconds reset works in this case..

edit: ok, 13 seconds reset still works, so i think it's the bootloader-chip which stays alive and monitors the button.

edit: and this confirms the 13-seconds reset works, too :)



 
Last edited:
ANALOGREAD

Played around a lot with analog read on A0 when doing the ir distance sensor and had no problems. Just as a sanity check I applied 3.3v to pins a0-a5 but read pins a0-6.
Results:
a0-a5: 1023 read consistently
a6: 1016 typ with floating

So with no voltage applied a6 still reads pretty close to high - are the analog pins default to high? On the T3.2 the same analog pins read less that 300 counts with nothing attached.
 
Any idea how FASTRUN can be tested.. or what it should do? Can we run code from flash? hehe..do we need a SLOWRUN?
 
ili9341_t3 : does it make sense to port it, since we have no fifo? or just use the original from adafruit (with our additional functions added (for Pauls fonts) and higher spi-speed etc)
 
ili9341_t3 : does it make sense to port it, since we have no fifo? or just use the original from adafruit (with our additional functions added (for Pauls fonts) and higher spi-speed etc)

T4 LPSPI does have FIFO -- or are you referring to another FIFO, i'm not familiar with all the ILI9341_T3 optimizations.
 
Status
Not open for further replies.
Back
Top