Teensy 4.0 First Beta Test

defragster · Jan 21, 2019

Fun and Fear of adding in debug code when things are bad .... Hooked up Serial#4 and enabled debug code - doesn't fault now with the Speed @800 MHz. Forced a fault with invalid write to GPT :: GPT1_CNT = 5;

I can get the temp out once ( to USB Serial! ) in the fault handler - then it won't print. Using debug's printf there causes RESET and restart of MCU.

This is with the weak override to a sketch local :: extern "C" void unused_interrupt_vector(void)

Decided to have setup do replacement for debug serial4 hardcode ... :: Serial4.begin( 115200); - now it won't make it back to the fault code ... locks up somewhere silently ... or auto restarts or something bad ...

So work to do to find a stable path out ... LOOK a Squirrel! ... Nope ... looks like I found a new rabbit hole ...

If I call out to my sketch from unused_interrupt_vector() - I can flash the LED and print the temp too ... I got this far showing temp dropping in fault handler::

>>> 1ms systick :micros() >>> Clock Speed is:804000000 øC=44.63
deg C= 44.626167
deg C= 40.046730
deg C= 39.392525

So there you have it Mike - and @xxxajk

- temp printed in Celsius on fault - showing it dropping with CPU speed drop. This was a short test so MCU didn't fully heat before I forced the fault. And even though I can Serial USB print - the T4 won't see bootloader request without a button ...

BTW - this does show on Serial4 before I make things ugly::

at 600 MHz :: Increasing voltage to 1250 mV
at 800 MHz :: Increasing voltage to 1300 mV
at 100 MHz :: Decreasing voltage to 1150 mV

And my IR thermometer does have °C button - but those numbers are so much less dramatic as well as contextually meaningless

manitou said:
FWIW, my digital meter thermometer probe touching the 1052 chip reads 10 degrees F lower than what tempmon reports. I haven't checked the EVKB board.

scanning the surface of the MCU I can get 31.4 °C and software reports 38.08 - not surprising the heat is localized and spotty until it hits the chip cover.
<edit:> sitting a bit ... I scan 25.7 to 30.3 C but software now shows 37.42 or 38.08

PaulStoffregen · Jan 21, 2019

manitou said:
you need to copy teensy3/IPAddress.cpp to teensy4/

Done
https://github.com/PaulStoffregen/cores/commit/6182e0f4ae92d3f7542c9b1b0a3c55f759d34494

PaulStoffregen · Jan 21, 2019

KurtE said:
Hi Paul - Not needed for T4, but might at some point pull in
https://github.com/PaulStoffregen/USBHost_t36/pull/23

Done.

As related question - Have you looked at doing USB Host stuff on this board? And if so how much different is it than T3.6.

Haven't done anything on this... but all those breakboard boards I sent a couple weeks ago have 2 pogo pin and a USB host connector, in anticipation of working on this soonish....

The EHCI controller appears to be identical to Teensy 3.6, but with slightly different register names. Was going to make a header in a "utility" folder (so it doesn't match includes from outside the library) which just translates the new names to the names already in the code.

The USB PHY looks a little different, seems like fewer features in the new chip, but otherwise pretty much the same hardware.

PaulStoffregen · Jan 21, 2019

KurtE said:
Follow up on SoftwareSerial.
....
Question is why?

Several old & probably no longer maintained Arduino libraries have hard-coded dependency on SoftwareSerial. Most of these were written back in the days when Arduino Duemilanove & Mega were the only Arduino products, and they only tested on the more popular Duemilanove where SoftwareSerial was the only way to talk to whatever serial hardware the library uses.

For any new projects, obviously real hardware serial is much better. These days, Adafruit and others (many copy whatever Adafruit does) are defaulting to "Serial" but offering a constructor or begin() function to let any other stream be used. Hard-coding an absolute dependency on SoftwareSerial isn't done anymore, except when people copy those ancient libs and make only superficial changes.

However, for those very old libs, people can't just use real serial. Those very old libraries have "SoftwareSerial" pointers or references hard-coded. Nobody is ever going to update that very old code. The main reason we have a SoftwareSerial which just uses real hardware serial is to give users who have whatever old shields or special hardware (some are serial interface LCDs) a way to use those ancient libraries. Editing the pin numbers is something most people are comfortable doing, but editing the library code isn't.

KurtE · Jan 21, 2019

FLEXIO - Playing with Serial Transmit, plus some general stuff

That I would try it out. Started off with data shown in UART Transmit setup shown on page 2732.

I created struct for all of the FLexIO registers, started a class that I can ask to map IO pin to which Flexio object... Then try to create a transmitter using pin 2...

Still very much WIP, but showing me more things needed in the structures, like the Clocks need to be enabled, like how to map each pin to FlexIO mode, ...

But it is outputting one character at a time...

Again just an experiment:

Also found the Macros for defining the different fields for the registers were setup to only output 16 bits of data, so upper words of registers were not updated. So updated, and did PR: https://github.com/PaulStoffregen/cores/pull/339

defragster · Jan 21, 2019

When I did the Pull to drop Speed - I almost thought I should have put it before the register dump ... just tried that ... FYI this may be a 3 dimensional rabbit hole?

When I moved the speed drop up - it failed to take effect - where I put it worked!

So the speed maintains at 800 MHz ... last temp in sketch was :: C=50.51

On entering the fault code it shows: deg C= 50.514019 , 51.822430, 51.822430, 51.822430, 51.822430, 52.476635, 52.476635, 52.476635, 53.130840

the printing HALTED for a bit in there ( i.e. 3D rabbit hole ? ) - and I lost the isr REG dump ... but it came back for other printing ... and my sketch void userDebugDump() {...} got control and after counting a bit to let that temp peak I again issued: set_arm_clock(100000000);

PJRC Serial4 properly shows: Decreasing voltage to 1150 mV

And further temp printing then shows ... deg C= 52.476635, ..., 42.663551, 40.700935, ..., 39.392525, 38.738319, 38.738319, 38.084110, ... 37.42

Since 800 MHz isn't causing this fault anymore I just left it at 600 MHz and rising from 41.35 the peak reported temp after Fault is 45.28 at 600 MHz before dropping to 38.73 ... 38.08 ... 37.42 at 100 MHz

That is a 15 degree C temp drop ... from the OC 800 MHz state - and 7.5+ C at 600 MHz ...

So bottom line ... that was a good change to let the MCU cool when it Faults - rather than heat up unattended in a while(1);. I'll see if I can get Serial#'s to work in my sketch void userDebugDump() after a Fault.

I hope this debug quest is just a rabbit hole and there isn't a minotaur nearby ... PJRC changes to USB Serial will tell ... and if I can see Serial#'s [ not #4 work ] time for a 2nd debug Teensy ...

Note: I see 200 MHz uses the same 1150 mV - not sure if that helps anything?

Removed some edits - isr REG dump is back . . . will start from here.

Frank B · Jan 21, 2019

Ili9341: We probably need different libraries for the different strategies to update. Having all in one slows down things and is optimal for nothing.
Dirty areas can be fast in some scenarios - in others way slower. Think of diagonal lines or triangles as worst case - and screen updates in between.
The "old" way is good for some other cases. Always fullscreen is good if you just want to draw and forget - if it allows to reach good refresh rates - if not, not

Not that easy with SPI and larger displays.
I dont think there is a the one best way. I'll probably add a manual dirty area which has to be defined by the user.

So, no reset? Why not?
There are several other while(1); loops in the core. At least handle them too. Leaving the timers and more running is not a good idea - you dont know what user- hardware does if clock signals and pins outputs are still active, but the program that controls the whole thing is halted.. can be dangerous. NXP had a reason to add a reset to the tempmon... and the same reason is valid for a halted program.

Frank B · Jan 21, 2019

Paul, do you plan any important changes to audio stream? Otherwise I'd start trying to make outputs/inputs..
I'll upload my ili-lib tonight and pause it until I know where's the trip going. I can't give much support for it anyway, longterm, so Kurt's lib may be better for general purpose usage. Mine will ever be speed-optimized and more special.
Edit: One Day, I'll see demos running, and ported PC games and software

With Arduino, not linux. Does this make sense? No.. but it's fun, and that's because it's my hobby

Would be really great if we could use the GPU on a future T4.2 .. would make everything graphics-related so much better..

defragster · Jan 22, 2019

Frank B said:
...
So, no reset? Why not?
There are several other while(1); loops in the core. At least handle them too. Leaving the timers and more running is not a good idea - you dont know what user- hardware does if clock signals and pins outputs are still active, but the program that controls the whole thing is halted.. can be dangerous. NXP had a reason to add a reset to the tempmon... and the same reason is valid for a halted program.

Frank - is this about the speed reduction code in the fault loop?

Assuming that is the case ... I was just going with T_3.x standard - which right now is in beta mode where fault is displayed with spaz blinking and suspected faulting MCU could get hot. As it is the user can decide now that can be user controlled :: __attribute__((weak)) void unused_interrupt_vector() , this is how the T_3.x works as well and how I started doing the debug_t3.

Additionally once I got in and found what can work - the T_3.x was very forgiving doing USB I/O stuff in the Faulted condition ... I'm hoping the T4 can get to the same place when new USB Serial is updated and Paul figures out the "// keep polling some communication while in fault mode, so we don't completely die."

Right now I got a step forward printing to Serial1() - found only half lines printed until the next line - I tried the private IRQHandler and it didn't help - so I enabled interrupts and the lines printed at once ... then I did something else and now I need to back up and see what I need to UNDO as it is stuck in FaultFastBlink again.

>> I was going to propose that in the end something along these lines:

Code:

__attribute__((weak))
void End_User_Code_On_Fault(void)
{ 
  // End user can replace with reset or ... TBD
  // perhaps sample min shutdown or restart
	while (1) {
		// 
	}
|

__attribute__((weak))
void unused_interrupt_vector(void)
{
	if ( F_CPU_ACTUAL >= 600000000 )
		set_arm_clock(100000000);
        End_User_Code_On_Fault();
}

But so far each attempt to drill down results in repeat faults or spontaneous restart loops - so far it seems when something is wrong auto restart could do more hard than good. This code is purposefully faulting (a simple unapproved write) at the start of loop() - but it isn't well handled.

Frank B · Jan 22, 2019

Oh I wrote about this issue years ago. Got ignored. This does not mean the standard is good. Now we have the chance to make it better

I'd reset the imxrt and after reset init just USB and switch to a slow frequency well below 100mhz and sleep somehow. for temp-panic reset and all the while(1) loops it can be the same. Maybe we can add an offical exit().

defragster · Jan 22, 2019

Frank B said:
Oh I wrote about this issue years ago. Got ignored. This does not mean the standard is good. Now we have the chance to make it better I'd reset the imxrt and after reset init just USB and switch to a slow frequency well below 100mhz and sleep somehow.

Ok - that is more and better than just 'reset'. Seems like the speed drop is the first step to go that direction - and the weak fault handler goes toward 'user choice'.

The user can do that on the T_3.x - well I could

- and could also ideally do that on T4 before beta is done. I didn't see the 'resetReason' code for T4 yet - but I included it in the debug_t3 startup code where the weak fault code was hooked..

I already did a test of 'wfi' - sleepCPU() - and it wasn't clear ... first the line before it printed about 20 times - then a small edit and I don't know that it worked so will revisit it.

Frank B · Jan 22, 2019

Sure, the user can do it. Or a library. Would be perfect if there were some early hooks - before and after USB init. Setup() is too late - all objects get initialized before Setup().

Edit:
But without library, as a standard, it would be 100x better.

defragster · Jan 22, 2019

DOH*opps - my code stopped getting called because "C" got deleted from my Extern ... back now [in the line below] - I even edited the open print line to show me when my func() was being called ... that is the DOH part - that is the problem with three SerMon/TyComm windows open : USB, Teensy on Ser4 and Ser1 ...

All that is needed is to replace the weak hooks - like T_3.x and Paul just took in my micros() request and library or not - I'm doing it now in a sketch - like the debug_t3 did:

Code:

extern "C" void unused_interrupt_vector(void)
{

And the build process sends all faults/unused _isr's to that function. Yes, depending on what is needed/can be done being in setup() may not be enough - but at that point all you can do it find out why it faulted and report that and halt? The code can't be changed ... unless it was a try/reset/try type of deal ?... but those things can all be resolved hopefully. T_3.x had 'startup_early_hook' that I don't see in place for T4 by name at least or a quick scan of startup.c.

<edit>: some progress - I can't call my DUMP func? Maybe that was why I tried it as non "C"?
I can get temp and micros() - (the important stuff) - micros is stalled as the systick isn't running - but it tracks the CycCnt until it wraps - ...
>> So that means this elapsedMicros emSysTick keeps the clock running - thanks CycCnt! :: if ( emSysTick > 1000 ) { systick_isr(); emSysTick -= 1000; }
Was feeling slow at 100 MHz - at least to Serial. It seemed __enable_irq(); helped Serial1 before - not seeing that now. Will try input - just doing a cyclic blink loop - and printing temp 40.7 °C at 300 MHz.
Slowness probably from having a busy loop based delay() simulation - I can use elapsedMicros() for blink without delay.
When I get a decent sample [ and see what .read() does ] I'll ask Kurt - prints 13 chars and stops mid output - until the next one of two lines kicks it out and repeats up to the same point or advanced a char or two over time?

manitou · Jan 22, 2019

KurtE said:
FLEXIO - Playing with Serial Transmit, plus some general stuff

FWIW, the NXP SDK has several flexio examples

Code:

./boards/evkbimxrt1050/driver_examples/flexio/spi/edma_lpspi_transfer/master/readme.txt
./boards/evkbimxrt1050/driver_examples/flexio/spi/edma_lpspi_transfer/slave/readme.txt
./boards/evkbimxrt1050/driver_examples/flexio/spi/int_lpspi_transfer/master/readme.txt
./boards/evkbimxrt1050/driver_examples/flexio/spi/int_lpspi_transfer/slave/readme.txt
./boards/evkbimxrt1050/driver_examples/flexio/i2s/interrupt_transfer/readme.txt
./boards/evkbimxrt1050/driver_examples/flexio/i2s/edma_transfer/readme.txt
./boards/evkbimxrt1050/driver_examples/flexio/uart/interrupt_transfer/readme.txt
./boards/evkbimxrt1050/driver_examples/flexio/uart/int_rb_transfer/readme.txt
./boards/evkbimxrt1050/driver_examples/flexio/uart/edma_transfer/readme.txt
./boards/evkbimxrt1050/driver_examples/flexio/uart/polling_transfer/readme.txt
./boards/evkbimxrt1050/driver_examples/flexio/pwm/readme.txt
./boards/evkbimxrt1050/driver_examples/flexio/i2c/read_accel_value_transfer/readme.txt
./boards/evkbimxrt1050/driver_examples/flexio/i2c/interrupt_lpi2c_transfer/readme.txt

KurtE · Jan 22, 2019

Good Morning everyone... Now quick comments on a few things since my last posting...

ili9341_t4 or such - @Paul @Frank - As I sort of mentioned in previous postings, I also am not sure of best usage patterns. Having more memory and more CPU speeds gives more options. Not sure yet if there is one that is best.

Example double buffering - probably great if you are doing something like video, where you have external something which fills in full frames, so you fill the frame, tell the system to use it, and then start filling other frame... Then switch.... However if you are doing only partial frame updates, like draw a few frames or lines, or text... Then when you wish to switch buffers, you need to somehow synchronize the data between the two buffers...

Automatic updates on timer - Not sure yet of usage pattern - I think I still prefer something with more user control, like beginTransaction/endTransaction or update me now functions, as again if my code does text updates like: fillScreen(BLACK), draw new sets of text, ... Then system may choose to update the screen during the time at least part of the display is black and the wait awhile before showing new text, so it introduces flicker...

Will try out a few more things with my _t3n version, like trying to relax the requirement for hardware CS pin for DC and see how much it impacts the performance.

Currently I don't keep a bounding rectangle for updates to limit how much gets updated during a screen update, For the non-dma version I do have a mode in place that if you have setup a clip rectangle, only the area within the clip rectangle will be updated on the screen, so that part is in place, I did not yet do this for the DMA updates, as it would take more DMA memory trickery to do. Probably doable, but the issue was how to setup the DMA Settings, such that after I output color word for example for columns: 100-200 in in the first row to output to increment the word address to column 100 to the next row to output

...

USB Host - @Paul, I will play along once you hopefully get some of the initial pieces into place.

SoftwareSerial - @Paul - I understand the need to have a version that at least limps along, which is what the T3.x did with at least allowing you to map it th hardware ports... Question is - Should we extend it's mapping to all 8 Serial ports on T4 and/or to the other Serial ports on T3.5/T3.6 while at it.

And assuming we get a FlexIO version working - Should we update this library as well as AltSerial... to map the users code to any possible pins that will work there as well...

FLEX IO Again lots more to do, Will be interesting to see if I get something reasonable to setup and use and if so, should it all be part of a library and/or parts of it part of core... Sort of the same issues with things like DMAChannels. That is if I wish to use 3 Flex Serial objects and a Flex SPI object, who manages, which timers, buffers, ... get used, Who routes the interrupts to code to handle it...

But first need to get more of this working!

Edit: @manitou - Question is how to get hold of these examples? Are they generically setup or like the descriptions in the PDF that for example assumes pin 0 (Flex pin 0 of the device not IO pin), timer 0, ... And how much other library support is there for these.

mjs513 · Jan 22, 2019

SoftwareSerial - @Paul - I understand the need to have a version that at least limps along, which is what the T3.x did with at least allowing you to map it th hardware ports... Question is - Should we extend it's mapping to all 8 Serial ports on T4 and/or to the other Serial ports on T3.5/T3.6 while at it.

Morning Kurt,
Already extended Softserial for all 8 ports for the T4 in the pull request. So that piece is already there - couldn't resist as long as I was updating it. Paul already incorporated the software pull request incorporating all 8.
Mike

KurtE · Jan 22, 2019

mjs513 said:
Morning Kurt,
Already extended Softserial for all 8 ports for the T4 in the pull request. So that piece is already there - couldn't resist as long as I was updating it. Paul already incorporated the software pull request incorporating all 8.
Mike

Great!

Still having fun playing with the FLEX IO stuff - Things like, I created structure with all of their registers, maybe at some point (soon?) maybe add to imxrt.h?

Code:

typedef struct {
	const 	uint32_t VERID;				// 0x00	(IMXRT_FLEXIO1.offset000)
	volatile uint32_t PARAM;			// 0x04	// (IMXRT_FLEXIO1.offset004)
	volatile uint32_t CTRL;				// 0x08(IMXRT_FLEXIO1.offset008)
	volatile uint32_t PIN;				// 0x0c (IMXRT_FLEXIO1.offset00C)
	volatile uint32_t SHIFTSTAT;		// 0x10 (IMXRT_FLEXIO1.offset010)
	volatile uint32_t SHIFTERR;			// 0x14(IMXRT_FLEXIO1.offset014)
	volatile uint32_t TIMSTAT;			// 0x18 (IMXRT_FLEXIO1.offset018)
	const	uint32_t UNUSED0;			// 0x1c
	volatile uint32_t SHIFTSIEN;		// 0x20 (IMXRT_FLEXIO1.offset020)
	volatile uint32_t SHIFTEIEN;		// 0x24 (IMXRT_FLEXIO1.offset024)
	volatile uint32_t TIMIEN;			// 0x28 (IMXRT_FLEXIO1.offset028)
	const	uint32_t UNUSED1;			// 0x2c
	volatile uint32_t SHIFTSDEN;		// 0x30 (IMXRT_FLEXIO1.offset030)
	const	uint32_t UNUSED2[3];		// 0x34 38 3C
	volatile uint32_t SHIFTSTATE;		// 0x40 (IMXRT_FLEXIO1.offset040)
	const	uint32_t UNUSED3[15];		// 0x44..  50... 60... 70...
	volatile uint32_t SHIFTCTL[4];		// 0x80 84 88 8C
	const	uint32_t UNUSED4[28];		// 0x90 - 0xfc
	volatile uint32_t SHIFTCFG[4];		// 0x100 104 108 10C (IMXRT_FLEXIO1.offset100)
	const	uint32_t UNUSED5[60];		// 0x110 - 0x1FC
	volatile uint32_t SHIFTBUF[4];		// 0x200 204 208 20c (IMXRT_FLEXIO1.offset200)
	const	uint32_t UNUSED6[28];		// 
	volatile uint32_t SHIFTBUFBIS[4];	// 0x280	// (IMXRT_FLEXIO1.offset280)
	const	uint32_t UNUSED7[28];		// 
	volatile uint32_t SHIFTBUFBYS[4];	// 0x300 (IMXRT_FLEXIO1.offset300)
	const	uint32_t UNUSED8[28];		// 
	volatile uint32_t SHIFTBUFBBS[4];	// 0x380 (IMXRT_FLEXIO1.offset380)
	const	uint32_t UNUSED9[28];		// 
	volatile uint32_t TIMCTL[4];		// 0x400 
	const	uint32_t UNUSED10[28];		// 
	volatile uint32_t TIMCFG[4];		// 0x480
	const	uint32_t UNUSED11[28];		// 
	volatile uint32_t TIMCMP[4];		// 0x500
	const	uint32_t UNUSED12[28+64];	// 
	volatile uint32_t SHIFTBUFNBS[4];	// 0x680
	const	uint32_t UNUSED13[28];		// 
	volatile uint32_t SHIFTBUFHWS[4];	// 0x700
	const	uint32_t UNUSED14[28];		// 
	volatile uint32_t SHIFTBUFNIS[4];	// 0x780
} IMXRT_FLEXIO_t;

I believe all of the offsets for the data members is correct. My test app printed out the address of SHIFTBUFNIS[0] from a pointer initialized to 0...

At times wondering if there are other ways in current c/c++ to set the members offset within a struct?

Also may want to at some point add some more #defines or enums or... for some of the fields and need to move more into my underlying class stuff:
Example in the current init code, which includes:

Code:

  pflex = FlexIOHandler::mapIOPinToFlexIOHandler(2, flex_pin);
  Serial.printf("pin 2 maps to: %x, port: %x pin %x\n", (uint32_t)pflex, (uint32_t)pflex->port(), flex_pin);
  transmit_timer = pflex->requestTimers();
  transmit_shifter = pflex->requestShifters();

  transmit_shifter_mask = 1;
  for (uint8_t i = transmit_shifter; i > 0; i++) transmit_shifter_mask <<= 1;

  Serial.printf("timer index: %d shifter index: %d mask: %x\n", transmit_timer, transmit_shifter, transmit_shifter_mask);

  // lets try to configure a tranmitter like example
  Serial.println("Enable flexio clock");
  CCM_CCGR5 |= CCM_CCGR5_FLEXIO1(CCM_CCGR_ON);
  p = pflex->port();
  Serial.println("Before configure flexio");
  p->SHIFTCFG[transmit_shifter] = FLEXIO_SHIFTCFG_SSTOP(3) | FLEXIO_SHIFTCFG_SSTART(2); //0x0000_0032;
  p->SHIFTCTL[transmit_shifter] = FLEXIO_SHIFTCTL_PINCFG(3) | FLEXIO_SHIFTCTL_SMOD(2) |
                                  FLEXIO_SHIFTCTL_TIMSEL(transmit_timer) | FLEXIO_SHIFTCTL_PINSEL(flex_pin); // 0x0003_0002;
  p->TIMCMP[transmit_timer] = 0xF01; //0x0000_0F01;		//
  p->TIMCFG[transmit_timer] = FLEXIO_TIMCFG_TSTART | FLEXIO_TIMCFG_TSTOP(2) |
                              FLEXIO_TIMCFG_TIMENA(2) |  FLEXIO_TIMCFG_TIMDIS(2); //0x0000_2222;
  p->TIMCTL[transmit_timer] = FLEXIO_TIMCTL_TIMOD(1) | FLEXIO_TIMCTL_TRGPOL | FLEXIO_TIMCTL_TRGSRC
                              | FLEXIO_TIMCTL_TRGSEL(1) | FLEXIO_TIMCTL_PINSEL(flex_pin);  // 0x01C0_0001;
  p->CTRL = FLEXIO_CTRL_FLEXEN;
  //p->SHIFTSTAT = transmit_shifter_mask;   // Clear out the status.

  // Set the IO pin into FLEXIO mode
  *(portConfigRegister(2)) = 0x14;

I need/want to move the clock setting into class defines, need to setup the port config register settings for each of the pins into the class...

As for defines example would like to put in something for FLEXIO_SHIFTCTL_PINCFG(3) as for the description 3=OUTPUT...

...

So far this morning now played with SHIFTSTAT to know when I can output a character... So main loop looks like:

Code:

uint8_t loop_char = 'a';
void loop() {
  IMXRT_FLEXIO_t *p = pflex->port();
  digitalWrite(13, !digitalRead(13));
  for (loop_char = 'a'; loop_char <= 'z'; loop_char++) {
  	while (!(p->SHIFTSTAT & transmit_shifter_mask)) ; // wait until it says there is room for next output
    p->SHIFTBUF[transmit_shifter] = loop_char;  // put the next byte out
  }
  delay(500);

}

And the a-z are being output... Probably next try out using Interrupt. Also move some of the stuff I mentioned into my underlying class.

And then figure out how baud rate is setup and make it right and configurable. Currently by the Autobaud setting in Logic Analyzer it looks like it is outputting at a baud rate of 7575757...

Edit: Forgot to mention, for anyone looking at FlexIO with current beta. The pin table shows FlexIO pins on Flex1 Flex2 and Flex3 example: pin 14 shows 3:2 - The IMXRT1050 only has two flex units so the 3:n values will only be available on the 1062 version.

manitou · Jan 22, 2019

KurtE said:
Edit: @manitou - Question is how to get hold of these examples? Are they generically setup or like the descriptions in the PDF that for example assumes pin 0 (Flex pin 0 of the device not IO pin), timer 0, ... And how much other library support is there for these.

To fetch an SDK zip file you need to set up an account at NXP.
https://mcuxpresso.nxp.com/en/welcome
Then select board for SDK download, then select to add additional middleware (to get more examples in the SDK), then download. The SDK contains working examples for the 1050 (or 1060), but you could just use SDK to browse. There is a learning curve, the examples utilize a driver layer with include files defining registers and fields, but if you drill down you can see how they init the device, setup ISRs or DMA, and read/write data. The particular ports used are specific to the NXP eval board, but you'd see the specific GPIO registers being used ...

Frank B · Jan 22, 2019

KurtE said:
fillScreen(BLACK), draw new sets of text, ... Then system may choose to update the screen during the time at least part of the display is black and the wait awhile before showing new text, so it introduces flicker...

Kurt, if you do it this way, you WANT it to flicker. Anyone who only thinks a little bit, uses a manual refresh, or just doesn't do so many updates in a short time and overwrites the same pixels over and over again that it flickers. Children learn this at school. That doesn't make any sense at all to work close to the refresh rate (this flickers the same with the other techniques, by the way).
Kurt, I don't know how many times we've had this discussion in the past, I'm tired of it - the first time I explained it to you was when I introduced the DMA library. And, btw, it already had that posibility to do it manual- I suggest we turn to other topics. I won't waste any more time on this discussion. I do other things now, a part from this thread and forum and come back when I have some things fixed or some audio working. I'm tired.

mjs513 · Jan 22, 2019

manitou said:
To fetch an SDK zip file you need to set up an account at NXP.
https://mcuxpresso.nxp.com/en/welcome
Then select board for SDK download, then select to add additional middleware (to get more examples in the SDK), then download. The SDK contains working examples for the 1050 (or 1060), but you could just use SDK to browse. There is a learning curve, the examples utilize a driver layer with include files defining registers and fields, but if you drill down you can see how they init the device, setup ISRs or DMA, and read/write data. The particular ports used are specific to the NXP eval board, but you'd see the specific GPIO registers being used ...

Just to add a little more to what @manitou said:
1. the pin configs are in the pins_mux files in the board directory along with all the clock functions
2. the MIMXRT1052.h file has 99% of the registers, masks, shifts etc that you need in the device directory.
3. the drivers for the examples are always in the drivers directory, obviously.

xxxajk · Jan 22, 2019

defragster said:
DOH*opps - my code stopped getting called because "C" got deleted from my Extern ... back now [in the line below] - I even edited the open print line to show me when my func() was being called ... that is the DOH part - that is the problem with three SerMon/TyComm windows open : USB, Teensy on Ser4 and Ser1 ...

All that is needed is to replace the weak hooks - like T_3.x and Paul just took in my micros() request and library or not - I'm doing it now in a sketch - like the debug_t3 did:

Code:

extern "C" void unused_interrupt_vector(void) {

And the build process sends all faults/unused _isr's to that function. Yes, depending on what is needed/can be done being in setup() may not be enough - but at that point all you can do it find out why it faulted and report that and halt? The code can't be changed ... unless it was a try/reset/try type of deal ?... but those things can all be resolved hopefully. T_3.x had 'startup_early_hook' that I don't see in place for T4 by name at least or a quick scan of startup.c.

<edit>: some progress - I can't call my DUMP func? Maybe that was why I tried it as non "C"?
I can get temp and micros() - (the important stuff) - micros is stalled as the systick isn't running - but it tracks the CycCnt until it wraps - ...
>> So that means this elapsedMicros emSysTick keeps the clock running - thanks CycCnt! :: if ( emSysTick > 1000 ) { systick_isr(); emSysTick -= 1000; }
Was feeling slow at 100 MHz - at least to Serial. It seemed __enable_irq(); helped Serial1 before - not seeing that now. Will try input - just doing a cyclic blink loop - and printing temp 40.7 °C at 300 MHz.
Slowness probably from having a busy loop based delay() simulation - I can use elapsedMicros() for blink without delay.
When I get a decent sample [ and see what .read() does ] I'll ask Kurt - prints 13 chars and stops mid output - until the next one of two lines kicks it out and repeats up to the same point or advanced a char or two over time?

Have you tried the following to reduce temp and power consumption instead?

Code:

while(1) __asm__ volatile ("wfi");

That will put the cpu core to sleep, but allow it to do anything important, which will only be interrupts.

mjs513 · Jan 22, 2019

XBARA1 - ENCODER, MORE TESTING
Failing on Pin 0 reassignment

In previous posts I tested pin sets 2/3, 3/4 and 6/7 which worked with the encoder example I posted no problem. But pin pair 0/1 was not working properly so today I decided to pin pair 1/2 just to see if it was pin 0 or 1 or both was an issue on configuration and assignment.

Results were as follows;
1. pin pair 1/2 worked with out an problem as it should be working
2. pin pair 0/2 did not work out like it should be working.

Conclusion: something flaky with pin 0 reassignment, was checking to see if there a issue with pin assignment to mux but didn't see anything, but may have missed something obvious.

KurtE · Jan 22, 2019

Frank B said:
Kurt, if you do it this way, you WANT it to flicker. Anyone who only thinks a little bit, uses a manual refresh, or just doesn't do so many updates in a short time and overwrites the same pixels over and over again that it flickers. Children learn this at school. That doesn't make any sense at all to work close to the refresh rate (this flickers the same with the other techniques, by the way).
Kurt, I don't know how many times we've had this discussion in the past, I'm tired of it - the first time I explained it to you was when I introduced the DMA library. And, btw, it already had that posibility to do it manual- I suggest we turn to other topics. I won't waste any more time on this discussion. I do other things now, a part from this thread and forum and come back when I have some things fixed or some audio working. I'm tired.

Sorry Frank, I thought I was agreeing with you

in saying that

li9341: We probably need different libraries for the different strategies to update. Having all in one slows down things and is optimal for nothing..

I am not advocating necessarily working this way... Yes I understand about ways to avoid the flicker. And I have written code to do so...

BUT: I do see lots of posts from people who complain about flicker... Examples: are things like suppose with ili9341_t3 library you wish to draw a field, using a text font (not default font). The current released code does not support Opaque writes, so how do you update that field. Currently the main way people do this is to fillRect back to background color and then draw new text....

Which by the way is why in my _t3n library I have implementation for opaque font character output support to avoid this...

So again sorry, and yes I am now also off on something else.

KurtE · Jan 22, 2019

mjs513 said:
XBARA1 - ENCODER, MORE TESTING
Failing on Pin 0 reassignment

In previous posts I tested pin sets 2/3, 3/4 and 6/7 which worked with the encoder example I posted no problem. But pin pair 0/1 was not working properly so today I decided to pin pair 1/2 just to see if it was pin 0 or 1 or both was an issue on configuration and assignment.

Results were as follows;
1. pin pair 1/2 worked with out an problem as it should be working
2. pin pair 0/2 did not work out like it should be working.

Conclusion: something flaky with pin 0 reassignment, was checking to see if there a issue with pin assignment to mux but didn't see anything, but may have missed something obvious.

Hi Mike do you have an example code setup with this... Again others may see the stuff better than I would but could again try to take look...

mjs513 · Jan 22, 2019

KurtE said:
Hi Mike do you have an example code setup with this... Again others may see the stuff better than I would but could again try to take look...

Yep, here is the example for using pin 0 and pin 1 (just the setup part):

Code:

#include "Enc_Layer.h"
#include "defines.h"

enc_config_t mEncConfigStruct;
uint32_t mCurPosValue;

void setup()
{
  while(!Serial && millis() < 4000);
  delay(2000);

  CCM_CCGR2 |= CCM_CCGR2_XBAR1(CCM_CCGR_ON);   //turn clock on for xbara1

  CORE_PIN0_CONFIG = 0x01;  //Select mux mode: ALT3 mux port for pins 2/3
                            // 0x01 for pins 0 or 1
  CORE_PIN2_CONFIG = 0x03;  //0x03=Input Path is determined by functionality, 
                            //0x13 for 1 enabled
  
  CORE_PIN0_PADCONFIG = 0x10B0;  //pin pad configuration
  CORE_PIN2_PADCONFIG = 0x10B0;
  
  //set as input
  IOMUXC_XBAR1_IN17_SELECT_INPUT = 0x00;  //set both pins as input
  IOMUXC_XBAR1_IN06_SELECT_INPUT = 0x00;

  //==========================================================================
  /* XBARA_SetSignalsConnection(XBARA1, kXBARA1_InputIomuxXbarIn21, kXBARA1_OutputEnc1PhaseAInput);
   * XBARA_SetSignalsConnection(XBARA1, kXBARA1_InputIomuxXbarIn22, kXBARA1_OutputEnc1PhaseBInput);
   * XBARA_SetSignalsConnection(XBARA1, kXBARA1_InputIomuxXbarIn23, kXBARA1_OutputEnc1Index);
   * These are the SDK settings
   * kXBARA1_OutputEnc1PhaseAInput   = 66|0x100U,   // XBARA1_OUT66 output assigned to ENC1_PHASE_A_INPUT
   * kXBARA1_OutputEnc1PhaseBInput   = 67|0x100U,   // XBARA1_OUT67 output assigned to ENC1_PHASE_B_INPUT
   * kXBARA1_OutputEnc1Index         = 68|0x100U,   // XBARA1_OUT68 output assigned to ENC1_INDEX 
   * kXBARA1_OutputEnc1Home          = 69|0x100U,   // XBARA1_OUT69 output assigned to ENC1_HOME
   * kXBARA1_OutputEnc1Trigger       = 70|0x100U,   // XBARA1_OUT70 output assigned to ENC1_TRIGGER 
   *
   * kXBARA1_InputIomuxXbarInout06   = 6|0x100U,    // IOMUX_XBAR_INOUT06 output assigned to XBARA1_IN6 input.
   * kXBARA1_InputIomuxXbarInout07   = 7|0x100U,    // IOMUX_XBAR_INOUT07 output assigned to XBARA1_IN7 input.
   * kXBARA1_InputIomuxXbarInout08   = 8|0x100U,    // IOMUX_XBAR_INOUT08 output assigned to XBARA1_IN8 input.
   */
  
  xbar_connect(17, 66);
  xbar_connect(6, 67);


  Serial.print("IOMUXC_GPR_GPR6: "); Serial.println(IOMUXC_GPR_GPR6, BIN);

  delay(5000);
  //========================================================================
  //Phase A => pin3
  //Phase B => pin2
    /* Initialize the ENC module. */
    ENC_GetDefaultConfig(&mEncConfigStruct);
    ENC_Init(&mEncConfigStruct);
    ENC_DoSoftwareLoadInitialPositionValue(); /* Update the position counter with initial value. */
}

uint32_t old_position = 0;

void loop(){
  
  /* This read operation would capture all the position counter to responding hold registers. */
  mCurPosValue = ENC_GetPositionValue();

  if(mCurPosValue != old_position){
    /* Read the position values. */
    Serial.printf("Current position value: %ld\r\n", mCurPosValue);
    Serial.printf("Position differential value: %d\r\n", (int16_t)ENC_GetHoldPositionDifferenceValue());
    Serial.printf("Position revolution value: %d\r\n", ENC_GetHoldRevolutionValue());
    Serial.println();
  }

  old_position = mCurPosValue;
}

Pretty sure the config setups are right. Works for any pin combination that does not include pin 0. Really must be missing something obvious. Been through the RM more times than I care to count

Teensy 4.0 First Beta Test

Senior Member+

Well-known member

Well-known member

Well-known member

Senior Member+

Attachments

Senior Member+

Senior Member

Senior Member

Senior Member+

Senior Member

Senior Member+

Senior Member

Senior Member+

Senior Member+

Senior Member+

Senior Member+

Senior Member+

Senior Member+

Senior Member

Senior Member+

Well-known member

Senior Member+

Senior Member+

Senior Member+

Senior Member+