Teensy 4.0 First Beta Test

Frank B · Jan 14, 2019

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"

mjs513 · Jan 14, 2019

defragster said:
Nothing in particular - just that that it would rollover and be confusing. I was perhaps conflating it with micros rolling in ~87 secs where it was used for longer as a reference.

Also the quick look I gave to the elapsedus code didn't turn out right - given everything coming or going needs to be handled with 1/F_CPU_ACTUAL in the proper fashion. Having a steady 1 MHz value to feed it would make it fit in less code and run faster. The T_3.x version of elapsedus and micros goes to some effort to resolve/round the current value - running overhead extra code.

Mike, does NeoPixel modifiy the CycleCounter or just start and use it as a running value? <edit> seems to have two places it starts it and then just reads it for it's value. Though it uses F_CPU for resolution that will be wrong.

Just went through it again - just to verify. Like you said, just enables and reads. Doesn't modify from what I can see.

manitou · Jan 14, 2019

mjs513 said:
Started with some of the libraries I touched so far:
View attachment 15599

Comments - suggestions?

Thanks. you need to go deeper to find hardware timer that is being used. For example, IntervalTimer uses PIT (maybe all 4 channels), PWM uses some channels of QTIMER and flexPWM timer, IRremote uses flexPWM1 timer, FreqMeasure uses FLEXPWM4...

mjs513 · Jan 14, 2019

manitou said:
Thanks. you need to go deeper to find hardware timer that is being used. For example, IntervalTimer uses PIT (maybe all 4 channels), PWM uses some channels of QTIMER and flexPWM timer, IRremote uses flexPWM1 timer, FreqMeasure uses FLEXPWM4...

Ok will do. FreqMeasure I got as FlexPWM4, it was obvious at that one. Will relook at the other IntervalTimer again. Will keep in mind that in mind as I go through them.

defragster · Jan 15, 2019

Going to test tonight to make sure but this seems to be working - I did a Cycle Counter based Micros from systick_ms. For now it has a unique name to allow Verification - code it replaces is below.

<edit> problem is taking two volatile vars from systick_isr and the return could cross a tick. Code below measures 11% faster, 17% slower with disable_irq and re-enable_irq? As getting old systick_cycle_count then updated systick_millis_count would add a tick on that call. My auto checked test running 3-4 passes per second [delay(300) to keep sermon happy JIC] on the 120 test values - when it was wrong it was way wrong - test allows ccmicros()+/-1 to pass - will see where it is in a few hours. Can try reading one count twice [before and after the other] and repeating if diff and not disable interrupt ...

Code:

uint32_t ccmicros(void)
{
	uint32_t ccdelta = ARM_DWT_CYCCNT, usec;
	ccdelta -= systick_cycle_count;
	usec = 1000*systick_millis_count + (ccdelta/(F_CPU_ACTUAL/1000000));
	return usec;
}

In the end if it really works it would replace current micros() - including elapsedMicros() usage - no interrupt disabling and what seems to be a lot less code - no conditionals and no wondering how long ago the clock ticked.
In fact should work over 7 seconds with interrupts disabled. I just put __disable_irq(); and __enable_irq(); around my test code and they run fed from prior systick_ms and delta cycleCounter. So if systicks are lost the clock base ref will diverge - though correction from ccdelta might be workable.
There is of course the startup issue given that the calculation is delta based we need the base first so while countably accurate up to 200ms, it will 'cusp' to get in sync - I won't show that cute trick that happens after 2nd systick_isr() until I run automated test run overnight

Works with one added line here:

Code:

extern "C" void systick_isr(void)
{
[B]	systick_cycle_count += F_CPU_ACTUAL/1000;[/B]
	systick_millis_count++;
	MillisTimer::runFromTimer();
}

This is the current T:\arduino-1.8.8T4_146\hardware\teensy\avr\cores\teensy4\delay.c

Code:

uint32_t micros(void)
{
	uint32_t msec, tick, elapsed, istatus, usec;
	static uint32_t prev_usec=0;
	static int doprint=180;

	__disable_irq();
	tick = SYST_CVR;
	msec = systick_millis_count;
	istatus = SCB_ICSR;     // bit 26 indicates if systick exception pending
#ifndef SYSTICK_EXT_FREQ
	const uint32_t fcpu = F_CPU;
#endif
	__enable_irq();
	istatus &= SCB_ICSR_PENDSTSET;
#ifdef SYSTICK_EXT_FREQ
	if ((istatus & SCB_ICSR_PENDSTSET) && (tick == 0 || tick > (SYSTICK_EXT_FREQ / 2000))) {
#else
	if ((istatus & SCB_ICSR_PENDSTSET) && (tick == 0 || tick > (fcpu / 2000))) {
#endif
		msec++;
	}
#if defined(SYSTICK_EXT_FREQ) && SYSTICK_EXT_FREQ <= 1000000
	elapsed = (SYSTICK_EXT_FREQ / 1000) - tick;
	if (tick == 0) elapsed = 0;
	usec = msec * 1000 + elapsed * (1000000 / SYSTICK_EXT_FREQ);
#elif defined(SYSTICK_EXT_FREQ) && SYSTICK_EXT_FREQ > 1000000
	elapsed = (SYSTICK_EXT_FREQ / 1000) - tick;
	if (tick == 0) elapsed = 0;
	usec = msec * 1000 + elapsed / (SYSTICK_EXT_FREQ / 1000000);
#else
	elapsed = (fcpu / 1000) - tick;
	if (tick == 0) elapsed = 0;
	usec = msec * 1000 + elapsed / (fcpu / 1000000);
#endif
	if (usec < prev_usec && doprint) {
		if (doprint > 0) doprint--;
	}
	prev_usec = usec;
	return usec;
}

output from current test after 471 seconds with this running each 3 seconds:

base rtc ticks=: 471

micros: 471617000 // base times before ALL test groups
ccmicros: 471617026
millis: 471617

micros: 471620330 // base times after ALL test groups
ccmicros: 471620343
millis: 471620
// This group updates 60,000 cpu cycles apart or 0.1 ms
471617105 471617205 471617305 471617405 471617505 471617605 471617705 471617805 471617905 471618005
471618105 471618205 471618305 471618405 471618505 471618605 471618705 471618805 471618905 471619005
471619105 471619205 471619305 471619405 471619505 471619605 471619705 471619805 471619905 471620005

// This group updates 6000 cpu cycles apart or 0.01 ms
471620015 471620025 471620035 471620045 471620055 471620065 471620075 471620085 471620095 471620105
471620115 471620125 471620136 471620146 471620156 471620166 471620176 471620186 471620196 471620206
471620216 471620226 471620236 471620246 471620256 471620266 471620276 471620286 471620296 471620306

// This group updates 600 cpu cycles apart or 0.001 ms
471620307 471620308 471620309 471620310 471620311 471620312 471620313 471620314 471620315 471620316
471620317 471620318 471620319 471620320 471620321 471620322 471620323 471620324 471620325 471620326
471620327 471620328 471620329 471620330 471620331 471620332 471620333 471620334 471620335 471620336

mjs513 · Jan 15, 2019

CORE_PINS.H

Think minor error on pin assignment:

Code:

// pad config registers control pullup/pulldown/keeper, drive strength, etc
#define CORE_PIN0_PADCONFIG	IOMUXC_SW_PAD_CTL_PAD_GPIO_AD_B0_02
#define CORE_PIN1_PADCONFIG	IOMUXC_SW_PAD_CTL_PAD_GPIO_AD_B0_03

Should this be:

Code:

// pad config registers control pullup/pulldown/keeper, drive strength, etc
#define CORE_PIN0_PADCONFIG	IOMUXC_SW_PAD_CTL_PAD_GPIO_AD_B0_03
#define CORE_PIN1_PADCONFIG	IOMUXC_SW_PAD_CTL_PAD_GPIO_AD_B0_02

Its about line 337

manitou · Jan 15, 2019

manitou said:
seems to fix the inversion problem with pins 0 and 1 (and presumably with pins 24 and 25).

With T4 breakout, I checked the PWM waveforms on the backside pins and confirmed PWM on pins 24 and 25 have proper polarity. Also did digitalWrite tests on backside pins, and Rx-Tx tests on Serial6, Serial7, Serial8. Also did GPT input capture on pin 26 (ref post #146 )

KurtE · Jan 15, 2019

Yesterday I was mostly busy with some other stuff, but did some experimenting on my ili9341_t3n library and SPIN...

So far I am not having any luck updating the SPI->TCR register on the fly and get the results output. Trying to use for DC.

I have hacked the code to enable the one CS pin to be enabled in SPI mode and I use the GPIO Set/Clear registers to manipulate the CS pin for CS

The graphic test program runs and does manipulate all of the pins but having issues.

a) My code to wait until transmission is complete is not working, so CS pin unasserted to early. I don't see anything like the EOQ flag that was used for T3.x in these libraries, so may update the SPIN code to work like TLC and count words/bytes output versus ones received back...

b) The changing of the TCR - while data is still in FIFO is not working and everything is output in 8 bits only...

c) The attempt to change which CS pin is asserted from 0 to non-zero is not working, currently the real CS is being set/cleared for each byte...

Here is an LA output showing the starting to try to clear the screen.

The trace line (CS, Reset, DC - hardware controlled CS, MOSI, SCLK, MISO)

Let me know if anyone wishes to play along, and I could update my GITHUB projects with this WIP

EDIT: - Found typo errors in my macros (used || instead of | )

So getting some better outputs...

Now to hack up fix for knowing when transmission is complete to update CS pin at the proper time.

Kurt

P.S. - @Frank B - I meant to say it yesterday, sorry to hear about your family member going to the hospital. I hope they are doing better! Take care!

mjs513 · Jan 15, 2019

@KurtE

Let me know if anyone wishes to play along, and I could update my GITHUB projects with this WIP

I started this so I willing to play along

You might want to check out TXCOUNT and maybe tx watermark? Maybe one of these will help.

Working another problem I am having, really just don't understand how to do it to be honest but will post that as a separate question

EDIT: That second image is just about what I saw on the scope when I hooked up DC and CS to the scope with the Adafruit library - man logic analyzers are nice

KurtE · Jan 15, 2019

Yep - Still WIP - But I pushed up T4_WIP branches for my SPIN and ili9341_t3n github projects...

Will be busy with some other stuff this morning... Will play more later. Also want to move some of my CS pin hacks out of the ILI9341_t3n library and put into SPI library update. That is define pin 10 is pinIsChipSelect in hardware table and to have the setCS put the pin into SPI mode...
i.e. let SPI do the normal SPI stuff here...

mjs513 · Jan 15, 2019

USING ALTERNATE DEFINITIONS OF PINS - HOW TO?

Getting myself really confused on this one, trying to read the manual and testing. Looking at PINs 0 and 1 for instance the default is Serial1 (LPUART6). Now if I want to reassign it to XBARA or FLEXCAN. I was looking at the quadrature encoder module and it use the xbara pins for input. Anyway this is the process I think:

1. Turn LPUART6 clock off (CCGR3)
2. Disable the LPUART6 IRQ
3. didn't see a way to update the vtable so guess that stays
4. Update pin configurations, i.e.,

Code:

000 ALT0 — Select mux mode: ALT0 mux port: FLEXCAN2_RX of instance: flexcan2
001 ALT1 — Select mux mode: ALT1 mux port: XBAR1_INOUT17 of instance: xbar1
010 ALT2 — Select mux mode: ALT2 mux port: LPUART6_RX of instance: lpuart6

and sion bit to enable
5. Select input - output modes for pins, i.e.

Code:

IOMUXC_FLEXCAN2_RX_SELECT_INPUT for Flexcan
xbar_connect  (saw this in pwm.c)

6. Configure Flexcan2 or Xbar clocks
7. Enable clocks with CCM_CCGR0 or CCM_CCGR2
8. Almost forgot enable IRQs for XBAR or FLEXCAN2

Still need to work some of the details but just want to see if this makes sense and I am on the right track.

mjs513 · Jan 15, 2019

KurtE said:
Yep - Still WIP - But I pushed up T4_WIP branches for my SPIN and ili9341_t3n github projects...

Will be busy with some other stuff this morning... Will play more later. Also want to move some of my CS pin hacks out of the ILI9341_t3n library and put into SPI library update. That is define pin 10 is pinIsChipSelect in hardware table and to have the setCS put the pin into SPI mode...
i.e. let SPI do the normal SPI stuff here...

Thanks = will work on this, this afternoon. Just picked up a stepper motor and Adafruits breakout motor controller board to test their library. Have their shield but that's a pain to work with. So have a bunch of soldering to do this afternoon as well.

Frank B · Jan 15, 2019

Problem(?) - not sure if it is..

I replaced set_arm_clock(600000000); with set_arm_clock(12000000); (12MHz) - teensy ist still fast

but that is not the problem

If I use this, the T4 blinks slowly (orange LED) after upload, and I have to press the button.

defragster · Jan 15, 2019

Frank B said:
Problem(?) - not sure if it is..

I replaced set_arm_clock(600000000); with set_arm_clock(12000000); (12MHz) - teensy ist still fast but that is not the problem
If I use this, the T4 blinks slowly (orange LED) after upload, and I have to press the button.

@Frank: Was the set_arm_clock(12000000) in the active sketch before upload? So the T4 is not doing a restart after the upload? Is that because USB is offline at 12 MHz?

I refined my [cc]micros() using ARM_DWT_CYCCNT and it is working with noInterrupts(). It takes about 19% longer and the codeline added to systick_isr() - is that better than wasting a GPT timer to work around the slow systick driven clock?

Current test running is on the way to us wrap - currently at 2,857,980,987 with 1024 * 2748000 successful tests of 1us update … then I'll try one more edit without int disable - my _isr occurred test correction was faulty.

mjs513 · Jan 15, 2019

defragster said:
@Frank: Was the set_arm_clock(12000000) in the active sketch before upload? So the T4 is not doing a restart after the upload? Is that because USB is offline at 12 MHz?

I refined my [cc]micros() using ARM_DWT_CYCCNT and it is working with noInterrupts(). It takes about 19% longer and the codeline added to systick_isr() - is that better than wasting a GPT timer to work around the slow systick driven clock?

Current test running is on the way to us wrap - currently at 2,857,980,987 with 1024 * 2748000 successful tests of 1us update … then I'll try one more edit without int disable - my _isr occurred test correction was faulty.

Tim,
Meant to say it last night, but, great work on the microsecond timer, hope it gets incorporated.

@Frank. There are so many different clocks that can get affected by the arm clock. Tim may be right about USB being offline - ran to a similar problem last night when trying to redefine pins and associated clocks. Sketch updates wouldn't load unless I hit the button. Once I changed the clocks back uploads worked normal.

Frank B · Jan 15, 2019

defragster said:
@Frank: Was the set_arm_clock(12000000) in the active sketch before upload? So the T4 is not doing a restart after the upload? Is that because USB is offline at 12 MHz?

Yes it was active, and USB is online.. so I don't know the reason.

defragster said:
I refined my [cc]micros() using ARM_DWT_CYCCNT and it is working with noInterrupts(). It takes about 19% longer and the codeline added to systick_isr() - is that better than wasting a GPT timer to work around the slow systick driven clock?

Good job! That's fine in my opinion

Does the code disable interrupts? If yes, is there a way without it?

I played with SPI, again.. I have a serious problem with SPI, or SPI with me..
How do you guys do it witout the gap between bytes?
If I use 32BIT transfers, it looks like this:

o...even then gaps between BYTES..(32BIt!!) that effectivly halfes the transferrate.. What the hell i'm doing wrong? (24MHz here)

@Kurt, LPSPI_CCR_SCKDIV(div) /*| LPSPI_CCR_DBT(0);*/ does not help.

defragster · Jan 15, 2019

mjs513 said:
Tim,
Meant to say it last night, but, great work on the microsecond timer, hope it gets incorporated.
...

Thanks Mike - I was wondering

So my current test with disabling interrupts just completed a wrap of us uint32_t. This test runs for 1024 us changes in a row and stores the value into an array when it changes. Then I compare sequential elements for 1us difference. Here is where that completed and crossed the number wrap of us's.
Code isn't much so posted below for any reviews ??? - this is the Version that allows INTERRUPTS TO STAY ON! Will do a PR if no notes and the current test wraps without error.
Paul: Is F_CPU_ACTUAL valid at all clock speeds so this works without ifdef's of the current micros()?
This could Port back to the T_3.6 and T_3.5 ( and T_3.2 ) if the cycle counter was started?
This shows 40 dots printed to entertain me for the just over 4 seconds it takes to test the 1024 values 4000 times per line. After that running count is new ccmicros() with usable last digit and the current micros() with a frozen digit.

Code:

........................................ #1024's=4116000 @ccus=4279366619 <> us=4279366610
........................................ #1024's=4120000 @ccus=4283522713 <> us=4283522710
........................................ #1024's=4124000 @ccus=4287678817 <> us=4287678810
........................................ #1024's=4128000 @ccus=4291834926 <> us=4291834920
........................................ #1024's=4132000 @ccus=1023739 <> us=1023734
........................................ #1024's=4136000 @ccus=5179837 <> us=5179834
........................................ #1024's=4140000 @ccus=9335940 <> us=9335934
........................................ #1024's=4144000 @ccus=13492033 <> us=13492024
........................................ #1024's=4148000 @ccus=17648127 <> us=17648124
........................................ #1024's=4152000 @ccus=21804225 <> us=21804224
........................................ #1024's=4156000 @ccus=25960333 <> us=25960324
........................................ #1024's=4160000 @ccus=30116431 <> us=30116424
........................................ #1024's=4164000 @ccus=34272524 <> us=34272524
........................................ #1024's=4168000 @ccus=38428632 <> us=38428624
........................................ #1024's=4172000 @ccus=42584735 <> us=42584734
........................................ #1024's=4176000 @ccus=46740843 <> us=46740834
........................................ #1024's=4180000 @ccus=50896951 <> us=50896944
........................................ #1024's=4184000 @ccus=55053054 <> us=55053054
........................................ #1024's=4188000 @ccus=59209152 <> us=59209144
........................................ #1024's=4192000 @ccus=63365245 <> us=63365244
........................................ #1024's=4196000 @ccus=67521343 <> us=67521334
........................................ #1024's=4200000 @ccus=71677441 <> us=71677434
........................................ #1024's=4204000 @ccus=75833534 <> us=75833534
........................................ #1024's=4208000 @ccus=79989627 <> us=79989624
........................................ #1024's=4212000 @ccus=84145735 <> us=84145734
........................................ #1024's=4216000 @ccus=88301838 <> us=88301834
........................................ #1024's=4220000 @ccus=92457931 <> us=92457924
........................................ #1024's=4224000 @ccus=96614029 <> us=96614024
........................................ #1024's=4228000 @ccus=100770122 <> us=100770114
........................................ #1024's=4232000 @ccus=104926227 <> us=104926224
........................................ #1024's=4236000 @ccus=109082325 <> us=109082324
........................................ #1024's=4240000 @ccus=113238424 <> us=113238424

This version looks like this timewise for repeat calls:

50K micros: 1647897
50K ccmicros: 1950699

Using the non interrupt display version looks a bit faster - on average:

50K micros: 1597772
50K ccmicros: 1601041

So far it is running right - just finished the first 2.3 million sets of 1024 tests:

... #1024's=2336000 @ccus=2447826438 <> us=2447826430

This is the current code in use to restart if it catches systick_isr having fired:

Code:

uint32_t ccmicros(void)
{
	uint32_t ccdelta, usec, smc, smc2;
	do {
		smc = systick_millis_count;
		ccdelta = ARM_DWT_CYCCNT;
		ccdelta -= systick_cycle_count;
		smc2 = systick_millis_count;
	} while ( smc != smc2 );
	usec = 1000*smc + (ccdelta/(F_CPU_ACTUAL/1000000));
	return usec;
}

Any ideas for trouble spots or improvements?

Here's the code in use to establish the base for the Arm CycCnt in the first 2 systicks as the first fire of the _isr() may hit before the cycle counter is running:

Code:

static void systick_isr_sync(void)
{
	systick_cycle_count = ARM_DWT_CYCCNT;
	systick_millis_count++;
	if ( 2 == systick_millis_count )
[B]	_VectorsRam[15] = systick_isr;
[/B]}
static void configure_systick(void)
{
	_VectorsRam[14] = pendablesrvreq_isr;
	[B]_VectorsRam[15] = systick_isr_sync;[/B]
	SYST_RVR = (SYSTICK_EXT_FREQ / 1000) - 1;
	SYST_CVR = 0;
	SYST_CSR = SYST_CSR_TICKINT | SYST_CSR_ENABLE;
	SCB_SHPR3 = 0x20000000;  // Systick = priority 32
	ARM_DEMCR |= ARM_DEMCR_TRCENA;
	ARM_DWT_CTRL |= ARM_DWT_CTRL_CYCCNTENA; // turn on cycle counter
	systick_cycle_count = ARM_DWT_CYCCNT;
}

And then the real _isr() code with one line added:

Code:

extern "C" void systick_isr(void)
{
	[B]systick_cycle_count += F_CPU_ACTUAL/1000;[/B]
	systick_millis_count++;
	MillisTimer::runFromTimer();
}

KurtE · Jan 15, 2019

@Frank B - SPI - No gaps....

As I mentioned in some previous post (getting hard to keep track of things here)

Transfer delays: a couple of things.

A certain amount of the time is taken up by the simple overhead.
So: SPI.transfer(0);SPI.transfer(1);
Each transfer puts the thing into the fifo (TDR) and then we wait for the data to be shifted out and then wait for SPI to say that SPI completed and data is available on RDR, which often we then read and ignore, finally returning, to repeat.

Now currently in the code there is now a defined delay after a transfer complete: I added it in the SPISettings...
ccr = LPSPI_CCR_SCKDIV(div) | LPSPI_CCR_DBT(div/2);

I added the DBT settings. (Page 2660) - Some of this was guesstimates by me... Why?

If you do what I mentioned, SPI.transfer(0); SPI.transfer(1);
You already get a significant delay without it...
But: if you do:

Code:

    uint8_t buf[] = {0, 1};
    SPI.transfer(buf, NULL, sizeof(buf));

This uses the FIFO buffer, and with the FIFO buffer, without the DBT settings, the gap between bytes defaults to something like 2SPI timing units or when measure was just a blip on my Logic Analyzer... So I set it up... And then I measured at near full speed, asked 30mhz, 8mhz, 2mhz, 400khz... And it measured reasonably close...

One thing I thought of was to hack the field in the CCR, like 0 it when Transfer(0), and Transfer(16) are called and set it for buffer transfers... But then would have to decide should it default to being set, such that if anyone like my ili9341_t3n library code who uses the queue would have proper timing...

Now still trying to figure out how to know when all transfers have fully shifted out... More experiments...

@Paul and @mjs513 - I did another PR on my open SPI changes (Fix for Serial Flash) - that now will return 1 if you ask if pin 10 is a chip select pin and it will set it into SPI mode if you call setCS(10);

defragster · Jan 15, 2019

@Frank - we cross posted

The "Leave Interrupts Running version" just completed a uint32_t wrap of microseconds on the clock - passed my testing where out of 4,293,134,314 us up to the WRAP point I tested 4,210,688,000 to present sequential microseconds - and the new versus the old micros() doesn't diverge.

........................................ #1024's=4108000 @ccus=4288978220 <> us=4288978220
........................................ #1024's=4112000 @ccus=4293134314 <> us=4293134310
........................................ #1024's=4116000 @ccus=2323112 <> us=2323104
........................................ #1024's=4120000 @ccus=6479219 <> us=6479214
........................................ #1024's=4124000 @ccus=10635321 <> us=10635314
........................................ #1024's=4128000 @ccus=14791424 <> us=14791424

Now the hardest part … jousting with GitHub to get a Pull request entered ...

As far as the time of the call - last post showed one set of 10K loops of 5 calls varied. Here is a set of 10 of those 50K each runs - looks like this CycleCount version runs in the same time but does not stop interrupts, and gives the true us's digit. NOTE: Times are in ARM_DWT_CYCCNT clock cycles - <33.2 clocks for each at 600 MHz.

50K micros: 1657928
50K ccmicros: 1650100

50K micros: 1657870
50K ccmicros: 1650285

50K micros: 1657862
50K ccmicros: 1651132

50K micros: 1657872
50K ccmicros: 1650306

50K micros: 1657854
50K ccmicros: 1652015

50K micros: 1657862
50K ccmicros: 1650303

50K micros: 1657855
50K ccmicros: 1653517

50K micros: 1657869
50K ccmicros: 1650305

50K micros: 1657855
50K ccmicros: 1655375

50K micros: 1657866
50K ccmicros: 1650303

mjs513 · Jan 15, 2019

Tim u got that right:

Now the hardest part … jousting with GitHub to get a Pull request entered ...

@KurtE - just downloaded your forked version of SPI so I could get you t3n_WIP running. Put a scope on the CS and DC pins running the GraphicsTest sketch. DC is firing constantly - have to come up with a better sketch to test with. Just started looking so not much else to say at this point.

defragster · Jan 15, 2019

mjs513 said:
Tim u got that right:
...

And tempmon_init broke my build after copying merged files - so I got current core Teensy4 - now I'm stuck on this. Is this a bug in github CORE files or something out of sync on my end?

T:\arduino-1.8.8T4_146\hardware\teensy\avr\cores\teensy4\IntervalTimer.cpp:38:119: error: expected ',' or ';' before '__attribute'

static void (*funct_table[4])(void) __attribute((aligned(32))) = {dummy_funct, dummy_funct, dummy_funct, dummy_funct} __attribute((aligned(32)));

^

mjs513 · Jan 15, 2019

defragster said:
And tempmon_init broke my build after copying merged files - so I got current core Teensy4 - now I'm stuck on this. Is this a bug in github CORE files or something out of sync on my end?

Tim
Not sure why tempmon_init would break your build. I see the function table in interval timer but it not throwing any errors when I run a intervaltimer example sketch that I have.

defragster · Jan 15, 2019

I had not done an update of my core in some time - I didn't have tempmon code - the init is in a file I touched so to do my code merge I needed to update.

With that done I get the dummy error in code I'm not using - it worked before when I did it - but something was added and my compiler doesn't like the syntax.

I just hacked it off to compile - but now the nebulous chore of watching time pass is made difficult because the old core micros() is no more - and millis and elapsedMillis not working … I'm hoping the problem relates to that vector not being aligned but am not sure why it is broken or how to fix it properly...

KurtE · Jan 15, 2019

Making some progress with my ili9341_t3n/SPIN library implementations

Needed to clear out some of the states (W1C in the SR register). Appears to be working better.

Still needs work. Also need to enable frame buffer, also need to work on DMA support and ...

But if I run the Adafruit_ili9341 library, the timings show:

Code:

ILI9341 Test!
SPI MISO: 12 MOSI: 11, SCK: 13
Display Power Mode: 0x94
MADCTL Mode: 0x48
Pixel Format: 0x5
Image Format: 0x80
Self Diagnostic: 0xC0
Benchmark                Time (microseconds)
Screen fill              993370
Text                     49080
Lines                    465640
Horiz/Vert Lines         81250
Rectangles (outline)     51720
Rectangles (filled)      2061730
Circles (filled)         288390
Circles (outline)        203800
Triangles (outline)      106080
Triangles (filled)       670390
Rounded rects (outline)  97400
Rounded rects (filled)   2241290
Done!

If I run mine, which at least some of the outputs are coming to the screen... And maybe a crash... But some progress...

Code:

LI9341 Test!
SPI MISO: 12 MOSI: 11, SCK: 13
After TFT Begin
13
Display Power Mode: 0x10
MADCTL Mode: 0x10
Pixel Format: 0x10
Image Format: 0x10
Self Diagnostic: 0x10
Benchmark                Time (microseconds)
Screen fill              244740
Text                     10920
Lines                    68330
Horiz/Vert Lines         20010
Rectangles (outline)     12780
Rectangles (filled)      502180
Circles (filled)         73360
Circles (outline)        62200
Triangles (outline)      16330
Triangles (filled)       166190
Rounded rects (outline)  27460
Rounded rects (filled)   547750
Hit key to continue

Again there are issues to resolve, but hopefully progress...
As mentioned in previous post SPI project updated, likewise SPIN and ILI9341_t3n project updated as well.

defragster · Jan 15, 2019

Undid my few changes - and IntervalTimer.cpp:38:119 still broken - is there something outside of CORES I need to update?

<edit> - I reverted my few changes and my system is still broken on this last Merge from Frank 3 days ago:

T:\arduino-1.8.8T4_146\hardware\teensy\avr\cores\teensy4\IntervalTimer.cpp:38:119: error: expected ',' or ';' before '__attribute'

static void (*funct_table[4])(void) __attribute((aligned(32))) = {dummy_funct, dummy_funct, dummy_funct, dummy_funct} __attribute((aligned(32)));

Teensy 4.0 First Beta Test

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+

Senior Member

Senior Member+

Senior Member+

Senior Member+

Senior Member+

Senior Member+

Senior Member+

Senior Member+

Senior Member+

Senior Member+