Forum Rule: Always post complete source code & details to reproduce any issue!
Page 2 of 172 FirstFirst 1 2 3 4 12 52 102 ... LastLast
Results 26 to 50 of 4292

Thread: Teensy 4.0 First Beta Test

  1. #26
    Administrator Robin's Avatar
    Join Date
    Oct 2012
    Location
    PJRC Global Headquarters
    Posts
    312
    I've shipped beta boards to everyone who has responded to me so far. You should have received an email with the tracking number

  2. #27
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,459
    Quote Originally Posted by mjs513 View Post
    The SDK code is rather convoluted
    Yes, indeed it look like typical semiconductor vendor code, a huge API with macros or trivial functions for every little hardware feature.

  3. #28
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,335
    Quote Originally Posted by Robin View Post
    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 ...
    Expected Delivery by Monday 31 December 2018 by 8:00pm

  4. #29
    Senior Member
    Join Date
    Dec 2016
    Location
    Montreal, Canada
    Posts
    3,050
    Patience is virtue
    my birthday present was being a beta tester

  5. #30
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,335
    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 ...

  6. #31
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,928
    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:
    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 */
    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:
    clock_functions.zip

    Do have a question - will there be teensyduino version to support the T4?

  7. #32
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    2,134
    Quote Originally Posted by mjs513 View Post
    Do have a question - will there be teensyduino version to support the T4?
    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/co...eensy4/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

  8. #33
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,928
    @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.....
    Last edited by mjs513; 12-28-2018 at 01:44 PM.

  9. #34
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,459
    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.

  10. #35
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    2,134
    Quote Originally Posted by mjs513 View Post
    @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

  11. #36
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,928
    @PaulStoffregen
    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.
    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
    There are other problems, including names that conflict with what's in imxrt.h
    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 by mjs513; 12-28-2018 at 03:13 PM.

  12. #37
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    My T4 will arrive wednesday.

    Quote Originally Posted by PaulStoffregen View Post
    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.
    +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 by Frank B; 12-28-2018 at 04:13 PM.

  13. #38
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,296
    Quote Originally Posted by Frank B View Post
    My T4 will arrive wednesday.
    Mine also Monday

    Quote Originally Posted by Frank B View Post
    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
    Not F?

  14. #39
    Senior Member
    Join Date
    Jul 2014
    Posts
    2,289
    Quote Originally Posted by KurtE View Post
    Mine also Monday


    Not F?

    I want Reaumur, or all five (C,D,F,R,K)

  15. #40
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    Quote Originally Posted by KurtE View Post
    Mine also Monday


    Not F?
    OK. A compromise: Rømer - nobody uses it (almost like F )

  16. #41
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,928
    @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.

  17. #42
    Senior Member
    Join Date
    Dec 2016
    Location
    Montreal, Canada
    Posts
    3,050
    aparently i got an alert that its on its way to my house right now, its still my bday today atm lol

  18. #43
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    Happy Birthday!!

  19. #44
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    MJS, what if a flame thrower is connected to LED Pin 13?

  20. #45
    Senior Member
    Join Date
    Dec 2016
    Location
    Montreal, Canada
    Posts
    3,050
    i wish i would have that, to melt the sleet of ice outside the house... a teensy ice melter!

  21. #46
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,928
    @FrankB - Argh! Ok I give up - what would suggest for notification. Just throwing out ideas here. Mike

  22. #47
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    Quote Originally Posted by mjs513 View Post
    @FrankB - Argh! Ok I give up - what would suggest for notification. Just throwing out ideas here. Mike
    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?

  23. #48
    Senior Member
    Join Date
    Dec 2016
    Location
    Montreal, Canada
    Posts
    3,050
    perhaps an event would be better to notify the user code to handle critical tasks before shutdown rather than just halting, we never know what the pins would be driving in a critical environment

  24. #49
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,335
    Quote Originally Posted by tonton81 View Post
    perhaps an event would be better to notify the user code to handle critical tasks before shutdown rather than just halting, we never know what the pins would be driving in a critical environment
    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.

  25. #50
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •