Forum Rule: Always post complete source code & details to reproduce any issue!
Page 51 of 175 FirstFirst ... 41 49 50 51 52 53 61 101 151 ... LastLast
Results 1,251 to 1,275 of 4362

Thread: Teensy 4.0 First Beta Test

  1. #1251
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    @WMXZ, yes, I have your code here :-) I see some lines for SPDIF - is that already working, too?

    Raspi-adapter: I'll just drop RX for the first revision.

  2. #1252
    Senior Member
    Join Date
    Jul 2014
    Posts
    2,398
    Quote Originally Posted by Frank B View Post
    @WMXZ, yes, I have your code here :-) I see some lines for SPDIF - is that already working, too?
    Did not try SPDIF (have no SPDIF device), It was only a test to see if I can get SAI2 working. SPDIF clock is one of the inputs. In the end, I found the error and did not need it.
    (At the moment I'm stuck (better screwed up) with USDHC)

  3. #1253
    Junior Member
    Join Date
    Dec 2014
    Posts
    16
    Quote Originally Posted by KurtE View Post

    As for RPI? Wondering if the new RPI3+ boards are exactly the same as the RPI0? ones.
    The 40 pin header is identical on all versions of the P that use iti; what is new on the Pi3 B+ is the power header to connect the POE (Power over Ethernet) HAT.

  4. #1254
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    Quote Originally Posted by daywalker03 View Post
    The 40 pin header is identical on all versions of the P that use iti; what is new on the Pi3 B+ is the power header to connect the POE (Power over Ethernet) HAT.
    I think the first models had a 26 pin header. And that's good, because we don't have enough regular pins..

  5. #1255
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,319
    Quote Originally Posted by defragster View Post
    Did a quick scan after prior - the descriptors and the code are spread different from the 'in progress' core code ... global search on T3 tree shows undef as well - there are lots of crossed/built_on dependencies - that message isn't real specific - I'm not sure where I'd begin.

    Only look I ever on descriptors was somebody wanted to change USB types during runtime startup and I found a place for that he got working ...

    It could be flag passing negating something in one place that is needed?
    Found why I'm getting the error. All the #includes for the USB devices like the joystick are commented out in WPogram.h. When I uncomment them they lead me to all the #if 0's that are in the core. Just thought I would let you know.

  6. #1256
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    10,115
    Quote Originally Posted by mjs513 View Post
    Found why I'm getting the error. All the #includes for the USB devices like the joystick are commented out in WPogram.h. When I uncomment them they lead me to all the #if 0's that are in the core. Just thought I would let you know.
    Good discovery - '//#include "usb_joystick.h"' is pretty subtle in a key [ default (?) ] file for inclusions and won't leave traces

  7. #1257
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,749
    Quote Originally Posted by defragster View Post
    Mike - Teensy View is a Teensy PCB sized and pinned 128x32 OLED from SparkFun - pretty cool - never found need to make one permanent - but I got two

    Kurt - Any alternatives it can offer is good - pretty sure the 1062 is on order and pending delivery in some quantity. I went looking I thought it was second SPI that went missing - even 7.5 would be better than nothing or most alternative busses for most uses.
    Actually can probably run faster. I am playing around with some of the dividers for FlexIO..
    The base clock going in runs at 480mhz, default dividers 2 and 8 so base flexio is default to 30mhz. So now tried 3 and 1 so 160mhz and it looks like min SPI divider of 4 here is could get 40mhz...

    But the signals don't look clean! Still experimenting. Oops The ground wire to the LA came off. Looks cleaner now.


    Here is showing at 20mhz...
    Click image for larger version. 

Name:	screenshot.jpg 
Views:	40 
Size:	40.5 KB 
ID:	15743

    Still has large gap between outputs, will work on that soon.

  8. #1258
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    10,115
    Quote Originally Posted by KurtE View Post
    Actually can probably run faster.
    ...
    Your prior comment suggested you hadn't gotten to tweaking yet, assumed you'd get there Given CAN FD is likely taking 2nd SPI w/1062 it is very good the FlexIO can function - and the 1062 adds more of those it seems.

  9. #1259
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,319
    Quote Originally Posted by defragster View Post
    Your prior comment suggested you hadn't gotten to tweaking yet, assumed you'd get there Given CAN FD is likely taking 2nd SPI w/1062 it is very good the FlexIO can function - and the 1062 adds more of those it seems.
    Depends where Paul decides to put them. Right now you have CAN1 and CAN2. You could always substitute CANFD for CAN1. Then put CAN1 back on future T4.x's

    Tim - gave up a usb - started reading the USB chapter and gave me a giant headache. Not sure how Paul sorted that out. Well, maybe not gave up but...

  10. #1260
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    Wow Kurt, good work.

  11. #1261
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    10,115
    Quote Originally Posted by mjs513 View Post
    Depends where Paul decides to put them. Right now you have CAN1 and CAN2. You could always substitute CANFD for CAN1. Then put CAN1 back on future T4.x's

    Tim - gave up a usb - started reading the USB chapter and gave me a giant headache. Not sure how Paul sorted that out. Well, maybe not gave up but...
    Swapping CAN1 for CANFD would be a seemingly safe and good exchange - I didn't follow enough to see that. If that preserved other native SPI ... and added 500 KB RAM and the third group of FlexIO the T4 would be much improved for the having 1062

    Putting USB aside facing that seems reasonable given the ground may shift when the more complete USB gets dropped in - and even if you found all the parts there may be unfixed pieces until then.

  12. #1262
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,829
    Giving up CAN1 would be tough - not because of CAN1, but due to the other stuff shared on its pins.

    Pins 11 & 13 are shared with SPI, so those are untouchable.

    Pins 22 & 23 are more likely candidates. But 23 is shared with I2S1 MCLK.

    On my list of stuff to investigate is whether MCLK can be shared between two different I2S ports. If so, that might open up the possibility to reassign pin 23.

    But we also need analog input on pin 23. Another subtle feature of the assignments we currently have for pins 14-23 is all 10 can be accessed by either ADC. Most of the alternates mux to only 1 of the ADCs. Not a critical feature, but having the ability for all the main analog inputs to use either physical ADC inside the chip does give some really interesting possibilities for the future....

  13. #1263
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    Quote Originally Posted by Frank B View Post
    I think the first models had a 26 pin header. And that's good, because we don't have enough regular pins..
    Ok, I think I have to make two board variants : T4 and T35/T36. Found no good way to combine the different pinouts. The T4 variant will not have pin 32, 36,37 and 38 - just not enough pins on T4.. I can only hope it works with some "hats".
    I'll make T4 first - because I want to try some of these Rasperry SPI Displays, and perhaps Audio with T4. Layout is done, if I upload it tomorrow the boards are done Tuesday, and then it takes two weeks to ship..

  14. #1264
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,319
    Quote Originally Posted by PaulStoffregen View Post
    Giving up CAN1 would be tough - not because of CAN1, but due to the other stuff shared on its pins.

    Pins 11 & 13 are shared with SPI, so those are untouchable.

    Pins 22 & 23 are more likely candidates. But 23 is shared with I2S1 MCLK.

    On my list of stuff to investigate is whether MCLK can be shared between two different I2S ports. If so, that might open up the possibility to reassign pin 23.

    But we also need analog input on pin 23. Another subtle feature of the assignments we currently have for pins 14-23 is all 10 can be accessed by either ADC. Most of the alternates mux to only 1 of the ADCs. Not a critical feature, but having the ability for all the main analog inputs to use either physical ADC inside the chip does give some really interesting possibilities for the future....
    Wow. Tradeoffs not easy. Almost want to say to wait for CANFD but that is one of the features of the M7 that most others don't have with extra hardware.

  15. #1265
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    Which hardware uses CANFD? Never worked with CAN. It's used in cars - are there more uses? Seems interesting..

    Edit: The obvious solution is to add 2-3 rows of pins..
    But a T4 with more PINs would of course compete with the Teensy 3.5 and 3.6. Not good for business.
    Last edited by Frank B; 01-27-2019 at 12:42 AM.

  16. #1266
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,319
    Quote Originally Posted by Frank B View Post
    Which hardware uses CANFD? Never worked with CAN. It's used in cars - are there more uses? Seems interesting..

    Edit: The obvious solution is to add 2-3 rows of pins..
    But a T4 with more PINs would of course compete with the Teensy 3.5 and 3.6. Not good for business.
    Besides for auto's it is used in UAV's, robotics, etc. Right now UAVCAN uses CAN but UAVCAN2 is going to support CAN and CANFD. Also used in UAVAEROSPACE applications. tonton81 can give you more details on capabilities between both. I actually got UAVCAN implemented on Teensy 3.x, https://forum.pjrc.com/threads/53394...ghlight=uavcan.

  17. #1267
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    10,115
    Suppose that is why I had not seen CAN1 as an exchange for CANFD - nice joke Mike

    2-4 more pins would be handy - might even open up room for better SD card mounting -

  18. #1268
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,319
    Quote Originally Posted by defragster View Post
    Suppose that is why I had not seen CAN1 as an exchange for CANFD - nice joke Mike

    2-4 more pins would be handy - might even open up room for better SD card mounting -
    Really wasn't meant as a joke - feel a little embarrassed. Didn't think the ramifications through. Real good explanation by Paul, and understanding grows daily

  19. #1269
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    10,115
    Mike - it is good to say wrong stuff now and then - I've found it brings out some of Paul's best explanations

    Frank - the rPi adapter seems cool - will be interested to see it develop - especially if it is worth sharing.

    I think I figured out some of the INO<>CPP<>C confusion with printf, printf_debug, Serial and Serial# that made the Fault handler seem so odd - on T3 the printf_debug was off and it is #defined I finally noticed over normal 'printf' and having it on needed attention so getting the debug_tt ported/upgraded seems like the next thing.

    Also I closed the IDE for some time and Teensy_ports/Win10 or whatever the issue was ( since T4 was not showing right in IDE -Tools/Port list ) seems better. Just unplugged the hub with all three on and T4 came up running unlike before where T4 had to come first. Though the one T_3.1 is not showing in T_ports IDE list now ... I'm hoping it is safe to expect that to clear up when the more complete USB stack on T4 is ready as there seems to be some odd contention.

  20. #1270
    Senior Member
    Join Date
    Jul 2014
    Posts
    2,398
    Quote Originally Posted by defragster View Post
    2-4 more pins would be handy - might even open up room for better SD card mounting -
    If I got the orientation right, the actual layout has still room for improvements. actual location id too far in the middle to allow direct soldering of a uSD card (the decoupling capacitors are interfering). The (uSD) pin spacing (1.1 mm) on the other hand is not compatible with any header (I soldered a 1 mm header by twisting outside header pins). Unfortunately Paul has overseen my earlier question (https://forum.pjrc.com/threads/54711...l=1#post195131) on intended uSD connection.

  21. #1271
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    10,115
    Not sure if anyone looked into the debug_t3 stuff - the goal was to not SPEW but keep a trace log when desired { code call for a given 'index 0-9' recorded line number and a passed uint32_t and name of last func() that called } , then if there was trouble the trace would show logged info. Would allow Assert to stop - and I added a HaltIf() - but I just made the Assert not fatal allowing a return to runnign code - so that is what the HaltIf did - and the logic was same as Assert - so it is redundant.

    The _t3 code only got as far as hardcoded to Serial - needs a rewrite to make that to allow user specifying the Stream* - for now I just hardcoded Serial1 since Serial is write only and it works for output and user prompted from there with a Teensy Echo'ing the chars to/from a second SerMon.

    Are there working T4 commands for :: _reboot_Teensyduino_ and _restart_Teensyduino_ ? I had those in the prompt area to allow that for when offers a better way than Button or replugging operation.

    I was thinking I was keeping it SMALL and fast to not interfere with problem at hand - only kept 10 item recording list. I think it is cool - works as I used it - but I think the TODO list is longer than the feature list and I just added a couple TODO items.

    It shows things like where in the end this led to the assert: float x = log (0);
    ___ ASSERT FAILED ___ FILE >> T:\tCode\libraries\debug_tt\examples\Asserts\Asser ts.ino
    ___ in function >> setup() at LINE# >> 37
    Expression >> isfinite( x )

    >>>> ABORT >>>> ASSERT FAILED
    >>>> debug_fault >>>> debug_fault >>>> TYPE:ASSERT
    Debug Info:
    3 => 470 0x1D6 [L#33_C#2 _<< last func::setup
    7 => 469603 0x72A63 [L#30_C#1
    ___ ASSERT FAILED ___ 'y' to continue ...
    'd' to call Debug_Dump()
    'b' Teensy Bootloader
    'r' Restart Teensy
    'z' Zero Debug logs
    Where this made the entry #: 3 => at 470 millis() as Call#2 with :: deb_tt( 3, millis() );
    And Call#1 in this short example was from line #30 :: deb_tt( 7, micros() );

    And the recorded uint32_t for micros&millis is shown in DEC and HEX

    The 'd' option should still work as well like under T3 - including after a fault - you can put a func() in user code to call to spew data or run code of your choice.

    And I made NULL #defines for the 'code' so everything could be disabled with a #define - to allow test runs with or without it with the instrumentation in place.

  22. #1272
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    @luni,
    do you want to test this (?): https://github.com/PaulStoffregen/cores/pull/347
    - no loop
    - check registers only if channel is in use
    together with the other changes, it'll be as fast as 3.6 - don't know exactly because I have so many other changes in my installation..

  23. #1273
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    SerialFlash: Works

    Code:
    Raw SerialFlash Hardware Test
    SPI MISO: 12 MOSI: 11, SCK: 13
    
    Read Chip Identification:
      JEDEC ID:     EF 40 18
      Part Nummber: W25Q128FV
      Memory Size:  16777216 bytes
      Block Size:   65536 bytes
    
    Reading Chip...
    
    Writing 32 signatures
    
    Double Checking All Signatures:
      all 8192 signatures read ok
    
    Checking Signature Pairs
      all 4095 signature pairs read ok
    
    Checking Read-While-Write (Program Suspend)
      write 256 bytes at 512
      write time was 390 microseconds.
      read-while-writing: 00 00 00 00 15 F5 95 4B 
      test passed, good read while writing
    
    Checking Read-While-Erase (Erase Suspend)
      erase time was 276770 microseconds.
      erase correctly erased 65536 bytes
      read-while-erasing: 00 00 00 00 15 F5 95 4B 
      test passed, good read while erasing
    
    All Tests Passed  :-)
    
    Test data was written to your chip.  You must run
    EraseEverything before using this chip for files.
    
    ----------------------------------------------------
    
    SPI MISO: 12 MOSI: 11, SCK: 13
    Flash Memory has 16777216 bytes.
    Erasing ALL Flash Memory:
      estimated wait: 40 seconds.
      Yes, full chip erase is SLOW!
    ............................................................
    ..
    Erase completed
      actual wait: 62 seconds.

  24. #1274
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    578
    Quote Originally Posted by Frank B View Post
    @luni,
    do you want to test this (?): https://github.com/PaulStoffregen/cores/pull/347
    - no loop
    - check registers only if channel is in use
    together with the other changes, it'll be as fast as 3.6 - don't know exactly because I have so many other changes in my installation..
    Here the results for 200kHz interrupt frequency


    Generated load for T3.6 @180MHz, empty ISR
    1 Timer 3%
    4 Timers 12%

    Generated load for T4.0 empty ISR (PR347)
    1 Timer 11.8 % (was 18% with old version)
    4 Timers 72%

    How did you test? Maybe I do something wrong? Here my test code:
    Code:
    #include "arduino.h"
    
    IntervalTimer t1, t2, t3, t4;
    
    void test() // dummyfunction
    {
      //digitalWriteFast(0, !digitalReadFast(0));
    }
    
    void test2() // dummyfunction
    {
      //digitalWriteFast(0, !digitalReadFast(0));
    }
    
    
    void test3() // dummyfunction
    {
     //digitalWriteFast(0, !digitalReadFast(0));
    }
    
    void test4() // dummyfunction
    {
      //digitalWriteFast(0, !digitalReadFast(0));
    }
    
    volatile int dummy;
      constexpr unsigned loops = 100000;
    
    void setup()
    {
      while (!Serial)
        ;
    
      // required for T3.6
      ARM_DEMCR |= ARM_DEMCR_TRCENA;
      ARM_DWT_CTRL |= ARM_DWT_CTRL_CYCCNTENA;
    
    
      // Measure cycles required for loop without any interrupts
      noInterrupts();
      uint32_t start = ARM_DWT_CYCCNT;
      for (unsigned i = 0; i < loops; i++)
      {
        dummy++;
      }
      uint32_t end = ARM_DWT_CYCCNT;
      float base = end - start;
    
      // activate interrupts and IntervalTimer
      interrupts();
      t1.begin(test, 5 );
      // t2.begin(test2, 5);
      // t3.begin(test3, 5);
      // t4.begin(test4, 5);
    
      start = ARM_DWT_CYCCNT;
      for (unsigned i = 0; i < loops; i++)
      {
        dummy++;
      }
      end = ARM_DWT_CYCCNT;
    
      float load = base / (end - start);
      Serial.printf("Load: %.3f\n", 100.0 * (1 - load));
    }
    
    
    int tt1=0, tt2=0;
    
    void loop()
    {  
    }

  25. #1275
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    Well, at least faster

    I check again.

    Edit: Load:6.827 with the old test-program. (Optimize "fastest"). Have you switched the clock to IPG?

    - Wasn't ~6 load of T 3.6? I remember it was about 6.. now, the new ~3 will be hard without IPG overclock..
    I don't have more Ideas..

    Did you try to measure the _absolute_ time ?
    Last edited by Frank B; 01-27-2019 at 02:49 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
  •