Teensy 4.0 First Beta Test

Status
Not open for further replies.
I've uploaded 1.46-beta5. Links are on msg #2. I also left the 1.46-beta4 links in places, since put this one together in a hurry. Hopefully it works ok. Rolls up the many small edits to files, and attachInterrupt, (hopefully) improved C++ constructors, tone, EventResponder, MillisTimer and yield().

I need to step away for several hours. Will be back later this afternoon.
 
@manitou -
Guess I can't sleep - too much goes on when I wake up :)

Thanks for the files. By the way I tried running the CMSIS Neural Network library but it needed two additional files:
Code:
arm_const_structs.h
arm_common_tables.h
I just copied these from the main cmsis GitHub page but not sure it they are correct for your version.

OK, thanks. I updated the dsp.zip file (ref post #204)
 
C compilation issue

In a previous post I show a sketch that sets the Audio PLL

It has the following lines
Code:
#define CCM_ANALOG_PLL_AUDIO_NUM_MASK ((uint32_t)((1<30)-1))
#define CCM_ANALOG_PLL_AUDIO_DENOM_MASK ((uint32_t)((1<30)-1))
needs to be replaced by
Code:
#define CCM_ANALOG_PLL_AUDIO_NUM_MASK (((1<29)-1))
#define CCM_ANALOG_PLL_AUDIO_DENOM_MASK (((1<29)-1))
otherwise the fractional PLL does not work as expected
 
Thanks Paul, Hopefully for next beta I will have more serial support ready. Have some stuff in place to start doing reads, but looks like I need to get better understanding of the FIFO stuff and initializing it, which is not a bad thing to do anyway. Looks like the FIFO register actually has the sizes of the TX and RX fifos for each one. I probably need to set the watermark register values. Also not clear if the ISR should use the STAT values to control RX/TX or the FIFO register... So have some experimenting to do.

Looks like the test run shows a vtable being created and init as the dump shows non zero values, so looks promising.
 
Upgraded to 1.46-beta5.

Using GPS PPS on pin 12 with attachInterrupt(), I measured crystal drift for 24mhz crystal (-3.2 ppm) and 32khz crystal (-4.7 ppm) using free running GPT timer in gpsgpt.ino. I'm not sure what the crystal specs are ...

Even with beta5 (on 32-bit linux with 1.8.8), I still have to push program button after upload to get the IDE serial monitor to come to life ??
 
PWMServo Library

Tested the sweep example with the scope on pins 0, 1, 2, and 3.
  1. On pins 0 and 1 the signal starts low goes when the sweep starts and the pulse widens from right to left as the sweep angle increases and then decreases as the angle decrease.
  2. On pins 2 and 3 this is reversed. The signal starts high goes low as the pulse starts and as the sweep angle increases the pulse width increases from right to left and decrease left to right as the angel decreases
  3. With sketch not running pins 0,1 are low while 2,3 are high.
  4. The frequency is 50khz with a period of 20ms

Is this the way it should be?

EDIT: Just repeated the sweep test on a T3.5 and looks 1 and 3 match.
 
Last edited:
coremarkish plot
T4 beta (1050)
Changed CPU speed in startup.c (set_arm_clock()) for coremark compiled Fastest (-03).
Code:
MHz   Iterations/sec power (ma)
 24      96.78        36.2
120     485.2         49.9
288    1165           62.4
396    1602           67.6
600    2427.4         94.1
About 4 iterations/MHz.
coremark4b.png
Unsurprisingly, similar to EVKB tests
corebar.png

EDIT: 8/14/19 production T4 (1062) CoreMark power & temperature -O3
Code:
MHz   Iterations/sec power(ma) temp ℃
 24     123.4         35.4      36.67
120     494.6         53.7      40.35
180     742.1         54.9      41.58
288    1188.3         68.1      44.04
396    1632.9         77.4      45.26
528    2177.4         85.7      47.11
600    2474.4        105.5      50.79

coremarkp4.png
If you run at 528 MHz or lower, the CPU runs at a slightly lower voltage (1.15V instead of 1.25V), which really reduces the power consumption. At 24 MHz or lower the voltage is 0.95V (see hardware/teensy/avr/cores/teensy4/clockspeed.c). MCU temperature measured with tempmonGetTemp().

See NXP's 1060 power consumption
 
Last edited:
Crystal Drift

Using @manitou gptgps.ino sketch to measure crystal drift I got somewhat different results:

Code:
Clock         manitou         mjs513
24mhz         -3.2            -16.3
32khz         -4.7             28.7
 
Installed TD 1.45b5 and 2 prior sketches working without change! I see setup entry millis jumped to 300+ and Serial online about 100 ms later too. I killed that annoying usb "status =" debug spew.

Paul - Koromix sent me a version of TyCommander that recognizes Teensy 4.0 - can now issue reboot and bootloader commands. I've sent him verbose feedback for his review - not hit UPLOAD yet.
>> Is there any unique twist to bootloader uploading versus Teensy 3.x's? Or is same exchange fully maintained through the bootloader chip?

Since I had IntervalTimer to trigger WFI I set it to 2 us trigger and am seeing 498095 _isr calls/sec to inc a volatile global. Cut down the 21M loop/sec to 9.5 million.

With IntTimer_isr running I started a print of a string of the alphabet each loop() - 63 letters with a newline, cycles A-Z ... except first 'Z' string is a \t so you can see it fly by.
That drops the loop count to a mere 25K - which means 1,580,800 Bytes/sec out to SerMon? TyComm and T_sermon about the same - maybe a few more from T_sermon - but seems pegged on Windows.
It times the 1 second interval with a elapsedMillis, toggles the LED and puts the micros to debug.print - it trigger +/- 10 us with clock resolution

So the Serial Throughput is good - and not affected by the interval timer.

It did lead to this JAVA HEAP Memory issue though:View attachment JavaHeapSpace.txt

manitou - did you have the same Button needed upload with the sketch I linked? Or the one here? What OS? If so that is unique - maybe Paul can see something in a Loader Verbose log?
 
I'd like to add delayNansoseconds(uint32_t).
https://github.com/PaulStoffregen/cores/pull/307/commits/acc3eeb91b9a0d106e0508f559f279114e4b6b53

It is useful for short wait-times. Could be used for PulseIn etc.
No very exact, but at least it is useful for delays of about half a microsecond or less, which is not that easy now.

That looks nice Frank. The T_LC doesn't have a cycleCounter - but other T_3.x's do - would be nice to have that on at setup() for supported units??
 
coremarkish plot
Changed CPU speed in startup.c (set_arm_clock()) for coremark compiled Fastest (-03).
Code:
MHz   Iterations/sec power (ma)
 24      96.78        36.2
120     485.2         49.9
288    1165           62.4
396    1602           67.6
600    2427.4         94.1
About 4 iterations/MHz.
Unsurprisingly, similar to EVKB tests

Yeah - but I want BARE METAL !!!! … oh wait … it's the same ? … but Arduino is for kids.
 
@FrankB
Do you mean 50Hz? 50Hz is perfect for servos
Yes I did, as you pointed out. Wanted to attach a servo to the board but all my servos are 5v and not sure what the signal is - don't want to short the T4.

I'd like to add delayNansoseconds(uint32_t).
https://github.com/PaulStoffregen/co...f279114e4b6b53

It is useful for short wait-times. Could be used for PulseIn etc.
No very exact, but at least it is useful for delays of about half a microsecond or less, which is not that easy now.
I agree with dragster on this. To go along the same lines maybe we should have a nanos() to go with millis and mircos?
 
@FrankB
Yes I did, as you pointed out. Wanted to attach a servo to the board but all my servos are 5v and not sure what the signal is - don't want to short the T4.

The servo shouldn't have feedback over the signal line - I use a 3.3V signal to drive servos and power them anywhere from 5V to over 7.2V (high voltage servos) just fine with a Teensy 3.6.
 
The servo shouldn't have feedback over the signal line - I use a 3.3V signal to drive servos and power them anywhere from 5V to over 7.2V (high voltage servos) just fine with a Teensy 3.6.
Thanks Brian. Time to go dig out a servo. Have to remember where I put them all now :)
 
Hardware Serial: Currently trying to debug Serial.read(). Currently not getting an interrupt when data should arrive on data pin.
Not sure yet if my configuration stuff for the LPUART or maybe the IO pin configuration stuff.

Code:
SerialX::begin stat:c00000 ctrl:0 fifo:c00011 water:0
  FIFO sizes: tx:4 rx:4
  Watermark tx:2, rx: 2
    stat:800000 ctrl:2c0000 fifo:c00099 water:20002
I have some new configuration stuff going on for FIFO and WATER... Current debug info shown above, where I believe that the
Uart has fifo sizes of 4 and I tried to configure the water marks for 2 2 and enabled fifo...

Still need to update the write part of ISR to stuff out as many bytes as possible... But trying to figure out why I am not getting any Serial inputs...

Code:
tatic BUFTYPE tx_buffer1[SERIAL1_TX_BUFFER_SIZE];
static BUFTYPE rx_buffer1[SERIAL1_RX_BUFFER_SIZE];

const HardwareSerial::hardware_t UART6_Hardware = {
	IRQ_LPUART6, &IRQHandler_Serial1,
	CCM_CCGR3, CCM_CCGR3_LPUART6(CCM_CCGR_ON),
	IOMUXC_SW_MUX_CTL_PAD_GPIO_AD_B0_03, // pin 0
	IOMUXC_SW_MUX_CTL_PAD_GPIO_AD_B0_02, // pin 1
	2, // page 473
	2, // page 472
};
HardwareSerial Serial1(&IMXRT_LPUART6, &UART6_Hardware, tx_buffer1, SERIAL1_TX_BUFFER_SIZE,
	rx_buffer1,  SERIAL1_RX_BUFFER_SIZE);
Currently the code only changes the MUX configuration for the pins... (I have not changed this part). Looking at changes put into Wire, wonder if I need to update the
actual pin definition. That is Should I also have pointers to: IOMUXC_SW_MUX_CTL_PAD_GPIO_AD_B0_03 ...

Or wondering if we should simply have the hardware definition here say it is pin 0, and then look up both: IOMUXC_SW_MUX_CTL_PAD_GPIO_AD_B0_03 and IOMUXC_SW_MUX_CTL_PAD_GPIO_AD_B0_03

Especially if we have s setTX and setRX for multiple pins... I think I am leaning that way...

Thoughts?
 
@FrankB

I agree with dragster on this. To go along the same lines maybe we should have a nanos() to go with millis and mircos?

Let's see what Paul says. If he accepts the PR, I'll add it for T3.x, and try nanos(). But delayNanoseconds() will be pretty inaccurate for slow F_CPUs. On the other hand +- 200ns are better than nothing :)
 
does that mean you could control leds/servos raw without using timers if the nanosecs are pretty accurate on T4? :)
 
LOL. You can measure the speed of light using servos, then.
I didn't have enough beer to understand the (your) context :confused:

I remember I wrote a servo controller for the C64 using wait-loops in assembler. uhh.. long ago..

edit: ok..got it.. took long :) i meant shiftout which is too fast without delay, not pulsein..
 
Last edited:
Status
Not open for further replies.
Back
Top