Forum Rule: Always post complete source code & details to reproduce any issue!
Page 44 of 174 FirstFirst ... 34 42 43 44 45 46 54 94 144 ... LastLast
Results 1,076 to 1,100 of 4339

Thread: Teensy 4.0 First Beta Test

  1. #1076
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,428
    Hi Paul - Not needed for T4, but might at some point pull in
    https://github.com/PaulStoffregen/USBHost_t36/pull/23

    As this fixes the Mouse to work on some combo units from Microsoft and Logitech - The first fix for the gigabyte keyboards was to always set the keyboards into BOOT mode, which worked fine for all keyboards I tried. However it had the side effect on the wireless combo units of causing the Mice to also change which caused at least some of them not to work...

    As related question - Have you looked at doing USB Host stuff on this board? And if so how much different is it than T3.6.

  2. #1077
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    2,201
    Quote Originally Posted by mjs513 View Post
    UPDATE: Nevermind - not working tested on pins 8/9 and 10/11 but if someone wants to double check. Not sure what pins are going to be allowed

    Found my answer and now I understand the code:
    So guess the same applies to T4.
    Re: SoftwareSerial

    You could add pin checks for backside UART's. I think it is supposed to work with non-uart pins too, but the code uses F_CPU and cycle counts, so that would need some T4 adjustments. Lib has magic cycles count WORST_INTERRUPT_CYCLES ?? which might need T4 adjustment. One wonders for code that depends on cycle counts, how do the various compiler optimizations (Fast Faster Fastest ...) affect cycle count loop delays ??

    Correction: I had never tried SoftwareSerial on Teensy 3* -- it seems it only works on UART ports as you noted.
    Last edited by manitou; 01-21-2019 at 03:21 PM.

  3. #1078
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,428
    Quote Originally Posted by mjs513 View Post
    Think I got it working - can someone verify for me. Here are the files new files:
    Attachment 15696

    Thanks

    UPDATE: Nevermind - not working tested on pins 8/9 and 10/11 but if someone wants to double check. Not sure what pins are going to be allowed

    Found my answer and now I understand the code:
    So guess the same applies to T4.
    I think that this might be a valid first approach. However I was also thinking that this might also be another interesting place to try out FLEXIO.
    That is a lot of the IO pins have FlexIO pins associated with them. And if you look at about page 2732 in newer PDF you see that for Transmit requires one Timer, one shifter and one pin. Likewise receive also takes one timer, shifter, pin... Maybe more stuff if you wish to support RTS/CTS signals...

    At one point I was starting on trying to setup a FLEXIO SPI, but lost it...

    Was also wondering about has anyone setup any more generic setup for managing Flex IO objects.
    That is it looks like with have 3 FLEXIO units as you can see in table where some of the pins are marked 1:n, 2:n, 3:n... Each of these units have 4 timers, shifters, compares? So would be good if I said I wanted to create a

    Flex UART Transmit on pin 2, there would be a set of calls, where it says: Pin 2 is FlexIO 1:4

    And then the FlexSerial would ask for a free Timer on unit 1 as well as a free shifter on unit 1... Where then it could do the configuration stuff to use those items...
    There are some complications, like for some objects that need two timers. The are needed to be N and N+1, so probably need to the API to ask for two...

    Thoughts?

  4. #1079
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,116
    Quote Originally Posted by KurtE View Post
    I think that this might be a valid first approach. However I was also thinking that this might also be another interesting place to try out FLEXIO.
    That is a lot of the IO pins have FlexIO pins associated with them. And if you look at about page 2732 in newer PDF you see that for Transmit requires one Timer, one shifter and one pin. Likewise receive also takes one timer, shifter, pin... Maybe more stuff if you wish to support RTS/CTS signals...

    At one point I was starting on trying to setup a FLEXIO SPI, but lost it...

    Was also wondering about has anyone setup any more generic setup for managing Flex IO objects.
    That is it looks like with have 3 FLEXIO units as you can see in table where some of the pins are marked 1:n, 2:n, 3:n... Each of these units have 4 timers, shifters, compares? So would be good if I said I wanted to create a

    Flex UART Transmit on pin 2, there would be a set of calls, where it says: Pin 2 is FlexIO 1:4

    And then the FlexSerial would ask for a free Timer on unit 1 as well as a free shifter on unit 1... Where then it could do the configuration stuff to use those items...
    There are some complications, like for some objects that need two timers. The are needed to be N and N+1, so probably need to the API to ask for two...

    Thoughts?
    Hi Kurt,
    My two cents - leave software serial as is just for compatibility and maybe update altsoftserial.

  5. #1080
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,428
    Follow up on SoftwareSerial.

    Going back to T3.5 and 3.6, the additional Serial objects were not added above Serial3 even though they both had additional objects.

    Question is why? First thought is, because apps that were converting from AVR boards expected that was all there were and if they needed to convert to different pins in their code, they might as well convert from using SoftwareSerial and simply specify the actual hardware Serial object they were going to use?

    I guess what I am asking, is it that we wanted to be able to support 3 SoftwareSerial objects and/or we wanted to support them on the same pins as T3.2 and/or we were lazy and never added the others?

    If it was that we wanted the same pins supported, then not sure what we should do here as we dont support 7-10 as there is not underlying UART at these pins...

    But again FlexIO could fix..


    On the actual code. Looks like your mapping should work. Could obviously add more.

    Also now with common class for HardwareSerial on T4, could add members to the class like SPI isMISO, could add isRX isTX like methods, then could simply iterate over each of the objects asking are these valid pins... Or could add staticMember, like mapRXTXpinstoSerial...

  6. #1081
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,116
    Quote Originally Posted by manitou View Post
    Re: SoftwareSerial

    You could add pin checks for backside UART's. I think it is supposed to work with non-uart pins too, but the code uses F_CPU and cycle counts, so that would need some T4 adjustments. Lib has magic cycles count WORST_INTERRUPT_CYCLES ?? which might need T4 adjustment. One wonders for code that depends on cycle counts, how do the various compiler optimizations (Fast Faster Fastest ...) affect cycle count loop delays ??

    Correction: I had never tried SoftwareSerial on Teensy 3* -- it seems it only works on UART ports as you noted.
    Yeah, I had the same reaction as well, that was my confusion in the post. I never really used softwareserial either. Always just used the Hardware serials direct.

  7. #1082
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,116
    Question is why? First thought is, because apps that were converting from AVR boards expected that was all there were and if they needed to convert to different pins in their code, they might as well convert from using SoftwareSerial and simply specify the actual hardware Serial object they were going to use?

    I guess what I am asking, is it that we wanted to be able to support 3 SoftwareSerial objects and/or we wanted to support them on the same pins as T3.2 and/or we were lazy and never added the others?
    @KurtE.
    Have no idea. Think Paul needs to add the history and real function in the Teensy universe. I was thinking about adding more but again not sure of the function so I didn't expand on available ports.

    EDIT: Believe NewSoftSerial superseded softwareserial but looking at it only supports teensy 2x.

  8. #1083
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,428
    my three cents - inflation

    I would not spend anytime trying to make a version of SoftwareSerial or AltSoft or... that is any bit banging version of Serial... Especially since there are 8 hardware Uarts... However it still might be fun to have a FLEXIO version, if for no other reason as a (hopefully) simple implementation to try out flexIO.

    Now assuming that it works well, I would probably then think we could update all of the Soft/Alt/???Serial libraries to do the same mapping like you are doing, to almost all of the IO pins... That way anyone converting from something like Arduino UNO or the like who may have their display output on pins 2 and/or 3 and recompile for T4 it hopefully just works...

  9. #1084
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    My worlds smallest software serial (TX only, any pin), once upon a time written for 3.2 - should work for T4, too (untested) :
    - can be used in NMI fault handlers instead of using anything more complicated:

    Code:
    //smallest software serial : (c) Frank B
    #define DEBUG_BAUD (115200)
    
    void _serialDebugPrint(const uint8_t pin, const char * s) {
      const unsigned long bit = F_CPU / DEBUG_BAUD;
      ARM_DEMCR |= ARM_DEMCR_TRCENA; // <- may be not neeed
      ARM_DWT_CTRL |= ARM_DWT_CTRL_CYCCNTENA; // <- may be not neeed
      pinMode(pin, OUTPUT); // <- needed only once
      digitalWriteFast(pin, 1);// <- needed only once
      
      while (*s) {
       uint16_t c = (0x100 | *s++) << 1; //Add start & stop bits
        noInterrupts(); //<-- not needed in NMI
        unsigned long t = ARM_DWT_CYCCNT;    
        for (int i = 1; i<11; i++) {
          digitalWriteFast(pin, (c & 1) );
          c = c >> 1;      
          while ( ARM_DWT_CYCCNT - t < (i * bit) ) {;}
        }
        interrupts();//<-- not needed in NMI
      }
    }
    just one cent.

  10. #1085
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,767
    Seeing this odd "" char in printf output of temp before ==ascii(248) symbol. It isn't always present
    °C=44.63
    also amazing how fast the temp fluctuates - or how rarely it doesn't change:
    Code:
    void setup() {
      while ( !Serial );
      Serial.println("\n" __FILE__ " " __DATE__ " " __TIME__);
    }
    
    float myTemp, mtl = 0, ii = 0;
    void loop() {
      myTemp = tempmonGetTemp();
      if ( myTemp != mtl ) {
        mtl = myTemp;
        Serial.printf( "\tC=%f\n" , myTemp );
        if ( 0 != ii) {
          Serial.print( "\t    NoChange=" );
          Serial.println( ii );
          ii = 0;
        }
        //delayMicroseconds(500);
      }
      else ii++;
    }

  11. #1086
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    [QUOTE=defragster;196301]Seeing this odd "" char in printf output of temp before ==ascii(248) symbol. It isn't always present
    Looks like an arduino-bug..
    I tried tera-term - the same:


    Code:
      °C=39.432991
            °C=38.711342
            °C=37.989689

  12. #1087
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    Quote Originally Posted by PaulStoffregen View Post
    Planning to do some testing and maybe some initial work on the USB stuff, then package up 1.46-beta8 late Monday or early Tuesday.
    Unsure if it is already there.. a little patch for platorm.txt: Can't find my inital post anmore.
    Code:
    ## Compute size
    recipe.size.pattern="{compiler.path}{build.toolchain}{build.command.size}" -A "{build.path}/{build.project_name}.elf"
    recipe.size.regex=^(?:\.text|\.data|\.text.progmem|\.bootloader)\s+([0-9]+).*
    recipe.size.regex.data=^(?:\.usbdescriptortable|\.dmabuffers|\.usbbuffers|\.data|\.bss|\.noinit|\.vectorsRAM)\s+([0-9]+).*
    recipe.size.regex.eeprom=^(?:\.eeprom)\s+([0-9]+).*
    Displays the correct sizes.

    Robin / Paul:
    Can you imagine a subforum (write access only for beta testers), please... it is very difficult to find anything in this thread.

  13. #1088
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    2,201
    Quote Originally Posted by Frank B View Post
    Can you imagine a subforum (write access only for beta testers), please... it is very difficult to find anything in this thread.
    Agreed things are hard to find. Do you use "Search Thread" ? that works best. i used that to search for recipe.size and got most of your posts, me thinks.

  14. #1089
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    2,201
    in boards.txt change teensy4b.build.fcpu=396000000 to
    teensy4b.build.fcpu=600000000
    even though F_CPU may not be meaningful for the T4, it would give me a warm comfy feeling ...

  15. #1090
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,116
    Quote Originally Posted by KurtE View Post
    my three cents - inflation

    I would not spend anytime trying to make a version of SoftwareSerial or AltSoft or... that is any bit banging version of Serial... Especially since there are 8 hardware Uarts... However it still might be fun to have a FLEXIO version, if for no other reason as a (hopefully) simple implementation to try out flexIO.

    Now assuming that it works well, I would probably then think we could update all of the Soft/Alt/???Serial libraries to do the same mapping like you are doing, to almost all of the IO pins... That way anyone converting from something like Arduino UNO or the like who may have their display output on pins 2 and/or 3 and recompile for T4 it hopefully just works...
    Hi Kurt
    Sorry it so long for me to get back to you all, was busy getting my wife's car towed for the last 3 hours. Argh.....

    Any way I think I agree. Lets leave soft/new/altserial alone for now and then come up with a new improved version just for the T4.x, hoping Paul continues the series

    @Frank
    Copied you smallest softTxSerial code into a one note I created for the T4. Figured it might be easier to find stuff I am interested in besides using the search thread option - it does come in handy as @ manitou pointed out, but.....

  16. #1091
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,116
    SOFTWARE SERIAL PORTED

    Ok. Created pull request, "Updated for T4 (Serial1-8) #3". And I added support for all serials

  17. #1092
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    Quote Originally Posted by mjs513 View Post
    Sorry it so long for me to get back to you all, was busy getting my wife's car towed for the last 3 hours. Argh.....
    I hope it doesn't get too expensive.

  18. #1093
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,767
    Quote Originally Posted by Frank B View Post
    Quote Originally Posted by defragster View Post
    Seeing this odd "" char in printf output of temp before ==ascii(248) symbol. It isn't always present
    Looks like an arduino-bug..
    I tried tera-term - the same:
    Thanks for confirming Frank - providing 'degrees' as a char byte works:
    Serial.printf( " %cC=%2.2f\n" , '' , tempmonGetTemp() );

    <EDIT>: Just noticed this WARNING on compile of the single char '' - so the problem is in source text parsing::
    Syncron_Micros:70: warning: multi-character character constant
    Serial.printf( " %cC=%2.2f\n" , '°' , tempmonGetTemp() );
    This works without warning:: Serial.printf( " %cC=%2.2f\n" , 248 , tempmonGetTemp() );

    Decided it would be fun to see what happens with 500K interrupts/sec during the micros() test - indeed that can nearly double the time it takes micros() to work out an un-interrupted read of the systick time variables:
    T:\tCode\T4\Syncron_Micros\Syncron_Micros.ino Jan 21 2019 15:10:20
    100K micros. Took cycles# 3691180
    // THIS is executed between these two tests >> ITtest.begin( TimeSome, 2);
    100K micros. w/IntvTimer Took cycles# 7005182
    >>> 1ms systick :micros() >>> Clock Speed is:600000000 C=44.63
    With the micros() taking so long my testing code catches errors in failed reading of successive us's - so I thought to bump speed to 800 MHz - if done too early the T4 here won't make it out of setup() without restarting or faulting [fault blink really fast at 800 MHz!]. I can start at 700 MHz - then bump to 800 MHz before leaving setup() and that works okay. And those spare 100 or 200 MHz allow my test to catch the us's even with the spare 500K IntervalTimer interrupts slowing micros() return. <possible test case for the debug lib to see why it is restarting?>

    This may ( I think likely will ? ) change with new USB code - as it seems there is some 'finalization of USB connect' still going on in the first second of T4 life? [ the delay that caused the special case for loop#1 in my test code]
    >> else if ( dd <= 2 && 1 == Lcnt ) // extra us tick may miss loop#1 startup @600 MHz

    I have not yet asked for 900 MHz - but this test running at 800 MHz is showing temp of 51.82 C - a touch drops it 3 degrees.

    Paul:: The above note reminds me of something I wanted to suggest before:: When the T4 goes into FAULT handler the F_CPU_ACTUAL could be dropped to a lower speed/power state to run the "while(1);". I've made a note to test this.
    Last edited by defragster; 01-21-2019 at 10:58 PM.

  19. #1094
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,767
    Pull 338 requested
    Putting this code in T:\arduino-1.8.8T4_146\hardware\teensy\avr\cores\teensy4\star tup.c:: unused_interrupt_vector()
    #if 1
    if ( F_CPU_ACTUAL >= 600000000 )
    set_arm_clock(100000000);
    IOMUXC_SW_MUX_CTL_PAD_GPIO_B0_03 = 5; // pin 13
    IOMUXC_SW_PAD_CTL_PAD_GPIO_B0_03 = IOMUXC_PAD_DSE(7);
    GPIO2_GDIR |= (1<<3);
    GPIO2_DR_SET = (1<<3);
    while (1) {
    volatile uint32_t n;
    GPIO2_DR_SET = (1<<3); //digitalWrite(13, HIGH);
    for (n=0; n < 2000000/6; n++) ;
    GPIO2_DR_CLEAR = (1<<3); //digitalWrite(13, LOW);
    for (n=0; n < 1500000/6; n++) ;
    }
    #else
    if ( F_CPU_ACTUAL >= 600000000 )
    set_arm_clock(100000000);
    while (1) {
    }
    #endif
    }
    Drops the T4's MCU temp ~10 degrees F using my IR thermometer - seeing 86 to 90F instead of 96 to 100.

  20. #1095
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,116
    Quote Originally Posted by defragster View Post
    Pull 338 requested
    Putting this code in T:\arduino-1.8.8T4_146\hardware\teensy\avr\cores\teensy4\star tup.c:: unused_interrupt_vector()


    Drops the T4's MCU temp ~10 degrees F using my IR thermometer - seeing 86 to 90F instead of 96 to 100.
    Hi Tim

    You didn't do a check of what tempmonGetTemp is reading vs your IR thermometer. There is a calibration I have to pull from the OCOTP register - was wondering if it was working.

  21. #1096
    Senior Member xxxajk's Avatar
    Join Date
    Nov 2013
    Location
    Buffalo, NY USA
    Posts
    528
    Quote Originally Posted by mjs513 View Post
    Hi Tim

    You didn't do a check of what tempmonGetTemp is reading vs your IR thermometer. There is a calibration I have to pull from the OCOTP register - was wondering if it was working.
    FWIW and for the rest of us, that 10 degrees Frankenstein == 5.58C drop

  22. #1097
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,767
    Quote Originally Posted by mjs513 View Post
    Hi Tim

    You didn't do a check of what tempmonGetTemp is reading vs your IR thermometer. There is a calibration I have to pull from the OCOTP register - was wondering if it was working.
    Patience ... I need to hook up Serial4 Debug again - killed it when working to test KurtE's 8 ports. So no way to print easily.

    Then I'll move on with my replacement debug lib ... having a hard time starting because I don't know what to call it ...
    Before it was debug_t3 - where it was Teensy 3 - but with #ifdef ideally it can work together with _t4.
    It is a pain but I liked '_t' there so a search could find any debug code easily ... maybe I'll go with _tt since some may have noted I always double my temp var names that is 'i' becomes 'ii' because I can search for and see it more easily versus jj and kk

    Looks like the speed drop on Fault will be in next beta! :: "PaulStoffregen commented" ... "going to merge this now... but later I'd like to see this done in a way that doesn't alter F_BUS"

  23. #1098
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,116
    Looks like the speed drop on Fault will be in next beta! :: "PaulStoffregen commented" ... "going to merge this now... but later I'd like to see this done in a way that doesn't alter F_BUS"
    Does changing the AHB divider count as changing F_BUS

  24. #1099
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    2,201
    Quote Originally Posted by mjs513 View Post
    Hi Tim

    You didn't do a check of what tempmonGetTemp is reading vs your IR thermometer. There is a calibration I have to pull from the OCOTP register - was wondering if it was working.
    FWIW, my digital meter thermometer probe touching the 1052 chip reads cooler than what tempmon reports.
    Code:
    MCU        meter   (degrees C)
    T4   49.6
    T4   46.9  38.4   beta2
    EVK  35.5  30.7
    EVKB 39.4  31.9
    1062 41.4  33
    Last edited by manitou; 02-02-2019 at 12:20 AM.

  25. #1100
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,590
    Quote Originally Posted by KurtE View Post
    Again I guess the real question I am asking here is how we should try to make ili9341_t3 library work? Does it need to be compatible with how it works on a T3.x? Should it require hardware CS pin? Should it use FB? DMA? ...
    I want to see a "default" library for ILI9341 using a frame buffer (150K DMAMEM) and some sort of timer-triggered DMA refresh. Drawing operations should probably update a "dirty region" so the refresh can transfer only the required area that's actually been modified since the prior refresh.

    3.5 inch 480x320 displays with ILI9488 are now appearing on the market and likely to become the norm over the next few years. Hoping to do the same, using a big 300K buffer in OCRAM (when we move to the 1062 chip....)

Posting Permissions

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