Forum Rule: Always post complete source code & details to reproduce any issue!
Page 47 of 174 FirstFirst ... 37 45 46 47 48 49 57 97 147 ... LastLast
Results 1,151 to 1,175 of 4350

Thread: Teensy 4.0 First Beta Test

  1. #1151
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    Quote Originally Posted by PaulStoffregen View Post
    @manitou - Any chance you could adapt coremarkish to use buffers in OCRAM? But leave the stack in DTCM. Either malloc() or DMAMEM allocate in OCRAM. Really looking to benchmark the performance impact of the different cache settings in the MPU.
    And manitou, can you check if it has any speed-impact to move the interrupts vectors to ITCM?

  2. #1152
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    2,232
    Quote Originally Posted by Frank B View Post
    And manitou, can you check if it has any speed-impact to move the interrupts vectors to ITCM?
    How do I do that?

  3. #1153
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    2,232
    Quote Originally Posted by mjs513 View Post
    The encoder stuff is pretty much direct from the SDK example. Not the cleanest but just needed something working to test XBAR and the module with before I started on anything with quadrature encoders.
    Re: encoder+XBAR
    I downloaded your T4 example from github. When I ran the sketch with a basic rotary encoder
    https://www.sparkfun.com/products/9117
    I saw only 0s from the device. The device has no debounce RC circuitry and no pullups. But the device worked on T4 with the teensy Encoder library. Looking with scope at Encoder lib test, I saw the two ENCA ENCB pins were high as soon as the lib sketch started. The scope showed no voltage on the pins when running the github sketch. So I decided the rotary encoder needed pullups and changed the PADCONFIGs in setup() to enable internal PULLUPS on the T4, e.g.
    CORE_PIN6_PADCONFIG = 0x1f038;
    That's the config that T4 uses for INPUT_PULLUP, and that fixed the github sketch. I was getting good data when turning the encoder clockwise or counter-clockwise.

    https://github.com/mjs513/WIP/tree/m...NC1_test_xbar1

    I also successfully tested the T4 sketch with an encoder simulator running on T3.2 (btot 0, freq 100).
    Last edited by manitou; 01-24-2019 at 03:50 PM.

  4. #1154
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,581
    FlexIO - flexSerial - working like normal Serial class, currently only doing TX...

    That is I have simple sketch:
    Code:
    #include "flex_io.h"
    #include "flexSerial.h"
    
    FlexSerial SerialFlex(-1, 2); // currently setup for pin 2 TX
    
    
    void setup() {
      pinMode(13, OUTPUT);
      while (!Serial && millis() < 4000);
      Serial.begin(115200);
      Serial1.begin(115200);  // lets start up Serial1, to see if we can receive anything from our FlexSerial
      delay(500);
      SerialFlex.begin(115200);
    
      Serial.println("End Setup");
    }
    
    uint8_t loop_char = 'a';
    void loop() {
      digitalWrite(13, !digitalRead(13));
      SerialFlex.println("abcdefghijklmnopqrstuvwxyz");
      delay(500);
    
    }
    
    void serialEvent1() {
      int ch;
      while ((ch = Serial1.read()) != -1) {
        Serial.write(ch);
      }
    }
    Where when I run it I have pin 0 connected to pin2, and the data is output to Serial...
    I have the TX code using interrupts... Still more things to work out like: flush(), on knowing when the last byte was output...

    But next start playing with RX...

    Again this requires the updated imxrt.h in core!

    Would have shown some output from the start... But currently the Serial monitor window does not appear to respect the Autoscroll turned off.

    Also wish I could do a copy from the Monitor after I unplug the cable, but it monitor window is totally disabled...
    Attached Files Attached Files

  5. #1155
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    2,232
    Quote Originally Posted by KurtE View Post
    Would have shown some output from the start... But currently the Serial monitor window does not appear to respect the Autoscroll turned off.

    Also wish I could do a copy from the Monitor after I unplug the cable, but it monitor window is totally disabled...
    What i do to freeze scrolling on SerialPlotter is add a pinMode(pin,INPUT_PULLUP) to sketch, and in loop() i'll fall into while(1); if pin is 0. Then jumper pin to GND to freeze monitor/serialplotter

  6. #1156
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    Quote Originally Posted by manitou View Post
    How do I do that?
    startup.c :
    Code:
    extern unsigned long _ebss;
    
    
    __attribute__ ((used, aligned(1024), section(".fastrun")))
    void (* _VectorsRam[NVIC_NUM_INTERRUPTS+16])(void);
    
    static void memory_copy(uint32_t *dest, const uint32_t *src, uint32_t *dest_end);
    static void memory_clear(uint32_t *dest, uint32_t *dest_end);
    quick'n dirty

  7. #1157
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,959
    Kurt, tycomm can of course be sermon, just need to manually toggle serial for upload

    Also new build for t4 reported to work, see koromix github

  8. #1158
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    Question:
    I get the following error:
    Code:
    c:\temp\arduino_build_355005\sketch\ILI9341_t4.cpp: In member function 'void ILI9341_t4DMA::begin()':
    ILI9341_t4.cpp:11: error: 'init_commands' causes a section type conflict with 'void _initDMA(uint16_t*)'
     PROGMEM static const uint8_t init_commands[] = {
                                  ^~~~~~~~~~~~~
    c:\temp\arduino_build_355005\sketch\ILI9341_t4.cpp:89:21: note: 'void _initDMA(uint16_t*)' was declared here
     PROGMEM static void _initDMA(uint16_t * buffer)
                         ^~~~~~~~
    If I use "Oprimize Debug". Otherwise it works flawlessly with other "optimize" options.

    The "problem" is, the compiler complains that I have a) a const array in PROGMEM, and b) a function in PROGMEM (it's a section named (".progmem))
    - what is the best way to solve this issue ? How does this work with AVR? is PROGMEM for the const array not correct, perhaps?

  9. #1159
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,213
    Quote Originally Posted by manitou View Post
    Re: encoder+XBAR
    I downloaded your T4 example from github. When I ran the sketch with a basic rotary encoder
    https://www.sparkfun.com/products/9117
    I saw only 0s from the device. The device has no debounce RC circuitry and no pullups. But the device worked on T4 with the teensy Encoder library. Looking with scope at Encoder lib test, I saw the two ENCA ENCB pins were high as soon as the lib sketch started. The scope showed no voltage on the pins when running the github sketch. So I decided the rotary encoder needed pullups and changed the PADCONFIGs in setup() to enable internal PULLUPS on the T4, e.g.
    CORE_PIN6_PADCONFIG = 0x1f038;
    That's the config that T4 uses for INPUT_PULLUP, and that fixed the github sketch. I was getting good data when turning the encoder clockwise or counter-clockwise.

    https://github.com/mjs513/WIP/tree/m...NC1_test_xbar1
    Thanks for pointing out the differences with the encoders - the ones I have resistors as part of the breakout board that its on. I did rewicker the sketch because I got tired of manually changing pin configs and xbar inputs, which I always managed to mess up so that the configuration is done as part of the encoder-xbar pin configuration, this includes the xbar_connect. So now to initialize the pins all you do is:
    Code:
      enc_xbara_mapping(6, PHASEA, PULLUPS);
      enc_xbara_mapping(7, PHASEB, PULLUPS);
    obviously the first passed parameter it the pin, the second is if you want that pin to be phasea/phaseb input and the last is if you want to use pullups as @manitou pointed out. I did update the GitHub repository

    https://github.com/mjs513/WIP/tree/m...NC1_test_xbar1

    so if you want to give it a test have fun.

  10. #1160
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,581
    Thanks guys!

    Yep - I thought I would mention the stuff with Serial Monitor, in case Paul expected the Autoscroll stuff to be working. And as a suggestion that maybe allow selection and copy out of the disabled buffer...

    Normally if I am not involved in beta stuff, I also use TyCommander

  11. #1161
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,213
    }
    Where when I run it I have pin 0 connected to pin2, and the data is output to Serial...
    I have the TX code using interrupts... Still more things to work out like: flush(), on knowing when the last byte was output...
    But next start playing with RX...
    Again this requires the updated imxrt.h in core!
    Would have shown some output from the start... But currently the Serial monitor window does not appear to respect the Autoscroll turned off.
    Also wish I could do a copy from the Monitor after I unplug the cable, but it monitor window is totally disabled..
    @KurtE
    Updated the imxrt.h from the latest core and it is working like a charm with pin 2 attached to pin 0. Also when unclick autoscroll the window stops scrolling for me and I was able to copy what it looks like:
    Code:
    Offset to SHIFTBUFNIS 780
    Enable flexio clock
    pin 2 maps to: 20000ba4, port: 401ac000 pin 4
    timer index: 0 shifter index: 0 mask: 1
    Before configure flexio
    CCM_CDCDR: 33f71f92
    VERID:2100404 PARAM:1 CTRL:1 PIN: 10
    SHIFTSTAT:1 SHIFTERR=0 TIMSTAT=0
    SHIFTSIEN:0 SHIFTEIEN=0 TIMIEN=0
    SHIFTSDEN:0 SHIFTSTATE=0
    SHIFTCTL:30402 0 0 0
    SHIFTCFG:32 0 0 0
    TIMCTL:1c00401 0 0 0
    TIMCFG:2222 0 0 0
    TIMCMP:f81 0 0 0
    End Setup
    
    abcdefghijklmnopqrstuvwxyz
    abcdefghijklmnopqrstuvwxyz
    abcdefghijklmnopqrstuvwxyz
    abcdefghijklmnopqrstuvwxyz

  12. #1162
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,959
    Quote Originally Posted by KurtE View Post
    Thanks guys!

    Yep - I thought I would mention the stuff with Serial Monitor, in case Paul expected the Autoscroll stuff to be working. And as a suggestion that maybe allow selection and copy out of the disabled buffer...

    Normally if I am not involved in beta stuff, I also use TyCommander
    The AutoScroll on/off has been working for me - it may reset on occasion with a new upload? .. but it has been working when unchecked to not scroll.

    And I've noted a couple times before that offline SerMon prevents Copy&Paste - and IIRC frank noted once - very prohibitive ...

    I've had to have TyComm open with 1 or 2 other Teensy's collecting Serial output from T4 ... I generally suffer with SerMon and don't use TyComm for Beta stuff either - but in this case it was there ... and I was using it on another IDE tree to upload with Frank's Compile.cmd to update the Echo Serial on the other Teensy's - but with T_Loader open that was messing with ports. Just got the alpha.beta of TyComm and it uploads to T4 so as long as things are going well I may use that to avoid confusion and fights with single instance IDE_SerMon.

  13. #1163
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    2,232
    Quote Originally Posted by Frank B View Post
    And manitou, can you check if it has any speed-impact to move the interrupts vectors to ITCM?
    OK, I modified startup.c. With optimization Faster, there was no change in coremark performance. With optimization Fastest, rate climbed from 2427.42 to 2428.57. Maybe speedups would be more apparent with sketch that requires a lot of ISR activity???

    Other than modified startup.c, testing with stock beta7 and T4@600mhz

  14. #1164
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    546
    Quote Originally Posted by Frank B View Post
    And manitou, can you check if it has any speed-impact to move the interrupts vectors to ITCM?
    I also changed startup.c according to #1156 and re-run my IntervalTimer performance test from #830. I still get some 18.5% load @200kHz interrupt frequency (3.8% for a T3.6). So, at least for the IntervalTimer I do not observe a significant improvement.

  15. #1165
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    As long it is not slower.. The Idea behind that is to have more free DTCM
    Thank you both!

  16. #1166
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    @luni, what do think is the reason for the high load? We should fix that!
    I'd say it is a high-priority issue, if all interrupts are slow.

  17. #1167
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    546
    @luni, what do think is the reason for the high load? We should fix that!
    I'd say it is a high-priority issue, if all interrupts are slow.
    I don't really know. Maybe it has something to do with the fact that RT10XX have a shared interrupt for all PITs. On the other hand, the "ISR-distribution" code is so small that I can not imagine that it really slows it down so much. Maybe some cache issues? But honestly this is over my head. I'll test the QUAD timers today and check if they show the same issue.

  18. #1168
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    Might be the "slow" F_BUS with 150 MHz.
    However, I tried to run it at 300MHz, and it worked.
    Somewhere in this thread.
    Last edited by Frank B; 01-24-2019 at 08:33 AM.

  19. #1169
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,959
    Quote Originally Posted by Frank B View Post
    Might be the "slow" F_BUS with 150 MHZ.
    However, I tried to run it at 300MHZ, and it worked.
    Somewhere in this thread.

    Thread search hit this note that it was tried … but not noted exact syntax to execute ...

    Quote Originally Posted by Frank B View Post
    Played a little bit with the new "F_BUS" (IPG). Default is 150MHz (max in Reference Manual) ..but..at least with 600MHZ core, F_BUS can work with 300MHZ, too.
    edit: 492000000 Hz at "Ludicrous Speed"
    Looks like it would be an edit to this in clockspeed.c?
    Code:
    	uint32_t div_ipg = (frequency + 149999999) / 150000000;
    	if (div_ipg > 4) div_ipg = 4;
    	if ((cbcdr & CCM_CBCDR_IPG_PODF_MASK) != (CCM_CBCDR_IPG_PODF(div_ipg - 1))) {
    		cbcdr &= ~CCM_CBCDR_IPG_PODF_MASK;
    		cbcdr |= CCM_CBCDR_IPG_PODF(div_ipg - 1);
    		// TODO: how to safely change IPG_PODF ??
    		CCM_CBCDR = cbcdr;
    	}
    I just got my T4 in a prior ODD state ... similar to the last with multi Teensy Confusion … seems okay again after 15 sec T4 reset.

    Had to plug it in alone - no debug T_3.2's and it would come up - stayed 'dead' - even with button - I was running TyCommander again not just as SerMon ???
    Last edited by defragster; 01-24-2019 at 09:50 AM. Reason: code from clockspeed

  20. #1170
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    Sorry I'm not at home. Yes, div_ipg I think.

  21. #1171
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    2,232
    Quote Originally Posted by Frank B View Post
    @luni, what do think is the reason for the high load? We should fix that!
    I'd say it is a high-priority issue, if all interrupts are slow.
    There was some followup on PIT ISR latency and double interrupts etc. in
    https://forum.pjrc.com/threads/54711...l=1#post195605

  22. #1172
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    was'nt that solved with "dsb"?

  23. #1173
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    546
    Yes, that was solved "with dsb". I originally thought that the observed double interrupts (in my experimental code) might also be the reason for the slow IntervalTimer (calling the ISR twice). However, it turned out that the IntervalTimer code doesn't have that double interrupt problem and consequently adding a dsb to didn't reduce the processor load.

  24. #1174
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,213
    XBEE - RADIOHEAD LIBRARIES STATUS
    @Paul and others (updating first page for library testing):

    Code:
    works               XBEE        see post #674,  tested with Series1
    works w/caveats     RadioHead   see post #1032
    For Radiohead library and teensy's not sure how you want to handle. Adafruit kept a separate fork and created a subdirectory in examples. We could do the same for the teensy?

  25. #1175
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,581
    Quote Originally Posted by mjs513 View Post
    XBEE - RADIOHEAD LIBRARIES STATUS
    @Paul and others (updating first page for library testing):

    Code:
    works               XBEE        see post #674,  tested with Series1
    works w/caveats     RadioHead   see post #1032
    For Radiohead library and teensy's not sure how you want to handle. Adafruit kept a separate fork and created a subdirectory in examples. We could do the same for the teensy?
    Hi Mike,
    If I read your previous posting correctly did the RFM69 modules act differently on T4 than on T3.2? If not I would think it would be sufficient for now?

    On different front: FlexIO, I rearranged the files into library/example(s), and put current stuff up on githhub: https://github.com/KurtE/FlexIO_t4

    The Transmit only code appears to be working (at least as far as the test was concerned), I have now put in code to hopefully be able to do receive. However this code is not fully working yet:
    Code:
    #include <FlexIO_t4.h>
    #include "flexSerial.h"
    
    FlexSerial SerialFlex(3, 2); // currently setup for pin 2 TX
    
    
    void setup() {
      pinMode(13, OUTPUT);
      while (!Serial && millis() < 4000);
      Serial.begin(115200);
      Serial1.begin(115200);  // lets start up Serial1, to see if we can receive anything from our FlexSerial
      delay(500);
      SerialFlex.begin(115200);
    
      Serial.println("End Setup");
    }
    
    uint32_t last_output = 0;
    
    void loop() {
      int ch;
      if ((millis() - last_output) > 1000) {
        last_output = millis();
        digitalWrite(13, !digitalRead(13));
        SerialFlex.println("abcdefghijklmnopqrstuvwxyz");
      }
      if (Serial1.available()) {
        while ((ch = Serial1.read()) != -1) {
          Serial1.write(ch);  // Updated... 
        }
      }
    
      if (SerialFlex.available()) {
        while ((ch = SerialFlex.read()) != -1) {
          Serial.write(ch);
        }
      }
    }
    One thing that is interesting with this code is, there is no delay between when the strings are output. That is the LA shows continuous output of characters on IO pin 2... Even though there is code to ask if difference between last time I output and now in millis() is > 1000. My guess is I have screwed up the ISR handling.
    Still debugging!

    Update1: some of strange behaviour is because example wrong... Updated above... Where when I receive something from Serial1, I send should write it out back to Serial1... Would also have helped to setup pin 3 for RX

    Now does not hang, does show stuff no going to the RX pin for this, but no response yet... Debugging!
    Last edited by KurtE; 01-24-2019 at 04:01 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
  •