Teensy 4.0 First Beta Test

Status
Not open for further replies.
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.
 
.bss.dma : { *(.dmabuffers) . = ALIGN(16); } > RAM

but dmabuffers is ocram.. looks like the linker is not doing what we think it does :)
 
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-Teensy-4-0-First-Beta-Test?p=194356&viewfull=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:
@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
 
I've ported IRremote. Here's the modified code if anyone wants to try before beta7.
 

Attachments

  • boarddefs.h
    23.2 KB · Views: 95
  • irRecv.cpp
    6.5 KB · Views: 133
@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.
 
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.
 
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..


Frank - please email me this code, if you still have it.

Anything that requires the 13 second recovery is my highest priority!
 
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.
 
Just ordered one - real inexpensive. Should get it on Sunday and will give it a test if no one else gives it a try.
 
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.
 
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?
 
@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.
 
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:
@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 :)
 
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.
 
@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.
 
@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...
 
@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
aw01pins.png

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);
}
 
I stumbled over the following issue
based on post https://forum.pjrc.com/threads/54711-Teensy-4-0-First-Beta-Test?p=194344&viewfull=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.
 
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:
 [B]PIN 2[/B]
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

[B]PIN 0[/B]
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
 
Status
Not open for further replies.
Back
Top