Teensy 4.0 First Beta Test

Status
Not open for further replies.
@WMXZ, yes, I have your code here :) I see some lines for SPDIF - is that already working, too?

Raspi-adapter: I'll just drop RX for the first revision.
 
@WMXZ, yes, I have your code here :) I see some lines for SPDIF - is that already working, too?
Did not try SPDIF (have no SPDIF device), It was only a test to see if I can get SAI2 working. SPDIF clock is one of the inputs. In the end, I found the error and did not need it.
(At the moment I'm stuck (better screwed up) with USDHC)
 
The 40 pin header is identical on all versions of the P that use iti; what is new on the Pi3 B+ is the power header to connect the POE (Power over Ethernet) HAT.

I think the first models had a 26 pin header. And that's good, because we don't have enough regular pins..
 
Did a quick scan after prior - the descriptors and the code are spread different from the 'in progress' core code ... global search on T3 tree shows undef as well - there are lots of crossed/built_on dependencies - that message isn't real specific - I'm not sure where I'd begin.

Only look I ever on descriptors was somebody wanted to change USB types during runtime startup and I found a place for that he got working ...

It could be flag passing negating something in one place that is needed?
Found why I'm getting the error. All the #includes for the USB devices like the joystick are commented out in WPogram.h. When I uncomment them they lead me to all the #if 0's that are in the core. Just thought I would let you know.
 
Found why I'm getting the error. All the #includes for the USB devices like the joystick are commented out in WPogram.h. When I uncomment them they lead me to all the #if 0's that are in the core. Just thought I would let you know.

Good discovery - '//#include "usb_joystick.h"' is pretty subtle in a key [ default (?) ] file for inclusions and won't leave traces :)
 
Mike - Teensy View is a Teensy PCB sized and pinned 128x32 OLED from SparkFun - pretty cool - never found need to make one permanent - but I got two :)

Kurt - Any alternatives it can offer is good - pretty sure the 1062 is on order and pending delivery in some quantity. I went looking I thought it was second SPI that went missing - even 7.5 would be better than nothing or most alternative busses for most uses.

Actually can probably run faster. I am playing around with some of the dividers for FlexIO..
The base clock going in runs at 480mhz, default dividers 2 and 8 so base flexio is default to 30mhz. So now tried 3 and 1 so 160mhz and it looks like min SPI divider of 4 here is could get 40mhz...

But the signals don't look clean! Still experimenting. Oops The ground wire to the LA came off. Looks cleaner now.


Here is showing at 20mhz...
screenshot.jpg

Still has large gap between outputs, will work on that soon.
 
Actually can probably run faster.
...

Your prior comment suggested you hadn't gotten to tweaking yet, assumed you'd get there :) Given CAN FD is likely taking 2nd SPI w/1062 it is very good the FlexIO can function - and the 1062 adds more of those it seems.
 
Your prior comment suggested you hadn't gotten to tweaking yet, assumed you'd get there :) Given CAN FD is likely taking 2nd SPI w/1062 it is very good the FlexIO can function - and the 1062 adds more of those it seems.

Depends where Paul decides to put them. Right now you have CAN1 and CAN2. You could always substitute CANFD for CAN1. Then put CAN1 back on future T4.x's

Tim - gave up a usb - started reading the USB chapter and gave me a giant headache. Not sure how Paul sorted that out. Well, maybe not gave up but...
 
Depends where Paul decides to put them. Right now you have CAN1 and CAN2. You could always substitute CANFD for CAN1. Then put CAN1 back on future T4.x's

Tim - gave up a usb - started reading the USB chapter and gave me a giant headache. Not sure how Paul sorted that out. Well, maybe not gave up but...

Swapping CAN1 for CANFD would be a seemingly safe and good exchange - I didn't follow enough to see that. If that preserved other native SPI ... and added 500 KB RAM and the third group of FlexIO the T4 would be much improved for the having 1062

Putting USB aside facing that seems reasonable given the ground may shift when the more complete USB gets dropped in - and even if you found all the parts there may be unfixed pieces until then.
 
Giving up CAN1 would be tough - not because of CAN1, but due to the other stuff shared on its pins.

Pins 11 & 13 are shared with SPI, so those are untouchable.

Pins 22 & 23 are more likely candidates. But 23 is shared with I2S1 MCLK.

On my list of stuff to investigate is whether MCLK can be shared between two different I2S ports. If so, that might open up the possibility to reassign pin 23.

But we also need analog input on pin 23. Another subtle feature of the assignments we currently have for pins 14-23 is all 10 can be accessed by either ADC. Most of the alternates mux to only 1 of the ADCs. Not a critical feature, but having the ability for all the main analog inputs to use either physical ADC inside the chip does give some really interesting possibilities for the future....
 
I think the first models had a 26 pin header. And that's good, because we don't have enough regular pins..

Ok, I think I have to make two board variants : T4 and T35/T36. Found no good way to combine the different pinouts. The T4 variant will not have pin 32, 36,37 and 38 - just not enough pins on T4.. I can only hope it works with some "hats".
I'll make T4 first - because I want to try some of these Rasperry SPI Displays, and perhaps Audio with T4. Layout is done, if I upload it tomorrow the boards are done Tuesday, and then it takes two weeks to ship.. :)
 
Giving up CAN1 would be tough - not because of CAN1, but due to the other stuff shared on its pins.

Pins 11 & 13 are shared with SPI, so those are untouchable.

Pins 22 & 23 are more likely candidates. But 23 is shared with I2S1 MCLK.

On my list of stuff to investigate is whether MCLK can be shared between two different I2S ports. If so, that might open up the possibility to reassign pin 23.

But we also need analog input on pin 23. Another subtle feature of the assignments we currently have for pins 14-23 is all 10 can be accessed by either ADC. Most of the alternates mux to only 1 of the ADCs. Not a critical feature, but having the ability for all the main analog inputs to use either physical ADC inside the chip does give some really interesting possibilities for the future....

Wow. Tradeoffs not easy. Almost want to say to wait for CANFD but that is one of the features of the M7 that most others don't have with extra hardware.
 
Which hardware uses CANFD? Never worked with CAN. It's used in cars - are there more uses? Seems interesting..

Edit: The obvious solution is to add 2-3 rows of pins..
But a T4 with more PINs would of course compete with the Teensy 3.5 and 3.6. Not good for business.
 
Last edited:
Which hardware uses CANFD? Never worked with CAN. It's used in cars - are there more uses? Seems interesting..

Edit: The obvious solution is to add 2-3 rows of pins..
But a T4 with more PINs would of course compete with the Teensy 3.5 and 3.6. Not good for business.

Besides for auto's it is used in UAV's, robotics, etc. Right now UAVCAN uses CAN but UAVCAN2 is going to support CAN and CANFD. Also used in UAVAEROSPACE applications. tonton81 can give you more details on capabilities between both. I actually got UAVCAN implemented on Teensy 3.x, https://forum.pjrc.com/threads/53394-UAVcan-for-Teensy-3-x-Proof-of-Concept?highlight=uavcan.
 
Suppose that is why I had not seen CAN1 as an exchange for CANFD - nice joke Mike :)

2-4 more pins would be handy - might even open up room for better SD card mounting - :)
 
Suppose that is why I had not seen CAN1 as an exchange for CANFD - nice joke Mike :)

2-4 more pins would be handy - might even open up room for better SD card mounting - :)

Really wasn't meant as a joke - feel a little embarrassed. Didn't think the ramifications through. Real good explanation by Paul, and understanding grows daily :)
 
Mike - it is good to say wrong stuff now and then - I've found it brings out some of Paul's best explanations :)

Frank - the rPi adapter seems cool - will be interested to see it develop - especially if it is worth sharing.

I think I figured out some of the INO<>CPP<>C confusion with printf, printf_debug, Serial and Serial# that made the Fault handler seem so odd - on T3 the printf_debug was off and it is #defined I finally noticed over normal 'printf' and having it on needed attention so getting the debug_tt ported/upgraded seems like the next thing.

Also I closed the IDE for some time and Teensy_ports/Win10 or whatever the issue was ( since T4 was not showing right in IDE -Tools/Port list ) seems better. Just unplugged the hub with all three on and T4 came up running unlike before where T4 had to come first. Though the one T_3.1 is not showing in T_ports IDE list now ... I'm hoping it is safe to expect that to clear up when the more complete USB stack on T4 is ready as there seems to be some odd contention.
 
2-4 more pins would be handy - might even open up room for better SD card mounting - :)
If I got the orientation right, the actual layout has still room for improvements. actual location id too far in the middle to allow direct soldering of a uSD card (the decoupling capacitors are interfering). The (uSD) pin spacing (1.1 mm) on the other hand is not compatible with any header (I soldered a 1 mm header by twisting outside header pins). Unfortunately Paul has overseen my earlier question (https://forum.pjrc.com/threads/54711-Teensy-4-0-First-Beta-Test?p=195131&viewfull=1#post195131) on intended uSD connection.
 
Not sure if anyone looked into the debug_t3 stuff - the goal was to not SPEW but keep a trace log when desired { code call for a given 'index 0-9' recorded line number and a passed uint32_t and name of last func() that called } , then if there was trouble the trace would show logged info. Would allow Assert to stop - and I added a HaltIf() - but I just made the Assert not fatal allowing a return to runnign code - so that is what the HaltIf did - and the logic was same as Assert - so it is redundant.

The _t3 code only got as far as hardcoded to Serial - needs a rewrite to make that to allow user specifying the Stream* - for now I just hardcoded Serial1 since Serial is write only and it works for output and user prompted from there with a Teensy Echo'ing the chars to/from a second SerMon.

Are there working T4 commands for :: _reboot_Teensyduino_ and _restart_Teensyduino_ ? I had those in the prompt area to allow that for when offers a better way than Button or replugging operation.

I was thinking I was keeping it SMALL and fast to not interfere with problem at hand - only kept 10 item recording list. I think it is cool - works as I used it - but I think the TODO list is longer than the feature list and I just added a couple TODO items.

It shows things like where in the end this led to the assert: float x = log (0);
___ ASSERT FAILED ___ FILE >> T:\tCode\libraries\debug_tt\examples\Asserts\Asserts.ino
___ in function >> setup() at LINE# >> 37
Expression >> isfinite( x )

>>>> ABORT >>>> ASSERT FAILED
>>>> debug_fault >>>> debug_fault >>>> TYPE:ASSERT
Debug Info:
3 => 470 0x1D6 [L#33_C#2 _<< last func::setup
7 => 469603 0x72A63 [L#30_C#1
___ ASSERT FAILED ___ 'y' to continue ...
'd' to call Debug_Dump()
'b' Teensy Bootloader
'r' Restart Teensy
'z' Zero Debug logs

Where this made the entry #: 3 => at 470 millis() as Call#2 with :: deb_tt( 3, millis() );
And Call#1 in this short example was from line #30 :: deb_tt( 7, micros() );

And the recorded uint32_t for micros&millis is shown in DEC and HEX

The 'd' option should still work as well like under T3 - including after a fault - you can put a func() in user code to call to spew data or run code of your choice.

And I made NULL #defines for the 'code' so everything could be disabled with a #define - to allow test runs with or without it with the instrumentation in place.
 
SerialFlash: Works

Code:
Raw SerialFlash Hardware Test
SPI MISO: 12 MOSI: 11, SCK: 13

Read Chip Identification:
  JEDEC ID:     EF 40 18
  Part Nummber: W25Q128FV
  Memory Size:  16777216 bytes
  Block Size:   65536 bytes

Reading Chip...

Writing 32 signatures

Double Checking All Signatures:
  all 8192 signatures read ok

Checking Signature Pairs
  all 4095 signature pairs read ok

Checking Read-While-Write (Program Suspend)
  write 256 bytes at 512
  write time was 390 microseconds.
  read-while-writing: 00 00 00 00 15 F5 95 4B 
  test passed, good read while writing

Checking Read-While-Erase (Erase Suspend)
  erase time was 276770 microseconds.
  erase correctly erased 65536 bytes
  read-while-erasing: 00 00 00 00 15 F5 95 4B 
  test passed, good read while erasing

All Tests Passed  :-)

Test data was written to your chip.  You must run
EraseEverything before using this chip for files.

----------------------------------------------------

SPI MISO: 12 MOSI: 11, SCK: 13
Flash Memory has 16777216 bytes.
Erasing ALL Flash Memory:
  estimated wait: 40 seconds.
  Yes, full chip erase is SLOW!
............................................................
..
Erase completed
  actual wait: 62 seconds.
 
@luni,
do you want to test this (?): https://github.com/PaulStoffregen/cores/pull/347
- no loop
- check registers only if channel is in use
together with the other changes, it'll be as fast as 3.6 - don't know exactly because I have so many other changes in my installation..

Here the results for 200kHz interrupt frequency


Generated load for T3.6 @180MHz, empty ISR
1 Timer 3%
4 Timers 12%

Generated load for T4.0 empty ISR (PR347)
1 Timer 11.8 % (was 18% with old version)
4 Timers 72%

How did you test? Maybe I do something wrong? Here my test code:
Code:
#include "arduino.h"

IntervalTimer t1, t2, t3, t4;

void test() // dummyfunction
{
  //digitalWriteFast(0, !digitalReadFast(0));
}

void test2() // dummyfunction
{
  //digitalWriteFast(0, !digitalReadFast(0));
}


void test3() // dummyfunction
{
 //digitalWriteFast(0, !digitalReadFast(0));
}

void test4() // dummyfunction
{
  //digitalWriteFast(0, !digitalReadFast(0));
}

volatile int dummy;
  constexpr unsigned loops = 100000;

void setup()
{
  while (!Serial)
    ;

  // required for T3.6
  ARM_DEMCR |= ARM_DEMCR_TRCENA;
  ARM_DWT_CTRL |= ARM_DWT_CTRL_CYCCNTENA;


  // Measure cycles required for loop without any interrupts
  noInterrupts();
  uint32_t start = ARM_DWT_CYCCNT;
  for (unsigned i = 0; i < loops; i++)
  {
    dummy++;
  }
  uint32_t end = ARM_DWT_CYCCNT;
  float base = end - start;

  // activate interrupts and IntervalTimer
  interrupts();
  t1.begin(test, 5 );
  // t2.begin(test2, 5);
  // t3.begin(test3, 5);
  // t4.begin(test4, 5);

  start = ARM_DWT_CYCCNT;
  for (unsigned i = 0; i < loops; i++)
  {
    dummy++;
  }
  end = ARM_DWT_CYCCNT;

  float load = base / (end - start);
  Serial.printf("Load: %.3f\n", 100.0 * (1 - load));
}


int tt1=0, tt2=0;

void loop()
{  
}
 
Well, at least faster :)

I check again.

Edit: Load:6.827 with the old test-program. (Optimize "fastest"). Have you switched the clock to IPG?

- Wasn't ~6 load of T 3.6? I remember it was about 6.. now, the new ~3 will be hard without IPG overclock..
I don't have more Ideas..

Did you try to measure the _absolute_ time ?
 
Last edited:
Status
Not open for further replies.
Back
Top