Forum Rule: Always post complete source code & details to reproduce any issue!
Page 23 of 81 FirstFirst ... 13 21 22 23 24 25 33 73 ... LastLast
Results 551 to 575 of 2024

Thread: Teensy 4.0 First Beta Test

  1. #551
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,529
    Quote Originally Posted by defragster View Post
    Changing -fsingle-precision-constant sounds like fun - across all 32b Teensy boards?
    Teensy 3.x isn't changing.

    And on those 3.x boards without 64 bit support in the FPU, you take a massive hit in performance for any constant without the "f" suffix, because the compiler automatically promotes each intermediate result in an equation to full 64 bits.

    On Teensy 4, we can expect this performance impact to be about 50% speed. Maybe? I'm a little concerned it may be worse if the conversions from 32 to 64 have extra overhead.

  2. #552
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,529
    Quote Originally Posted by manitou View Post
    I still have to push the program button afer an upload.
    I've asked Robin to send you a replacement. You should hear from her tomorrow. After you've got a new one, I want to get the board back here so I can look into what went wrong.

    I just tested the replacement board here. It definitely auto-reboots on Ubuntu 18.04 64-bit.

  3. #553
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,529
    Quote Originally Posted by KurtE View Post
    Another sort of generic question: What state to set IO pins when you call some subsystems ::end method
    ....
    So far I am not seeing us doing anything on T4 yet. So question is what should we do? Try to emulate T3, where each type is different?

    EDIT: Also what is a disabled and/or default state on T4 0?

    EDIT2: I know looking at the PDF file that for some of these pins the default is MUX_MODE = 5, could default to this, or could build that into my HardwareTable (SerialX objects). Probably likewise for Wire, SPI...
    Looks like we don't get a disable state in this chip. I've been setting them back to mux = 5. But maybe it should be 0x15, so the input path bit is set? I'm not 100% sure - don't have all the answers here.

    The pad config register is the other issue. The pins default to input keeper mode. That's a nice feature for many things, but not sure how I feel about it with serial. I'm guessing we probably want weak pullup on the receive pins?

    But these are fairly minor issues. I wouldn't lose any sleep over them right now.

  4. #554
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,529
    Quote Originally Posted by Frank B View Post
    ..or..not..it was a cached TCD, I think.
    My understanding is the entire peripheral space is supposed to be configured for no caching and ARM's "strongly ordered" memory access.

  5. #555
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,529
    Quote Originally Posted by KurtE View Post
    As I believe a lot of the USB serial code may be updated maybe this week? ...
    Yes. I had meant to do audio this weekend and USB next week, but I'm now way behind where I wanted to be.

    I'm going to look into several more bugs recently reported, fix as many as I can and roll all that up into beta7. Then look at USB & audio, but the idea is to get beta7 with as many fixes as possible before messing with new USB code.


    Again I know I can copy some of the stuff from onewire to fix... But wondering if some of the OneWire stuff maybe should be defined in Core?
    Oh, that's a complicated matter for another day! Really doesn't make much sense unless we coordinate on an API with the all the other boards (maybe even Arduino too, but I've kind of given up hope they'll ever care about this).

  6. #556
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    7,814
    Quote Originally Posted by PaulStoffregen View Post
    Teensy 3.x isn't changing.

    And on those 3.x boards without 64 bit support in the FPU, you take a massive hit in performance for any constant without the "f" suffix, because the compiler automatically promotes each intermediate result in an equation to full 64 bits.

    On Teensy 4, we can expect this performance impact to be about 50% speed. Maybe? I'm a little concerned it may be worse if the conversions from 32 to 64 have extra overhead.
    Indeed ... have been following that - but the 3.x unchanged wasn't clear - having the default in one different from the other means the same sketch would act differently numerically was where I was headed. Though T4 and after will be unique and must have a way to get full 64b.


    I pulled down current cores - is Mike's code on tap for :: void analogReadRes(unsigned int bits) { }

  7. #557
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    7,814
    KurtE/Paul - with the github/CORE I got earlier today I find this to be working on Serial 2 and 3 with them looped to themselves.

    You'll note the added explicit call to "HardwareSerial:rocessSerialEvents();" is required or a call to yield(); or delay(1); as this code doesn't call yield() [it works when I added it]::
    Code:
    startup.c :: void ResetHandler(void)
    {
        // ...
    	while (1) {
    		//printf("loop\n");
    		loop();
    	}
    I put this same code in my larger cross/loop Serial 1/5 & LedControl & IntervalTimer sketch and all four Serial# ports are running together without problem/error at 5Mbaud - I have not found a faster number that works yet.

    Working sketch::
    Code:
    #define SERIALX2 Serial2
    #define SERIALX3 Serial3
    
    void serialEvent2() {
      //SERIALX2.disableSerialEvents();
      while (SERIALX2.available()) {
        char ch = SERIALX2.read();
        Serial.write(ch);
      }
    }
    void serialEvent3() {
      // SERIALX3.disableSerialEvents();
      while (SERIALX3.available()) {
        char ch = SERIALX3.read();
        Serial.write(ch);
      }
    }
    
    elapsedMillis noDelay;
    void setup() {
      while ( !Serial && millis() < 800 ) ;
      pinMode(13, OUTPUT);
      SERIALX2.begin(5000000);
      SERIALX2.enableSerialEvents();
      SERIALX3.begin(5000000);
      SERIALX3.enableSerialEvents();
      SERIALX2.print( "22222" );
      SERIALX3.print( "33333" );
      noDelay = 0;
    }
    
    void loop() {
      // put your main code here, to run repeatedly:
      if ( noDelay > 1000 ) {
        Serial.print( " ... " );
        Serial.println( millis() );
        SERIALX2.print( "22222" );
        SERIALX3.print( "33333" );
        noDelay = 0;
      }
      HardwareSerial::processSerialEvents();
    }
    Output::
    2222233333 ... 1448
    2222233333 ... 2452
    2222233333 ... 3456
    2222233333 ... 4460

  8. #558
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    2,673
    <edit>: Mike - just glanced at Talkie code - did you alter the PWM frequency? They indicate 62500Hz for PWM. (is that working yet?) I see the AVR stuff in there - but it is the AVR method - suppose it would just be a lesser pin: analogWrite(A8, nextPwm); and that shows as 'PWM4_A0' or maybe Pin_3 common to Arduino that also has 'PWM4_B2' indicated?
    Morning Tim. Gave it a try and looked through the code but was getting too late so I stopped for the night. Was going to really look at the code today and see if I can get it working. Like you said, probably pin3. Ok, have to restart my computer.

    Yes frequency stuff is working, https://forum.pjrc.com/threads/54711...l=1#post194622.

    EDIT: just saw your other post, think Paul already incorporated the PR analogReadRes and averaging on GitHub so if you downloaded it you should have the latest.

  9. #559
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    7,814
    Quote Originally Posted by mjs513 View Post
    Morning Tim. Gave it a try and looked through the code but was getting too late so I stopped for the night. Was going to really look at the code today and see if I can get it working. Like you said, probably pin3. Ok, have to restart my computer.

    Yes frequency stuff is working, https://forum.pjrc.com/threads/54711...l=1#post194622.
    I thought I saw that go by as working - so much going by - with this as post #559. Speaking of late and stopping for the night … today is almost 3 hours old …

    Pulled the CORE as noted - hoped to see your readFreq code there to retry that sketch … just {}

    Nice that EventResponder working with Serial - a shame it so much like SerialEvents from yield() - but then again arbitrary calls with random interruptions would be ugly.

  10. #560
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    1,860
    PDB equivalent?
    The Teensy 3 PDB timer was real handy for clocking peripherals (ADC, DAC, ...). Is there a timer or other mechanism on T4 for doing what PDB did?

  11. #561
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    2,673
    Pulled the CORE as noted - hoped to see your readFreq code there to retry that sketch … just {}
    The two functions I put in (analogWriteRes and AnalogReadAveraging - are in the core. Do we need a analogReadFreq?

    Nice that EventResponder working with Serial - a shame it so much like SerialEvents from yield() - but then again arbitrary calls with random interruptions would be ugly.
    Remember, reading about using eventresponder for serial way back when in the eventresponder thread. So I agree it is nice!

    TALKIE LIBRARY: Got it working, two simple changes using pin3. (1) set up an if define for the RT1052 and (2) added analogWriteFrequency(3, 62500). Now its working. Guess its a pull request to the teensy library, only thing is the examples may need notes in them, since you don't have make pin5 high anymore for the propshield - that one now sure how to handle, unless it gets moved to the .cpp?

  12. #562
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,529
    Quote Originally Posted by manitou View Post
    PDB equivalent?
    The Teensy 3 PDB timer was real handy for clocking peripherals (ADC, DAC, ...). Is there a timer or other mechanism on T4 for doing what PDB did?
    Pretty much any of the unused FlexPWM or QuadTimer sub-modules can be used, by routing their signals through the XBAR.

  13. #563
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,529
    On my todo list is coming up with an unofficial list of which libs are using which timer resources.....

    Hopefully we can mostly avoid conflicts where 2 different libraries need the same module for internal triggering.

  14. #564
    Senior Member
    Join Date
    Jul 2014
    Posts
    2,052
    Quote Originally Posted by WMXZ View Post
    Some update from the SAI front

    Trying to get SAI2 working I run into some issues.
    first, internal logic (SAI2 triggering DMA seems to work properly)
    but I cannot observe any clock signal on the ports
    Solved.
    The pin_mux of sai2 was wrong, should be 2 and not 3

    Code:
        CORE_PIN5_CONFIG  = 2;  //2:MCLK
        CORE_PIN4_CONFIG  = 2;  //2:TX_BCLK
        CORE_PIN3_CONFIG  = 2;  //2:TX_SYNC
        CORE_PIN2_CONFIG  = 2;  //2:TX_DATA0
        CORE_PIN33_CONFIG = 2;  //2:RX_DATA0

  15. #565
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    1,860
    Quote Originally Posted by Frank B View Post
    Perhaps things will be even more weird when we try to *read* data that was written by DMA...
    If this does not work reliable we might even have to disable the cache for these areas.

    Thanks for the code, manitou!!

    Edit: I found a more detailed description:

    DSB in IRQ handler:

    Just a follow up on use of DSB. In several of my T4 ISR handlers where I clear the interrupt flag, I would get double interrupts (as noted by tick++ in ISR), so for correct behavior, I would either have to spin waiting for the device interrupt flag to clear (69 cycles) or use DSB (asm volatile ("dsb")) which took 37 cycles. Measured with ARM_DWT_CYCCNT.

  16. #566
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    1,860
    Quote Originally Posted by manitou View Post
    random is on the bug list. Compiling speedTest fails because no random(). Just copying cores/teensy3/WMath.cpp to cores/teensy4 fixes the problem, but i'm thinking there must be more to it?? The Teensy 4 TRNG is quite complicated, though the NXP SDK has working code. Was the intent for the "random" bug to try to incorporate T4 TRNG???

    finding random()


    I need another set of eyes to solve what should be a simple mystery. I dutifully copied WMath.cpp into T4 core to get random() to work, giving same numbers as on Teensy 3. I just recently wanted to confirm that randomSeed() was ok. T4 and T3.2 behave the same when using randomSeed(), BUT changing the seed on T4 or T3 has no effect on the values returned from random() ???? So then I ran the random() code from WMath.cpp on linux, and the random numbers don't match what T4 and T3.2 are generating --- SO it appears there is another random() hidden in the core/libraries. Where ?

  17. #567
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,529
    Quote Originally Posted by defragster View Post
    ... with Beta 3 1.46 also cannot compile for T_3.6 the Adafruit_SSD1306 i2c Example :: problem with WIRE
    Committed a fix.

    https://github.com/PaulStoffregen/Wi...f5d1111a0d77cd

  18. #568
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,426
    Quote Originally Posted by manitou View Post

    DSB in IRQ handler:

    Just a follow up on use of DSB. In several of my T4 ISR handlers where I clear the interrupt flag, I would get double interrupts (as noted by tick++ in ISR), so for correct behavior, I would either have to spin waiting for the device interrupt flag to clear (69 cycles) or use DSB (asm volatile ("dsb")) which took 37 cycles. Measured with ARM_DWT_CYCCNT.
    This is very interesting to read: https://community.arm.com/processors...gle-core-parts

  19. #569
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,426
    Quote Originally Posted by manitou View Post

    finding random()


    I need another set of eyes to solve what should be a simple mystery. I dutifully copied WMath.cpp into T4 core to get random() to work, giving same numbers as on Teensy 3. I just recently wanted to confirm that randomSeed() was ok. T4 and T3.2 behave the same when using randomSeed(), BUT changing the seed on T4 or T3 has no effect on the values returned from random() ???? So then I ran the random() code from WMath.cpp on linux, and the random numbers don't match what T4 and T3.2 are generating --- SO it appears there is another random() hidden in the core/libraries. Where ?
    NEWLIB maybe??

  20. #570
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,529
    Maybe a C vs C++ namespace issue on random() ?

    I'm going to leave this until beta8. Looks like we may have a long history of not using the correct random(). Will look into this soon, but right now there's been a ton of little fixes, so I'm going to package up beta7 with everything we have so far.

  21. #571
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    2,673
    TALKIE LIBRARY

    Here is a copy of the .cpp file for the changes to the Talkie lib if anyone cares to give it a try. Works on PIN3.Talkie.zip

  22. #572
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,529
    I've uploaded 1.46-beta7 to msg #2. So many small fixes, Kurt's latest on hardware serial.

  23. #573
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    1,860
    Quote Originally Posted by Frank B View Post
    NEWLIB maybe??
    Ah, most likely. there is random() in libc.

  24. #574
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    2,673
    More sensor library testing:

    LCDControl Library: Couldn't resist ordering that LED strip that defroster reference in his post on LEDcontrol. Gave it a try and it still works Pretty neat,

    Sparkfun TMP102 (i2c): Sparkfun's library works fine no issue;

    VL53L0X Range Library: Adafruits works, Pololu's Arduino Library does not work with the T4, the LED blinks brightly and rapidly. But it does work with T3.5's that I tested it on.

  25. #575
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    1,860
    beta7 quick tests:
    -did a few loop back tests on Serial1, Serial3 ... but what is the mapping from Serialx to UARTn (or pin numbers)?? Add to post #3
    -I have one float benchmark (lat-lon to UTM) that has a few floating constants. On beta6 duration was 4230 us, on beta 7 4260 us -- not much difference
    -SPI clock settings look to be working with SPISettings
    -analogWrite on 0 and 1 have correct duty polarity
    Last edited by manitou; 01-07-2019 at 03:00 PM.

Posting Permissions

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