Teensy 4.0 First Beta Test

Status
Not open for further replies.
Well, the proof may be in the pudding -- since it doesn't want to count above 10mhz.

So I changed the test sketch to not use the interval timer (spin on micros() for a second), and before init'ing GPT2 clock, changed source clock to 150mhz
CCM_CSCMR1 &= ~CCM_CSCMR1_PERCLK_CLK_SEL; // turn off 24mhz mode
and sketch counted properly for PWM running at 15 mhz (which wasn't working in 24mhz mode).
Works @30mhz, and when i PWM @40mhz, it reports 37.5mhz (as expected, max is 150mhz/4) well, maybe, because max PWM rate is also only 37.5 mhz.

modified sketch
……..

@manitou
Thanks for checking - funny that's not the way I was reading the RM but then again I only read it twice :) Ran some tests with various inputs:
Code:
@10Mhz ==> 10000010
@15Mhz ==> 15000013-15000017
@20Mhz ==> 18750017-18750021
@25Mhz ==> 25000024-25000027
@30Mhz ==> 30000027-30000033
@35Mhz & @40Mhz ==> 37500033-37500041
Interesting the bumped at 20Mhz..... So now guess to have to change freqcount library
 
Interesting the bumped at 20Mhz..... So now guess to have to change freqcount library

Well, that's discretization error from the PWM divisors (150/2=75, 150/3=50,150/4=37.5, /5 =30, 25, 21.4, 18.75, ...)
 
Last edited:
Well, that's discretization error from the PWM divisors (150/4=37.5, /5 =30, 25, 21.4, 18.75, ...)

@manitou

Good to know - keep learning something new everyday :) Anyway made the change to freqcount library - no longer uses a timer - just the 1 second reading got up to 30Mhz reliable output using analogwritefreq :)
Code:
Input	Output
5000000	5000007
10000000	10000014
20000000	18750027
25000000	25000681
30000000	30000041
 
@manitou
Anyway made the change to freqcount library

So your lib changes include changing the source clock of GPT to 150mhz? Will that be viable since the the source clock for PIT timer also changes, and things like interval timer will break? Also GPT and PIT will be affected by any change to the CPU clock speed. When clocked from 24mhz oscillator, those timers are not affected by changes to CPU clock.

Recall all of the clock functions that the NXP SDK used to determine what that base clock frequency was for a given timer ...
 
So your lib changes include changing the source clock of GPT to 150mhz? Will that be viable since the the source clock for PIT timer also changes, and things like interval timer will break? Also GPT and PIT will be affected by any change to the CPU clock speed. When clocked from 24mhz oscillator, those timers are not affected by changes to CPU clock.

Recall all of the clock functions that the NXP SDK used to determine what that base clock frequency was for a given timer ...

Yeah - unfortunately know no other way around it unless we limit freqcount to 10Mhz but then again .. What do you recommend - keep it the way we have it or to change it - my guess is you are going to tell me to leave it limited to 10Mhz :)

EDIT: Yeah - you are right - would cause too many other issues so let it be with just a note that there is a limit, https://github.com/PaulStoffregen/FreqCount/pull/11
 
you could comment or ifdef out the line that turns off 24mhz and provide comments about the benefits/problems...

There might be a way to use Quad Timer with one of the timer input pins as clock source. timer is only 16 bits (like T3 FMT timers), but you can also chain/cascade count registers to get 32-bits (or 48 or 64)
 
Last edited:
So far I have not had much luck with these types of displays that do not have a CS pin.

What I have read up on the web is some/all of them may require +5v to their VIN (looks like a VR on them).

Some had luck editing Adafruit_st7735/89 library, although it looks like some of the stuff may be built in now...

But the instructions were to set CS to -1 so that it was not used... I tried instead just using some random CS pin... Then instead of SPI_MODE0, some say for these boards you need SPI_MODE2 and others say SPI_MODE3. I was experimenting with that with my previous boards, but I think they are all DOA.

The Init code on Adafruit library allowed you to pass in a SPI_MODE to the ST7789::init method. So my current version allows it as well and defaults to SPI_MODE0.
But in theory you should be able to do: tft.init(240,240, SPI_MODE3);

And or SPI MODE 2... But non of them worked for me...

When I tried the last one I got from EBAY - when I tried starting it up, it almost looked like a tear in the display when it was powered up...

I have two other ST7789 displays: One from Adafruit, which arrived yesterday... Have not tried it yet.
And one from Amazon (https://smile.amazon.com/gp/product/B07MH93747/) which has CS pin and works.

I just ordered four of them for $3.77 each on Amazon ( see https://www.amazon.com/Semoic-Commu...coding=UTF8&psc=1&refRID=A3CCKTY8GGG4ER5HV3T6). I think it does have CS but it is labeled, 'DC'. See the product description at the bottom of the page.
 
I just ordered four of them for $3.77 each on Amazon ( see https://www.amazon.com/Semoic-Commu...coding=UTF8&psc=1&refRID=A3CCKTY8GGG4ER5HV3T6). I think it does have CS but it is labeled, 'DC'. See the product description at the bottom of the page.

Hmmm, it was $4.12 when I ordered my two yesterday, now it is $3.77. Of course it is on the slow boat from China (or China Post) to me. It looks like there are two different sellers (but all with the same photos).

Note, DC is typically a part of the SPI protocol (it allows you to switch between data and command modes), so I suspect the CS is just hardwired to ground (which enables the device). The Waveshare board KurtE mentioned looks like it has a proper CS pin. Of course the second one is made by a name manufacturer and is being sold for $14.85 which the no-name version is $3.77.
 
Last edited:
Hmmm, it was $4.12 when I ordered my two yesterday, now it is $3.77. Of course it is on the slow boat from China (or China Post) to me.

Note, DC is typically a part of the SPI protocol (it allows you to switch between data and command modes), so I suspect the CS is just hardwired to ground (which enables the device). The Waveshare board KurtE mentioned looks like it has a proper CS pin. Of course the second one is made by a name manufacturer and is being sold for $14.85 which the no-name version is $3.77.

You're right. DC is data/command selection. When I quickly read through it I saw 'command selection' and read CS.
 
So far I have not had much luck with these types of displays that do not have a CS pin.

What I have read up on the web is some/all of them may require +5v to their VIN (looks like a VR on them).

Hmmm, I know with WS2812B (neopixels) things get cranky if you feed the device 5v power but only 3.3v data lines. I wonder if running the DC/SCK/MOSI lines through a 3.3v->5v booster would work.

And of course if it is wanting 5v, it may be expecting a slow Arduino Uno to control it.
 
@MichaelMeissner & KurtE ...:
Not sure if this is any better than the last github link I posted this is also ESP32: ST7789 Driver for MicroPython - based on the forum that linked it - It is a "C" code rewrite - so the architecture will be very wrong as both microPython and ESP32 - but it is "C" so it might have a readable set of notes to a functional solution providing what the display needs.

It has this code - not sure if it sets a mode in display - or if it just changes color look ups:
Code:
// color modes
#define COLOR_MODE_65K      0x50
#define COLOR_MODE_262K     0x60
#define COLOR_MODE_12BIT    0x03
#define COLOR_MODE_16BIT    0x05
#define COLOR_MODE_18BIT    0x06
#define COLOR_MODE_16M      0x07


And actually looking at the readme info it shows it was ported from this given it is the "CS" free version shown in above link:: github.com/ananevilya/Arduino-ST7789-Library/ that may be a better start point?

Scanning that code I even see this :: #if defined(__AVR__) || defined(CORE_TEENSY) // 8 bit!

That 8 bit is opposed to 9 bit SPI AFAIK - and this code doesn't seem to (pretend to) offer 'color mode' selection.
 
@MichaelMeissner @Defragster - ST7789 without CS pins - Maybe should create a new thread as not really T4 specific...

I have tried out a couple of these and have not had much luck...

https://smile.amazon.com/gp/product/B07P9X3L7M/

This includes a couple of interesting images:

612gnrUwDTL._SL1200_.jpg

71Wm8civGdL._SL1200_.jpg


Note the Adafruit library has since been edited, where you can directly pass in the SPI mode to use, instead of hard coding it to SPI_MODE0. It does default to Mode 0

Kurt

P.S. - I went ahead and ordered one of those cheap ones that should arrive whenever the boat gets here...
 

Attachments

  • 71Wm8civGdL._SL1200_.jpg
    71Wm8civGdL._SL1200_.jpg
    111.6 KB · Views: 108
you could comment or ifdef out the line that turns off 24mhz and provide comments about the benefits/problems...

There might be a way to use Quad Timer with one of the timer input pins as clock source. timer is only 16 bits (like T3 FMT timers), but you can also chain/cascade count registers to get 32-bits (or 48 or 64)

QTIMER count external pulses (quad timer)

Here is a sketch that counts external pulses on T4 pin 19 with QTIMER3 CHNL0. It chains to CHNL1 to get 32-bit count (but that will make pin 18 unavailable for PWM). I tested with PWM jumper up to 50 Mhz. Ref 53.3 says "Max count rate equals peripheral clock/2 for external clocks".

So besides GPT, QTIMER might also be used to implement FreqCount
 
Last edited:
QTIMER count external pulses (quad timer)

Here is a sketch that counts external pulses on T4 pin 19 with QTIMER3 CHNL0. It chains to CHNL1 to get 32-bit count (but that will make pin 18 unavailable for PWM). I tested with PWM jumper up to 37.5 Mhz. Ref 53.3 says "Max count rate equals peripheral clock/2 for external clocks".

So besides GPT, QTIMER might also be used to implement FreqCount

Worked for me, only testing at either 1 or 7,500 counts and 75,000 and 5.

Either 1 on pin 13 for LED toggle on 15,000 count, or added a pin 14 toggle in the _isr to the prior QTimer example on second T4 that was set at 15,000, then dropped a '0' on timer count and it shows 75,000 or 75,001, and then 5 on the LED blink for 75,000/15,000.

Dropped another zero from count and get 75,003 and 75,004 on #14 and 50 on the LED. That _isr seems to peak at 3.6M with anoter dropped zero?
 
QTIMER count external pulses (quad timer)

Here is a sketch that counts external pulses on T4 pin 19 with QTIMER3 CHNL0. It chains to CHNL1 to get 32-bit count (but that will make pin 18 unavailable for PWM). I tested with PWM jumper up to 37.5 Mhz. Ref 53.3 says "Max count rate equals peripheral clock/2 for external clocks".

So besides GPT, QTIMER might also be used to implement FreqCount

@manitou - @defragster

Thanks for putting this together @manitou, nice job - decided to take a little break from playing with T4 and was reading up on my robotics project again. Any way ran it up to 30Mhz with no problem range 30,000,017-30,000,027. Doesn't seem to want to go beyond 30Mhz though on my setup, AnalogwriteFreq on 1 T4 and QT counter on another T4.
 
@manitou - @defragster

Thanks for putting this together @manitou, nice job - decided to take a little break from playing with T4 and was reading up on my robotics project again. Any way ran it up to 30Mhz with no problem range 30,000,017-30,000,027. Doesn't seem to want to go beyond 30Mhz though on my setup, AnalogwriteFreq on 1 T4 and QT counter on another T4.

Yes, Pin 19 seems good for Both.

Just realized I didn't need to see the _isr toggle #14 - I just hooked #19 to #19 - one putting the time out and one counting it.

Freq Read of :
66543811
66547737
66555067
66542816
66542183
66541634
66553339
66506297
66170196
66115698
66248220
with:
TMR3_COMP10 = 1 - 1; // 6.7nS per clock = 66.7uS for 10,000 clocks on each half cycle
TMR3_CMPLD10 = 1 - 1;

For this - The 66M count is a bit better with the _isr only resetting the timer:
66655787
66661018
66658489
66652029
66660243
66658720
66649701
66660648
66653940

Freq read of :
37500179
37500170
37500174
37500174
37500173
37500176
37500176
37500173
with:
TMR3_COMP10 = 2 - 1; // 6.7nS per clock = 66.7uS for 10,000 clocks on each half cycle
TMR3_CMPLD10 = 2 - 1;
 
Yes, Pin 19 seems good for Both.

Just realized I didn't need to see the _isr toggle #14 - I just hooked #19 to #19 - one putting the time out and one counting it.

Freq Read of :

with:


For this - The 66M count is a bit better with the _isr only resetting the timer:


Freq read of :

with:

All I can say is cool - sounds like we should go ahead and implement it in FreqCount.

EDIT: If I remember to put gnd to gnd, and use @Frank B's code for freq:
Code:
  unsigned freq = 37500000; //15MHz or any other.. works up to F_BUS_ACTUAL / 2 = 75MHz (without overclocked F_BUS)
  TMR3_CMPLD10 = F_BUS_ACTUAL /2/freq - 1;
, delete the write's to the LED in the ISR on the transmitting side I get a bit different,

For freq = 37,500,000
Code:
37500063
37500062
37500063
37500062
37500062
37500062

With
Code:
  TMR3_COMP10 = 1 -1;              // 6.7nS per clock = 66.7uS for 10,000 clocks on each half cycle
  TMR3_CMPLD10 = 1 -1;
am getting:
Code:
68282367
68262393
68362798
68062886
67983771
66961227
66471841
67337636
 
Last edited:
Re: 68mhz
I don't have fast enough scope, so is PWM actually running at 75 mhz (or 68mhz) or is it the counter that is off, or ? Maybe tuning pin config (hysteresis?) would help.
 
All I can say is cool - sounds like we should go ahead and implement it in FreqCount.

EDIT: If I remember to put gnd to gnd, and use @Frank B's code for freq:
Code:
  unsigned freq = 37500000; //15MHz or any other.. works up to F_BUS_ACTUAL / 2 = 75MHz (without overclocked F_BUS)
  TMR3_CMPLD10 = F_BUS_ACTUAL /2/freq - 1;
, delete the write's to the LED in the ISR on the transmitting side I get a bit different,

For freq = 37,500,000
Code:
37500063
37500062
...

With
Code:
  TMR3_COMP10 = 1 -1;              // 6.7nS per clock = 66.7uS for 10,000 clocks on each half cycle
  TMR3_CMPLD10 = 1 -1;
am getting:
Code:
68282367
68262393
...

Variation will be T4's crystal. I'm using the original manitou QTimer code from days back - but it looks like we have the same timer counts - using the same base clock.

Last night I started two T4's doing the one sec blink {15K timer ticks with _isr telling loop to blink each 15K } and powered them at the same time and one was barely perceptibly ahead of the other as I flipped two 5V switches. When I looked this morning there was clear drift from clock diffs between the two with ONE LED full bright before the other started..
 
Re: 68mhz
I don't have fast enough scope, so is PWM actually running at 75 mhz (or 68mhz) or is it the counter that is off, or ? Maybe tuning pin config (hysteresis?) would help.

No - moved away from using analogWriteFrequency for the higher freq tests. Using TelephoneBill's QT3 code from a couple of pages back to generate the higher frequencies. Ran out of room on my desk for the scope - but before I do anything will make space and hook it up as a double check and will let you all know. Actually on hysteresis didn't it say in the RM that we should enable when using it as a clock pin?

@defragster - you are probably right with the crystal differences. Still using Beta2 boards.
 
I updated my qtmr_count.ino on github, added "manual" PWM on pin 10 up to 75mhz,
Code:
  // pin 10 PWM
  TMR1_CTRL0 = 0;  // stop  timer
  TMR1_SCTRL0 = TMR_SCTRL_OEN; // output enable
  TMR1_CNTR0 = 0;
  TMR1_LOAD0 = 0;
  TMR1_CMPLD10 = 1 - 1;
  TMR1_CSCTRL0 = TMR_CSCTRL_CL1(1);
  TMR1_CTRL0 =  TMR_CTRL_CM(1) | TMR_CTRL_PCS(8 ) | TMR_CTRL_LENGTH | TMR_CTRL_OUTMODE(3);

  //configure Teensy pin Compare output
  IOMUXC_SW_MUX_CTL_PAD_GPIO_B0_00 = 1;
and sketch is measuring 75mhz with pin 10 jumpered to 19
Code:
75000081
75000076
75000066
75000083
75000075
analogWriteFrequency() on pin 11 worked up to 50 mhz

T4B2R 1.8.8 1.47-beta4
 
Last edited:
I updated my qtmr_count.ino on github, added "manual" PWM on pin 10 up to 75mhz,
Code:
  // pin 10 PWM
  TMR1_CTRL0 = 0;  // stop  timer
  TMR1_SCTRL0 = TMR_SCTRL_OEN; // output enable
  TMR1_CNTR0 = 0;
  TMR1_LOAD0 = 0;
  TMR1_CMPLD10 = 1 - 1;
  TMR1_CSCTRL0 = TMR_CSCTRL_CL1(1);
  TMR1_CTRL0 =  TMR_CTRL_CM(1) | TMR_CTRL_PCS(8 ) | TMR_CTRL_LENGTH | TMR_CTRL_OUTMODE(3);

  //configure Teensy pin Compare output
  IOMUXC_SW_MUX_CTL_PAD_GPIO_B0_00 = 1;
and sketch is measuring 75mhz with pin 10 jumpered to 19
Code:
75000081
75000076
75000066
75000083
75000075
analogWriteFrequency() on pin 11 worked up to 50 mhz

Just gave it a try and can confirm that its working at 75Mhz - made one change to your sketch though, used this for microsecond conditional:
Code:
if (micros() - us >= 1000000) {
with that change got a bit better results:
Code:
75000002
74999997
75000002
75000000
75000003
74999996
75000009
74999994
74999998
75000003
74999998
Guess its time to reread the manual again which always gives me a headache :)

EDIT: Using pin 11 at 50Mhz
Code:
49999996
50000000
50000000
49999999
50000000
50000005
49999994
50000006
 
@mjs513 thanks for the improvement to micros() test.

I also went back to the GPT2@150mhz count sketch. analogWrite() on pin 11 also counts correctly with PWM at 50 MHZ. I then added the raw pin 10 PWM at 75mhz, and GPT2 sketch properly counts 75m ticks. But quad timer is probably the best choice for FreqCount
 
@mjs513 thanks for the improvement to micros() test.

I also went back to the GPT2@150mhz count sketch. analogWrite() on pin 11 also counts correctly with PWM at 50 MHZ. I then added the raw pin 10 PWM at 75mhz, and GPT2 sketch properly counts 75m ticks. But quad timer is probably the best choice for FreqCount

@manitou - I agree - just got my coffee and was getting ready to make the edits to use the quad timer for FreqCount. Will let you know when I get it done - still waking up here :)
 
Status
Not open for further replies.
Back
Top