Teensy 4.0 First Beta Test
- Thread starter PaulStoffregen
- Start date
- Status
PaulStoffregen
Well-known member
Yes, indeed it look like typical semiconductor vendor code, a huge API with macros or trivial functions for every little hardware feature.
defragster
Senior Member+
I've shipped beta boards to everyone who has responded to me so far. You should have received an email with the tracking number
Thanks - not sure if it might be a Saturday surprise - but ...
defragster
Senior Member+
Happy birthday Tony
Patience ??? … I was looking to give Paul a heads up on expected delivery … it's only a few hours drive to PJRC so it could/should be here Saturday afternoon ...
Patience ??? … I was looking to give Paul a heads up on expected delivery … it's only a few hours drive to PJRC so it could/should be here Saturday afternoon ...
mjs513
Senior Member+
Yep. My package is due on Monday 12/31 as well, but I am across country. Getting happy.
@PaulStoffregen. Think I got the register map on the tempmon ready to be added to the imrxt.h:
Think this is right. Just followed you other format.
Also, Since there are so many clocks and at least for me I like to double check when they get changed I extracted and recombined the getFreq functions from the SDK, at least for debugging purposes. Have them all in one file for now and they are untested but here it as a first cut:
View attachment clock_functions.zip
Do have a question - will there be teensyduino version to support the T4?
@PaulStoffregen. Think I got the register map on the tempmon ready to be added to the imrxt.h:
Code:
// 53.3: page 2986 TODO...
#define IMXRT_TEMPMON (*(IMXRT_REGISTER32_t *)0x400F8180)
#define TEMPMON_TEMPSENSE0 (IMXRT_TEMPMON.offset000) /**< Tempsensor Control Register 0, offset: 0x180 */
#define TEMPMON_TEMPSENSE0_SET (IMXRT_TEMPMON.offset004) /**< Tempsensor Control Register 0, offset: 0x184 */
#define TEMPMON_TEMPSENSE0_CLR (IMXRT_TEMPMON.offset008) /**< Tempsensor Control Register 0, offset: 0x188 */
#define TEMPMON_TEMPSENSE0_TOG (IMXRT_TEMPMON.offset08c) /**< Tempsensor Control Register 0, offset: 0x18C */
#define TEMPMON_TEMPSENSE1 (IMXRT_TEMPMON.offset090) /**< Tempsensor Control Register 1, offset: 0x190 */
#define TEMPMON_TEMPSENSE1_SET (IMXRT_TEMPMON.offset094) /**< Tempsensor Control Register 1, offset: 0x194 */
#define TEMPSENSE1_CLR (IMXRT_TEMPMON.offset098) /**< Tempsensor Control Register 1, offset: 0x198 */
#define TEMPSENSE1_TOG (IMXRT_TEMPMON.offset09C) /**< Tempsensor Control Register 1, offset: 0x19C */
#define TEMPMON_TEMPSENSE2 (IMXRT_TEMPMON.offset100) /**< Tempsensor Control Register 2, offset: 0x290 */
#define TEMPMON_TEMPSENSE2_SET (IMXRT_TEMPMON.offset104) /**< Tempsensor Control Register 2, offset: 0x294 */
#define TEMPMON_TEMPSENSE2_CLR (IMXRT_TEMPMON.offset108) /**< Tempsensor Control Register 2, offset: 0x298 */
#define TEMPMON_TEMPSENSE2_TOG (IMXRT_TEMPMON.offset10C) /**< Tempsensor Control Register 2, offset: 0x29C */Also, Since there are so many clocks and at least for me I like to double check when they get changed I extracted and recombined the getFreq functions from the SDK, at least for debugging purposes. Have them all in one file for now and they are untested but here it as a first cut:
View attachment clock_functions.zip
Do have a question - will there be teensyduino version to support the T4?
manitou
Senior Member+
Yep, Paul will provide Teensyduino update.
I'm glad you did the clock_functions stuff. I was thinking about that. I think the symbols using -> will need to be changed to match what's in
https://github.com/PaulStoffregen/cores/blob/master/teensy4/imxrt.h
e.g. CCM_ANALOG->PLL_ARM becomes CCM_ANALOG_PLL_ARM
once we have the T4 teensyduino, the compiler will help identify those
mjs513
Senior Member+
@manitou - shoot, I missed those - i got the ones converted with ccm-> to ccm_. Oh well will go through it again and get them updated and repost. I love the compiler for that - found a lot of errors i made like take over the years
EDIT: OK. got it updated. Simple global replace of CCM_ANALOG-> with CCM_ANALOG_. Just in case there are other issues I will repost after I give it a try on Monday night. Yes its new years eve but if you think i am not going to at least run 1 test.....
EDIT: OK. got it updated. Simple global replace of CCM_ANALOG-> with CCM_ANALOG_. Just in case there are other issues I will repost after I give it a try on Monday night. Yes its new years eve but if you think i am not going to at least run 1 test.....
Last edited:
PaulStoffregen
Well-known member
Before anyone goes far down this path, I want to be clear than I do not intend to put a huge & complex low-level API similar to NXP's SDK into Teensyduino.
manitou
Senior Member+
@manitou - shoot, I missed those - i got the ones converted with ccm-> to ccm_. Oh well will go through it again and get them updated and repost. I love the compiler for that - found a lot of errors i made like take over the years
EDIT: OK. got it updated. Simple global replace of CCM_ANALOG-> with CCM_ANALOG_. Just in case there are other issues I will repost after I give it a try on Monday night. Yes its new years eve but if you think i am not going to at least run 1 test.....
There are other problems, including names that conflict with what's in imxrt.h. (I think that's why i didn't attempt the port
)You can do a crude compile test by cloning Paul's github core files, then injecting your clock code into cores/Teensy4/Blink.cc and editing the Makefile with the path to your Teensyduino toolchain, and then do a make
mjs513
Senior Member+
@PaulStoffregen
@manitou
EDIT: Updates here: https://github.com/mjs513/WIP
Understood. Was really doing that just as a double check for my testing purposes. Wasn't going to propose adding it to the core it. Was planning on using within my sketches and just thought it might be useful for others.
@manitou
Hmm - will have to check. Thought I checked them or at least did a sampling for verification. I can wait since I can't really test it anyway. I will keep you posted.
EDIT: Updates here: https://github.com/mjs513/WIP
Last edited:
My T4 will arrive wednesday.
+1
For the temperatures, it should be as simple to use as possible, maybe just two functions to a) set critial temperature(crit) - not more - and b) set temphotcold(hot, cold), both in °C with defaults set during startup and hopefully without throttling and the eventresponder instead... just simple and clean.
edit: Maybe automated throttling can be done in a external, optional, library? (even linux loads a optional driver for that..)
For clock-settings, I was hoping you (Paul) do the API, or define it, at least
+1
For the temperatures, it should be as simple to use as possible, maybe just two functions to a) set critial temperature(crit) - not more - and b) set temphotcold(hot, cold), both in °C with defaults set during startup and hopefully without throttling and the eventresponder instead... just simple and clean.
edit: Maybe automated throttling can be done in a external, optional, library? (even linux loads a optional driver for that..)
For clock-settings, I was hoping you (Paul) do the API, or define it, at least
Last edited:
KurtE
Senior Member+
OK. A compromise: Rømer - nobody uses it (almost like FMine also Monday
Not F?
)
mjs513
Senior Member+
@FrankB. For the temperature monitor you are actually pretty close to the number of functions needed. The tempmonitor actually sets irq bits in the ccm_analog_misc1n register when either the settings break high temp, low temp or panic temp thresholds. So really you just need to do the config (Set measurement frequency bits - uses, set temperature levels (TBD - would say 90 for panic, 80 for high and say 25 for low, just guessing) - enable the irq, then get the current measurement (auto update at the frequency specified), and then tell it what you want it to do. HALT if PANIC temp reached, if it goes high probably need to give a warning by flashing the LED?????. So technically i guess you don't even need the eventresponder? Pardon me if I didn't say all this correctly.
Throttling involves changing the clock freq when the threashold temps are met, and really don't want to mess with that code if I don't have - not comfortable or should say brave enough to do that.
Throttling involves changing the clock freq when the threashold temps are met, and really don't want to mess with that code if I don't have - not comfortable or should say brave enough to do that.
No indication for "hot"/"cold" - its not needed, I'd say.. For "critical", if we reset - the bootloader LED turns on, perhaps? Even if not - a reset + halt is indication enough?
defragster
Senior Member+
If Mike can get a baseline working with chip features and know it works that is step one. The Teensy should have fail safe pull ups etc as Frank already noted, but having shutdown cleanup time would be ideal.
User code should have a way to track it for warming - but a 'no warning hot shutdown' seems a bit minimal. Though going into LIMP mode with slowdown may either not help avert overtemp, or it may actually compromise the system - all of that could be determined by end use case.
Maybe a two step establish as Warning Temp - when that triggers alert the user and update [_isr/callback/event] next trigger to shutdown temp unless/until user updates/take corrective action.
There are new [Pre/POST] steps for WFI - page 11 of this : iMXRT_LowPower_AN12085, that may be enough current drop with function to cool off?
Speaking of warnings - my Beta T4 not out for delivery today - but it left PJRC's State big city Post Office and arrived at my State's big city Post Office this AM - so Saturday delivery is likely/expected based on it being 1 hour from my local delivery post office and 12 + hours to make that trip and get into the carrier vehicle - and it may be making that trip now.
err...no... "hot" fires before critical. So, the user can react to "hot". critical is _really_ critical. And with a reset, all pins get disabled, so, in a sensitve application, the user can add pullups/pulldonws to ensure a secure shutdown-state. This is needed anyway, because during startup the pins are not enabled, too.
- Status