Teensy 4.0 First Beta Test

Status
Not open for further replies.
@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?
 
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/master/ENC1_test_xbar1

I also successfully tested the T4 sketch with an encoder simulator running on T3.2 (btot 0, freq 100).
 
Last edited:
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...
 

Attachments

  • flex_uart_test-190123a.zip
    6 KB · Views: 78
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
 
How do I do that?

startup.c :
Code:
extern unsigned long _ebss;


__attribute__ ((used, aligned(1024), [B][COLOR=#ffa500]section(".fastrun")[/COLOR][/B]))
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 ;)
 
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
 
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?
 
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/master/ENC1_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.
 
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 :D
 
}
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
 
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 :D

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.
 
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
 
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.
 
@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.
 
@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.
 
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:
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 ...

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:
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.
 
XBEE - RADIOHEAD LIBRARIES STATUS
@Paul and others (updating first page for library testing):

Code:
works               XBEE        see post [URL="https://forum.pjrc.com/threads/54711-Teensy-4-0-First-Beta-Test?p=195088&viewfull=1#post195088"]#674[/URL],  tested with Series1
works w/caveats     RadioHead   see post [URL="https://forum.pjrc.com/threads/54711-Teensy-4-0-First-Beta-Test?p=196124&viewfull=1#post196124"]#1032[/URL]

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?
 
XBEE - RADIOHEAD LIBRARIES STATUS
@Paul and others (updating first page for library testing):

Code:
works               XBEE        see post [URL="https://forum.pjrc.com/threads/54711-Teensy-4-0-First-Beta-Test?p=195088&viewfull=1#post195088"]#674[/URL],  tested with Series1
works w/caveats     RadioHead   see post [URL="https://forum.pjrc.com/threads/54711-Teensy-4-0-First-Beta-Test?p=196124&viewfull=1#post196124"]#1032[/URL]

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 :eek:

Now does not hang, does show stuff no going to the RX pin for this, but no response yet... Debugging!
 
Last edited:
Status
Not open for further replies.
Back
Top