Forum Rule: Always post complete source code & details to reproduce any issue!
Page 18 of 83 FirstFirst ... 8 16 17 18 19 20 28 68 ... LastLast
Results 426 to 450 of 2054

Thread: Teensy 4.0 First Beta Test

  1. #426
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,436
    ok no problem - how can I tell the compiler to use OCRAM for this array? It was not my intention to use DTCM anyway. I thought DMAMEM is OCRAM.

  2. #427
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,436
    .bss.dma : { *(.dmabuffers) . = ALIGN(16); } > RAM

    but dmabuffers is ocram.. looks like the linker is not doing what we think it does

  3. #428
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    1,862
    Quote Originally Posted by Frank B View Post
    Good news: simple SPI (8bit) transfer works (have not tried reading).
    beta SPI lib is hardwired to 12.5 mbs, no code yet for configuring clock rate, BUT you can manually override by setting divider (DIV) in LPSPI4_CCR, see
    https://forum.pjrc.com/threads/54711...l=1#post194356
    Discrete SPI CLK rates are 37 mhz, 25 mhz, 19 mhz, 15, 12.5, ...

    I have done simple SPI benchmarks with MISO to MOSI. And I have exercised SPI serial flash on prop shield from T4. all ok

    EDIT: afer SPI lib upgrade, tested prop shield SerialFlash with SPI CLK 37.5 (settings requests 50mhz). Can read and write SPI serial flash. Scope shows clock at 37.5 mhz, Vpp 2v.
    Last edited by manitou; 01-12-2019 at 09:56 PM.

  4. #429
    Senior Member
    Join Date
    Nov 2012
    Posts
    1,021
    @Frank B: The audio library also uses DMAMEM so I tried compiling the PlaySynthMusic example. It fails because it can't find AudioStream.h and, indeed, that file is not in cores/teensy4. It appears that the audio library hasn't been tested (or even installed?) yet, so this DMAMEM issue may have to be solved to get that working too.

    Pete

  5. #430
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,541
    I've ported IRremote. Here's the modified code if anyone wants to try before beta7.
    Attached Files Attached Files

  6. #431
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,436
    Quote Originally Posted by el_supremo View Post
    @Frank B: The audio library also uses DMAMEM so I tried compiling the PlaySynthMusic example. It fails because it can't find AudioStream.h and, indeed, that file is not in cores/teensy4. It appears that the audio library hasn't been tested (or even installed?) yet, so this DMAMEM issue may have to be solved to get that working too.

    Pete
    Pete, here's a PR I did some days ago:
    https://github.com/PaulStoffregen/cores/pull/305

    Paul is working on it and I think he changes some things, but the PR should help to move on.

  7. #432
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,541
    Yes, I'm going to work on AudioStream this weekend (and look into the DMAMEM linker issues). Want to spend a little more time on experimenting with doing AudioStream a little differently than before, to make best use of DTCM & OCRAM.

  8. #433
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,541
    Quote Originally Posted by Frank B View Post
    If someone wants to know how to switch the IMXRT off completely, mail me.. tested, works... but I don't write that here, because if you have no long delay before that, there is currently no way to switch it on again, as it will immediately switch off when it runs the program with the command ... so..it's risky. have not tried if the 13-seconds reset works in this case.. [FONT=monospace]
    Frank - please email me this code, if you still have it.

    Anything that requires the 13 second recovery is my highest priority!

  9. #434
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,436
    It does not NEED the 13-second recovery - It's needed only If you don't insert insert a delay before switching off It's like these most useless toys which switch of themselfes..
    You have mail in a few minutes.

  10. #435
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    2,702
    Never played with ir recv lib before. Was wondering if this would work as well:
    https://www.amazon.com/SunFounder-In...ustomerReviews this it uses a VS/1838B ir receiver.

  11. #436
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,541
    Quote Originally Posted by mjs513 View Post
    Was wondering if this would work as well:
    https://www.amazon.com/SunFounder-In...ustomerReviews this it uses a VS/1838B ir receiver.
    Yes, that looks like it should work.

    Most IR remotes use 38 kHz, but some rate ones are 56 kHz. If you have one of those remotes, you'll need a module with the proper frequency reception. Almost all the normal ones are 38 kHz.

  12. #437
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    2,702
    Just ordered one - real inexpensive. Should get it on Sunday and will give it a test if no one else gives it a try.

  13. #438
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,436
    some are 36kHz - the38kHz receivers will work with them too, because the inbuilt filters are not that good. you'll see a slightly reduced range. try a minimum distance of 1m, because the internal amplifiers can overshoot/overdrive ( what is the correct English term?) , too.

  14. #439
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    4,212
    I am trying to test some of the Serial3 (UART2) CTS pin, which I believe should be pin 18 (only CTS pin defined), and running into some issues. So did a quick look and see:

    When I did a query for Searching 3059 files for "IOMUXC_SW_MUX_CTL_PAD_GPIO_AD_B1_01"

    I noticed that in core_pins.h we have:
    Code:
    #define CORE_PIN18_CONFIG	IOMUXC_SW_MUX_CTL_PAD_GPIO_AD_B1_01
    #define CORE_PIN19_CONFIG	IOMUXC_SW_MUX_CTL_PAD_GPIO_AD_B1_00
    But it also found it in Wire library: WireIMXRT.cpp
    Code:
    	IOMUXC_SW_MUX_CTL_PAD_GPIO_AD_B1_00, // 18/A4  AD_B1_01  GPIO1.17  I2C1_SDA
    	IOMUXC_SW_MUX_CTL_PAD_GPIO_AD_B1_01, // 19/A5  AD_B1_00  GPIO1.16  I2C1_SCL
    Which shows that 18 and 19 are swapped here or is it just the comments on the wrong lines?

  15. #440
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    2,702
    @KurtE
    Which shows that 18 and 19 are swapped here or is it just the comments on the wrong lines?
    Think the comments are wrong. Been using SCL on pin 19 so 01 and 00 should be swapped in the comment.

  16. #441
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    1,862
    Quote Originally Posted by PaulStoffregen View Post
    I've ported IRremote. Here's the modified code if anyone wants to try before beta7.
    I copied the 2 files into my beta6. On T3.2, I compiled and ran the IRsendDemo example and scope on pin 5 showed properly modulated 42 khz carrier with Sony code 0xa90.
    On Teensy 4, i get compile errors
    Code:
    /u1/home/linux/arduino-1.8.8/hardware/teensy/avr/libraries/IRremote/boarddefs.h:51:26: error: 'PORTB' was not declared in this scope
     # define BLINKLED_ON()  (PORTB |= B00100000)
                              ^
    /u1/home/linux/arduino-1.8.8/hardware/teensy/avr/libraries/IRremote/IRremote.cpp:196:10: note: in expansion of macro 'BLINKLED_ON'
         else BLINKLED_ON() ;   // if no user defined LED pin, turn default LED pin for the hardware on
              ^
    /u1/home/linux/arduino-1.8.8/hardware/teensy/avr/libraries/IRremote/boarddefs.h:52:27: error: 'PORTB' was not declared in this scope
     # define BLINKLED_OFF()  (PORTB &= B11011111)
                               ^
    /u1/home/linux/arduino-1.8.8/hardware/teensy/avr/libraries/IRremote/IRremote.cpp:198:10: note: in expansion of macro 'BLINKLED_OFF'
         else BLINKLED_OFF() ;   // if no user defined LED pin, turn default LED pin for the hardware on
              ^
    Using library IRremote at version 2.2.3 in folder: /u1/home/linux/arduino-1.8.8/hardware/teensy/avr/libraries/IRremote 
    Error compiling for board Teensy 4-Beta1.
    I hacked boarddefs.h to use digitaWrite for default LED, and example compiled and ran on Teensy 4. I saw 41.7khz carrier on pin 7 properly modulated for the Sony code 0xa90. So transmit looks good ... I may later hook it up to IRLED and see if I can awaken my old Sony VCR.

    On T4 I ran the IRrecvDump example with IR sensor on pin 11. When I point my Sony remote at sensor and push buttons, T4 is properly decoding Sony IR signals.

    T4 mods look good with the exception of the PORTB errors noted above.
    Last edited by manitou; 01-04-2019 at 11:59 PM.

  17. #442
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,541
    Quote Originally Posted by manitou View Post
    On Teensy 4, i get compile errors
    Oh, opps, you also need this.

    https://github.com/PaulStoffregen/co...0076a605a7a629

  18. #443
    Senior Member xxxajk's Avatar
    Join Date
    Nov 2013
    Location
    Buffalo, NY USA
    Posts
    510
    @PaulStoffregen
    I'm interested in doing some more beta testing, and I see Teensy 4.0 is in the works...
    My contact info hasn't changed. :-)

    Also, I've been working on a non-usb board... KE1xF :-)

  19. #444
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,541
    Welcome back Andrew! Your name is on the list, so just email Robin (like msg #1 says) and we'll send you a beta board.

    For everyone watching this thread, the beta boards are only being made available to people on the list in msg #1. We're going to add more names to the list - people who have a long history of contributing on this forum or who've written important open source libraries. You can't get on the list simply by asking, so please don't send us email asking to be added to the list.

  20. #445
    Senior Member xxxajk's Avatar
    Join Date
    Nov 2013
    Location
    Buffalo, NY USA
    Posts
    510
    @PaulStoffregen
    I've not gone anywhere, just been busy making products for my client.
    Not sure how much time I can dedicate, but I should, at a minimum, be able to do UHS3 support.

  21. #446
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    4,212
    Quote Originally Posted by mjs513 View Post
    @KurtE

    Think the comments are wrong. Been using SCL on pin 19 so 01 and 00 should be swapped in the comment.
    @Paul,
    My guess is the lines in Wire are wrong... That is if we look at the hardware description...
    Code:
    class TwoWire : public Stream
    {
    public:
    	// Hardware description struct
    	typedef struct {
    		volatile uint32_t &clock_gate_register;
    		uint32_t clock_gate_mask;
    		volatile uint32_t &sda_mux_register;
    		volatile uint32_t &scl_mux_register;
    		volatile uint32_t &sda_pad_register;
    		volatile uint32_t &scl_pad_register;
    		volatile uint32_t &sda_input_register;
    		volatile uint32_t &scl_input_register;
    		uint8_t sda_mux_value;
    		uint8_t scl_mux_value;
    		uint8_t sda_input_value;
    		uint8_t scl_input_value;
    		IRQ_NUMBER_t irq;
    	} I2C_Hardware_t;
    And in this case:
    Code:
    constexpr TwoWire::I2C_Hardware_t TwoWire::i2c1_hardware = {
            CCM_CCGR2, CCM_CCGR2_LPI2C1(CCM_CCGR_ON),
    	IOMUXC_SW_MUX_CTL_PAD_GPIO_AD_B1_00, // 18/A4  AD_B1_01  GPIO1.17  I2C1_SDA
    	IOMUXC_SW_MUX_CTL_PAD_GPIO_AD_B1_01, // 19/A5  AD_B1_00  GPIO1.16  I2C1_SCL
    	IOMUXC_SW_PAD_CTL_PAD_GPIO_AD_B1_00,
    	IOMUXC_SW_PAD_CTL_PAD_GPIO_AD_B1_01,
    	IOMUXC_LPI2C1_SDA_SELECT_INPUT,
    	IOMUXC_LPI2C1_SCL_SELECT_INPUT,
    	3 | 0x10,
    	3 | 0x10,
    	1,
    	1,
            IRQ_LPI2C1
    };
    But again if we look at #3 posting
    For lines 18 and 19:
    Code:
    18/A4  AD_B1_01   1.17   2_cts    1_SDA        QT3_1                             3:1     A1:6,A2:6
    19/A5  AD_B1_00   1.16            1_SCL        QT3_0                             3:0     A1:5,A2:5
    And if we look at the definition for B1_01 it is SDA, which matches the comments. So I think the hardware structure should be:
    Code:
    constexpr TwoWire::I2C_Hardware_t TwoWire::i2c1_hardware = {
            CCM_CCGR2, CCM_CCGR2_LPI2C1(CCM_CCGR_ON),
    	IOMUXC_SW_MUX_CTL_PAD_GPIO_AD_B1_01, // 18/A4  AD_B1_01  GPIO1.17  I2C1_SDA
    	IOMUXC_SW_MUX_CTL_PAD_GPIO_AD_B1_00, // 19/A5  AD_B1_00  GPIO1.16  I2C1_SCL
    	IOMUXC_SW_PAD_CTL_PAD_GPIO_AD_B1_01,
    	IOMUXC_SW_PAD_CTL_PAD_GPIO_AD_B1_00,
    	IOMUXC_LPI2C1_SDA_SELECT_INPUT,
    	IOMUXC_LPI2C1_SCL_SELECT_INPUT,
    	3 | 0x10,
    	3 | 0x10,
    	1,
    	1,
            IRQ_LPI2C1
    };
    Again may not make much difference as the init code for both may be the same...

  22. #447
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    2,702
    @PaulStoffregen
    You may have to take off analogwrite after this msg. Here goes, on this page, https://www.pjrc.com/teensy/td_pulse.html, found a nice example with a nice scope picture so I decided to test with those values (50 and 140) as well as 128 with a scope on the pins to see if they matched your example.

    Pins 2 and 3 matched the wave exactly as pictured with the following values I picked off the measure panel:
    Code:
    //value = 40  //pwidth = 43.6us, +duty = 19.5%
    //value = 128 //pwidth =111.6us, +duty = 50%
    //value = 140 //pwidth =122.0us, +duty = 54.7%
    //value = 200 //pwidth =174.3us, +duty = 78.1%
    Now on pins 0/1 got different results:
    Code:
    //value = 40  //pwidth = 188.4us, +duty = 84.4%
    //value = 128 //pwidth =111.6us, +duty = 50%
    //value = 140 //pwidth =101.2us, +duty = 45.3%
    //value = 200 //pwidth =48.8us, +duty = 21.9%
    heres the scope waveforms on pins 0 and 2
    Click image for larger version. 

Name:	aw01pins.png 
Views:	10 
Size:	404.0 KB 
ID:	15498

    It looks like the on pin0/2 the duty and pulse widths are reversed from pins2/3. Not sure what the pulse widths should be. Sketch is pretty simple:
    Code:
    void setup()   {                
      pinMode(2, OUTPUT);
      pinMode(0, OUTPUT);
    }
    
    void loop()                     
    {
      analogWrite(2, 50);  
      delay(500);
      analogWrite(0, 140); 
      delay(500);
    }

  23. #448
    Senior Member
    Join Date
    Jul 2014
    Posts
    2,055
    Quote Originally Posted by WMXZ View Post
    I stumbled over the following issue
    based on post https://forum.pjrc.com/threads/54711...l=1#post194344
    I tried to generalize further and found that the program only works for DMA channel 0

    Any attempt to use another channel (e.g. 1) generates nonsense
    In particular, the DADDR used inside the DMA-isr to know where the DMA is actual writing to, is not correct (even outside the destination array!)
    SOLVED
    (at least it seems so)
    using two dma channels (i2s_input, i2s_output) I got it working

    Conclusion: using dma channel 1, requires also dma channel 0.

    It seems that one cannot use any arbitrary dma channel, but only consecutive ones starting from zero.

  24. #449
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    2,702
    ANALOGWRITE FREQUENCY TEST

    Tested analogwritefrequency mainly because I was curious on pin 0 and pin 2 (see post #447), can confirm that analogwritefrequency works. Here is some data:
    Code:
     PIN 2
    100 = 100hz
    150 = 149.9/150.1 hz
    5000 = 5.000khz
    15000 = 14.97khz
    20000 = 20.00khz
    50000 = 50.00khz
    100000 = 100.00khz
    1Mhz = 1.000Mhz
    1.5Mhz = 1.5Mhz  but seeing spikes on rising and falling edges
    3.0Mhz = 2.996/3.007 Mhz, spikes on rising and falling edges
    
    PIN 0
    1000 = 1.000hz
    10000 = 10.00khz
    100000 = 100.0khz but seeing spikes on rising and falling
    1000000 = 1.00mhz spikes nice and steady
    3500000 = 3.478mhz spikes, more oscillation in signal on flat top/bottom

  25. #450
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,436
    Quote Originally Posted by Frank B View Post
    ok no problem - how can I tell the compiler to use OCRAM for this array? It was not my intention to use DTCM anyway. I thought DMAMEM is OCRAM.
    ok, answering myself i just use malloc

Posting Permissions

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