Teensy 4.0 First Beta Test

Status
Not open for further replies.
I tracked the mysterious serial monitor freeze to a character set decoder parsing exception within the Java code which gets data from teensy_serialmon and gives it to the serial monitor window.

Fixed with this:
https://github.com/PaulStoffregen/A...mmit/4d14510ba8d689af75356d3003c00d68da9a7f8e

I'll package up a 1.47-beta5 installer soon. I know nobody has reported this rare bug yet, but it really is annoying when it strikes.

That is great. Did the exception as it was bring itself to your attention in debugging - or did you have to come across that? Good you have the USB analyzer to show T4 was alive - did you try an alternate SerMon that would not have tripped on that?

The updated Beta5 will be welcome so all can reset on the same updated TD.

Did my look into a location for the startup_late_hook(); seem right? Except USB_Serial the system is stable then - and the clock only ticked off just under 66 ms

I just put a startup_early_hook() before the while (millis() < 20) and that shows up at 31 ms. - Lots of hardware _init after that but clocks running and CPU up to 600 MHz.
Code:
Start setup()::  E_hook millis is 31
Start setup()::  L_hook millis is 65
Start setup()::  setup millis is 300
@micros>>360017 [ms>>360] Time is Tue Jan  1 00:00:00 2019

startup.c:
Code:
void startup_default_early_hook(void) {}
void startup_early_hook(void)		__attribute__ ((weak, alias("startup_default_early_hook")));
void startup_default_late_hook(void) {}
void startup_late_hook(void)		__attribute__ ((weak, alias("startup_default_late_hook")));
__attribute__((section(".startup"), optimize("no-tree-loop-distribute-patterns"), naked))
void ResetHandler(void)
{
// …
	startup_early_hook();
	while (millis() < 20) ; // wait at least 20ms before starting USB
	usb_init();
	analog_init();
	pwm_init();
	tempmon_init();

	startup_late_hook();
	while (millis() < 300) ; // wait at least 300ms before calling user code
//…
}
 
Update to prior - I turned off the debug/printf.h :: //#define PRINT_DEBUG_STUFF

That was adding to startup time shown above. I extern "C" those hooks in my sketch and recorded the running clock values shown in the hook() code and then they are printed in setup after Serial is online.
Code:
Start setup():: E_hook millis is 1
Start setup():: L_hook millis is 45
Start setup():: setup millis is 300
@micros>>332015 [ms>>332] Time is Tue Jul  9 02:35:08 2019

There are probably reasons to move either way or add a third? I don't know what they might be - except 'printf_debug_init();' is earlier and manages to get Serial4 online for use - but those two 'stall' points represent progressively more stable times as the 1062 is brought to life, and anything done there offers a few 'free' milliseconds and sooner that setup().
 
... GPT highest clock speed available in the Clock selections (powerup de facto) to be 24 MHz. I'm trying to make 150 MHz available for counting.

@Paul - I'm still nervous about changing bit 6 which is CSCMR1[PERCLK_CLK_SEL]. I can disable the PIT module with MDIS and set GPTn_CR control modules to zero, but I'm concerned that other modules may still be using this clock signal (IPG_PERCLK_ROOT), so reluctant to attempt it as the comment in 13.7.7 is quite ominous. That note also recommends gating the clocks to modules while the change is done, and that could be laborious/error prone.

Perhaps it would be better to change this bit 6 earlier in the T4 power up ignition sequence, before any modules are activated? In which case I would wait for another Teensyduino beta release before experimenting. I think having 150 MHz available to GPT's is going to be essential for most users, so better it be done as part of Teensduino than putting T4's at risk with novice users changing it.

What do you think?
 
What do you think?

Live dangerously - go for it. :)

I've stumbled across a few surprising things that do lock up the chip, but power cycling (including VBAT removal) always brings it back. Or always has so far.

The one exception is the DC-DC converter. Look for the "danger Will Robinson" comment in the code. The chip's absolute max CPU voltage spec is 1.3V. But the hardware will allow you to go all the way up to 1.45V. I tried that on a few of the 1052 chip and got them to run at 960 MHz. It ran burning hot (no heatsink & no forced air cooling, only natural convection in still air), but surprisingly didn't die. I only abused a couple chips that way, for about a hour. Haven't tried such extreme overclocking on any 1062 chips, and really don't recommend you push the CPU voltage beyond 1.3V. Voltage over the absolute max spec probably is a real risk of damage.

But for mis-configuring the clocks, I wouldn't worry. I've done *many* very wrong things with the clocks and a full power cycle has always recovered.
 
@TelephoneBill - do either of the _hook points in #3576 look appropriate? If nothing will {affect your} change then _early should work and much more hardware still at rest if the func() names are as suggested. The systick has started and the RTC and PLL are up and running before _early() - and the ArmClock up to 600 MHz … not sure if any of those relate as prohibited or required to get the 150 MHz needed for GPT clock?

If you edit startup like above you can put this in your sketch.INO:
Code:
#ifdef __cplusplus
extern "C" {
#endif
void startup_early_hook(void) {
  // CODE HERE - No Serial 
[COLOR="#FF0000"]  // EDIT: THIS WORKS
	pinMode( LED_BUILTIN, OUTPUT);
	digitalWriteFast( LED_BUILTIN, HIGH );[/COLOR]
}

void startup_late_hook(void) {
  // CODE HERE - No Serial 
}
#ifdef __cplusplus
} // extern "C"
#endif
 
Last edited:
I believe the SYNCPIN stuff was added to allow two HALLOWINGs to work together. The HALLOWING which is a M0, with a feather pinout and a builtin TFT 128x128 display:

One thing that I've thought about is rather than using two analog pins for eye direction is to hook up two distance sensors and make the eyes track as something comes closer on one side.

Thanks for the explanation on the SYNCPIN Michael. Had the thought about figuring out a way to track objects or people. You beat me too it.
 
Well, I've had one attempt to go for it... not succeeded yet. May take a little to figure out why not. I discovered that clock gating registers can upset the IDE and monitor, but managed to recover so far.

Good ideas on the hook points... the early one seems appropriate. Once I witness the 150 MHz clock is present then will give it a shot.

One confusing item... the RM talks about "bus" clocks and "serial" clocks without explaining them. My guess is that a bus clock is one directly from the ARM bus architecture, and a serial clock might be a bus clock that goes through a pre-scaler. If anyone knows better...
 
Clocks in this chip are indeed complicated.

I tend to think of them in 4 groups.

1: ARM clock and others sync'd to it
2: RTC (aka "SNVS") 32 kHz clock
3: Direct from the 24 MHz crystal
4: Many peripheral clocks async to everything else.

The ARM clock has 2 main other clocks sync'd, the "IPG" clock which runs the bus interface to pretty much every peripheral (and is the ARM clock divided by 1, 2, 3 or 4), and the AXI clock which is always the ARM clock divided by 4 (and rarely shown or mentioned in the manual).

This big diagram from pages 1072-1073 shows how most of the async peripheral clocks are generated. The places where "OSC" or "OSC(24M)" magically appear are the direct 24 MHz crystal.

clocks.jpg
 
150 MHz now available for GPT's

Success now with 150 MHz peripheral clock available to GPT1 and GPT2, using bit 6 = 0 for CCM_CSCMR1[PRECLK_CLK_SEL]. I gated/stopped both GPT2 clocks CG13, CG12 of CCM_CCGR0, also GPT1 clocks CG11,CG10 of CCM_CCGR1 while the change was made, then reinstated them directly afterwards. Probably ought to stop PIT clocks on CG6 of CCM_CCGR1 as well, but did not for the tests.

There are 5 options for clock source select for the two GPTn_CR control registers. Option 0 = no clock. 1 = Peripheral Clock, 2 = High Frequency Reference Clock. These options 1 and 2 seem to be exactly the same, but it is possible that one of them is via a 6 bit prescaler (I have yet to check). When bit 6 previous is not changed then they are both 24 MHz, and when changed to zero they are both 150 MHz. Option 3 has been tested elsewhere so works and requires use of an external pin pad underneath. Option 4 was a surprise = Low Freq Reference Clock of 32KHz. I thought this might have been the RTC crystal but can't see one fitted - perhaps its derived from one of the bus clocks. It was available when I had either 24 MHz or 150 MHz on the 1,2 options. Option 5 should be using the 24 MHz crystal osc direct, but did not work on my test (GPT1 and GPT2 not counting). There may be a gate elsewhere that needs opening.

I did try close/stop all the gates on CCGR0 and CCGR1 (save, zero both registers, then restore) but that won't work as it interferes with the Serial Monitor. So am still wondering if there are more clock gates that should be closed before changing bit 6. The clock diagram (page 1072) only refers to GPT and PIT.
 
Sorry for my absence.
Are there open Audio-issues not mentioned on the 1st page? There are still some not implemented things. I'll try to add some of them and want to fix bugs if there are any.
 
@mjs513 and whoever might have an Adafruit OLED ssd1351...

I made a first pass through the SSD1351 library (shows up as teensy_ssd1351). I hope I have most of the pieces in place. Their simple program compiles. I don't have the display yet (should be here later today)...

Put WIP branch up at: https://github.com/KurtE/teensy_ssd1351/tree/t4_beta

I can try it tonight when I get home.

I'm wondering whether maybe the files should be renamed so that it can co-exist with the standard library from Adafruit. I.e. lets try to not repeat the ST7735 mess.
 
I can try it tonight when I get home.

I'm wondering whether maybe the files should be renamed so that it can co-exist with the standard library from Adafruit. I.e. lets try to not repeat the ST7735 mess.

Thanks Michael,

My package from Amazon arrived today... The one I ordered was not Adafruit... Looks like I need to do some debugging... The good news is that the Adafruit library worked (at least their example test), with no changes except changing pin numbers...

But looks like the teensy_ssd1351 code now needs to be debugged. Appears to hang/crash in begin...

But the interesting part is that I am not sure this library was ever tested with 128x128 display.

As for names, I forked the library: https://github.com/kirberich/teensy_ssd1351 Which I believe is where @Paul gets it for the Teensyduino install?

Also may take me awhile as it is using those no fangled things like templates ;)
 
Success now with 150 MHz peripheral clock available to GPT1 and GPT2, using bit 6 = 0 for CCM_CSCMR1[PRECLK_CLK_SEL]. I gated/stopped both GPT2 clocks CG13, CG12 of CCM_CCGR0, also GPT1 clocks CG11,CG10 of CCM_CCGR1 while the change was made, then reinstated them directly afterwards. Probably ought to stop PIT clocks on CG6 of CCM_CCGR1 as well, but did not for the tests.

There are 5 options for clock source select for the two GPTn_CR control registers. Option 0 = no clock. 1 = Peripheral Clock, 2 = High Frequency Reference Clock. These options 1 and 2 seem to be exactly the same, but it is possible that one of them is via a 6 bit prescaler (I have yet to check). When bit 6 previous is not changed then they are both 24 MHz, and when changed to zero they are both 150 MHz. Option 3 has been tested elsewhere so works and requires use of an external pin pad underneath. Option 4 was a surprise = Low Freq Reference Clock of 32KHz. I thought this might have been the RTC crystal but can't see one fitted - perhaps its derived from one of the bus clocks. It was available when I had either 24 MHz or 150 MHz on the 1,2 options. Option 5 should be using the 24 MHz crystal osc direct, but did not work on my test (GPT1 and GPT2 not counting). There may be a gate elsewhere that needs opening.

The NXP SDK has examples using the GPT when clocked from Peripheral clock @150mhz. Of course, SDK core structure is much different from Teensy core. The SDK also has a "clock configuration" gui that is supposed to aid you in setting up various 1050/1060 clocks as described in the "daunting" clock tree in the reference manual!

T4 is fitted with 32khz crystal, and i've used GPT with GPS PPS to measure drift of either the 24 mhz crystal or the 32khz crystal, see
https://github.com/manitou48/teensy4/blob/master/gpsgpt.ino

anecdotal T4 crystal drifts

EDIT: with battery hooked up to VBAT, RTC with the 32khz crystal will keep on ticking even when no power to T4.
 
Last edited:
@Frank B
I just received the T4 beta today so I'm playing catch up.
Is there a new version of your setI2SFreq function - I can't find any mention of it in this thread? I need to set the audio frequency to 12kHz to get my FT4 encoder working with the audio board on the T4. I've added 12kHz to it for PLL frequencies up to 240MHz but don't know how to handle it with T4.

Pete
 
Thanks Michael,

My package from Amazon arrived today... The one I ordered was not Adafruit... Looks like I need to do some debugging... The good news is that the Adafruit library worked (at least their example test), with no changes except changing pin numbers...

But looks like the teensy_ssd1351 code now needs to be debugged. Appears to hang/crash in begin...

But the interesting part is that I am not sure this library was ever tested with 128x128 display.

As for names, I forked the library: https://github.com/kirberich/teensy_ssd1351 Which I believe is where @Paul gets it for the Teensyduino install?

Also may take me awhile as it is using those no fangled things like templates ;)
Fixed (I think) - At least it appears to run in both buffered and non-buffered mode.

Note: I modified his objects in the example app, to specify 128x 128 and which pins I am using...

// Choose display buffering - NoBuffer or SingleBuffer currently supported
// auto display = ssd1351::SSD1351<Color, ssd1351::NoBuffer, 128, 128>(10, 9, 23);
auto display = ssd1351::SSD1351<Color, ssd1351::SingleBuffer, 128, 128>(10, 9, 23);

So far I have only tried on T4... If anyone wishes to try it out before I try to issue a PR that would be great.
https://github.com/KurtE/teensy_ssd1351/tree/t4_beta

Edit: Also tested (and fixed) running on T3.6
 
Last edited:
Teensy 4.0 cards came in today's mail - they look great - and they are cut the same size as all the others - the stack is getting bigger with 6 of them. {LC, 3.1, 3.2, 3.5, 3.6 and now Teensy 4 }



EDIT: with battery hooked up to VBAT, RTC with the 32khz crystal will keep on ticking even when no power to T4.

Note - with enough (2 or 3?) active Serial# UART pins powered the RTC also stays ticking { likely the same with enough other pullup pins if they present enough current } - even without VBat, Vin or USB power.
>> 2nd breakout Inactive 7 connected Serial ports does not keep RTC active - when those 7 UART ports of 14 pins are active from the second T4 in this case and powered it feeds enough power to keep the RTC section ticking. But the Brownout problem is fixed with White wire or later PCB and Teensy for uploads and functions as desired.

Also Note: When the RTC segment is powered { VBat or per Note above } - also active is the Power Button logic! That is an unpowered T4 with active RTC will maintain or change Power state OFF>ON or ON>OFF and when powered will come up at the prior state - or the changed Power state.
 
Audio Lib use of PT8211 fails on IDE 1.89 TD1.46 {b1} but works on IDE1.88 TD1.45 {b2} - when tested with a T_3.5

So PT8211 does not work on T4 { or T_3.5 } with TD1.47 current Beta on IDE 1.89

>> Assuming the PT8211 pins to Beta Breakout headers are correct for PT8211?

Post Here has perhaps more detail { and a simple sketch } with T_3.2 user noting failure after TD upgrade : PT8211-Not-Working-After-Upgrade-to-Arduino-IDE-1-8-9-and-Teensy-Loader-1-46 is where I tested my freshly assembled PT8211 I ordered from PJRC when the T4B1 shipped.

GOOD NEWS is the PJRC AUDIO board on T4 { and T3.5 } worked on the same Sketches as noted in that post - Also great that I ordered that kit and soldered it to work on the T_3.5 with TD1.45 so I know it works for T4 testing

>> Added to Post #6

Frank B: bringing this forward for your review.

EDIT: Seems I also had trouble getting Audio Add on FLASH chip access to work - if so I posted here - but not sure when/where
 
@mjs513 and whoever might have an Adafruit OLED ssd1351...

I made a first pass through the SSD1351 library (shows up as teensy_ssd1351). I hope I have most of the pieces in place. Their simple program compiles. I don't have the display yet (should be here later today)...

Put WIP branch up at: https://github.com/KurtE/teensy_ssd1351/tree/t4_beta

Hmmm, I downloaded it, and tried it on my system, and got:

Code:
In file included from /home/meissner/Arduino/Tests/Oled/Oled_128x128_KurtE/Oled_128x128_KurtE.ino:3:0:
/home/meissner/Arduino/libraries/ssd1351/ssd1351.h: In member function 'void ssd1351::SSD1351<C, B, W, H>::waitFifoNotFull()':
/home/meissner/Arduino/libraries/ssd1351/ssd1351.h:708:9: error: 'KINETISK_SPI0' was not declared in this scope
    sr = KINETISK_SPI0.SR;
         ^
/home/meissner/Arduino/libraries/ssd1351/ssd1351.h: In member function 'void ssd1351::SSD1351<C, B, W, H>::waitTransmitComplete(uint32_t)':
/home/meissner/Arduino/libraries/ssd1351/ssd1351.h:716:18: error: 'KINETISK_SPI0' was not declared in this scope
    uint32_t sr = KINETISK_SPI0.SR;
                  ^
/home/meissner/Arduino/libraries/ssd1351/ssd1351.h:717:13: error: 'SPI_SR_EOQF' was not declared in this scope
    if (sr & SPI_SR_EOQF) break;  // wait for last transmit
             ^
/home/meissner/Arduino/libraries/ssd1351/ssd1351.h:720:3: error: 'KINETISK_SPI0' was not declared in this scope
   KINETISK_SPI0.SR = SPI_SR_EOQF;
   ^
/home/meissner/Arduino/libraries/ssd1351/ssd1351.h:720:22: error: 'SPI_SR_EOQF' was not declared in this scope
   KINETISK_SPI0.SR = SPI_SR_EOQF;
                      ^
/home/meissner/Arduino/libraries/ssd1351/ssd1351.h:721:3: error: 'SPI0_MCR' was not declared in this scope
   SPI0_MCR = mcr;
   ^
/home/meissner/Arduino/libraries/ssd1351/ssd1351.h: In member function 'void ssd1351::SSD1351<C, B, W, H>::sendCommandAndContinue(uint8_t)':
/home/meissner/Arduino/libraries/ssd1351/ssd1351.h:728:3: error: 'KINETISK_SPI0' was not declared in this scope
   KINETISK_SPI0.PUSHR = command | (pcs_command << 16) | SPI_PUSHR_CTAS(0) | SPI_PUSHR_CONT;
   ^
/home/meissner/Arduino/libraries/ssd1351/ssd1351.h:728:73: warning: there are no arguments to 'SPI_PUSHR_CTAS' that depend on a template parameter, so a declaration of 'SPI_PUSHR_CTAS' must be available [-fpermissive]
   KINETISK_SPI0.PUSHR = command | (pcs_command << 16) | SPI_PUSHR_CTAS(0) | SPI_PUSHR_CONT;
                                                                         ^
/home/meissner/Arduino/libraries/ssd1351/ssd1351.h:728:77: error: 'SPI_PUSHR_CONT' was not declared in this scope
   KINETISK_SPI0.PUSHR = command | (pcs_command << 16) | SPI_PUSHR_CTAS(0) | SPI_PUSHR_CONT;
                                                                             ^
/home/meissner/Arduino/libraries/ssd1351/ssd1351.h: In member function 'void ssd1351::SSD1351<C, B, W, H>::sendLastCommand(uint8_t)':
/home/meissner/Arduino/libraries/ssd1351/ssd1351.h:732:18: error: 'SPI0_MCR' was not declared in this scope
   uint32_t mcr = SPI0_MCR;
                  ^
/home/meissner/Arduino/libraries/ssd1351/ssd1351.h:733:3: error: 'KINETISK_SPI0' was not declared in this scope
   KINETISK_SPI0.PUSHR = command | (pcs_command << 16) | SPI_PUSHR_CTAS(0) | SPI_PUSHR_EOQ;
   ^
/home/meissner/Arduino/libraries/ssd1351/ssd1351.h:733:73: warning: there are no arguments to 'SPI_PUSHR_CTAS' that depend on a template parameter, so a declaration of 'SPI_PUSHR_CTAS' must be available [-fpermissive]
   KINETISK_SPI0.PUSHR = command | (pcs_command << 16) | SPI_PUSHR_CTAS(0) | SPI_PUSHR_EOQ;
                                                                         ^
/home/meissner/Arduino/libraries/ssd1351/ssd1351.h:733:77: error: 'SPI_PUSHR_EOQ' was not declared in this scope
   KINETISK_SPI0.PUSHR = command | (pcs_command << 16) | SPI_PUSHR_CTAS(0) | SPI_PUSHR_EOQ;
                                                                             ^
/home/meissner/Arduino/libraries/ssd1351/ssd1351.h: In member function 'void ssd1351::SSD1351<C, B, W, H>::sendDataAndContinue(uint8_t)':
/home/meissner/Arduino/libraries/ssd1351/ssd1351.h:738:3: error: 'KINETISK_SPI0' was not declared in this scope
   KINETISK_SPI0.PUSHR = data | (pcs_data << 16) | SPI_PUSHR_CTAS(0) | SPI_PUSHR_CONT;
   ^
/home/meissner/Arduino/libraries/ssd1351/ssd1351.h:738:67: warning: there are no arguments to 'SPI_PUSHR_CTAS' that depend on a template parameter, so a declaration of 'SPI_PUSHR_CTAS' must be available [-fpermissive]
   KINETISK_SPI0.PUSHR = data | (pcs_data << 16) | SPI_PUSHR_CTAS(0) | SPI_PUSHR_CONT;
                                                                   ^
/home/meissner/Arduino/libraries/ssd1351/ssd1351.h:738:71: error: 'SPI_PUSHR_CONT' was not declared in this scope
   KINETISK_SPI0.PUSHR = data | (pcs_data << 16) | SPI_PUSHR_CTAS(0) | SPI_PUSHR_CONT;
                                                                       ^
/home/meissner/Arduino/libraries/ssd1351/ssd1351.h: In member function 'void ssd1351::SSD1351<C, B, W, H>::sendLastData(uint8_t)':
/home/meissner/Arduino/libraries/ssd1351/ssd1351.h:742:18: error: 'SPI0_MCR' was not declared in this scope
   uint32_t mcr = SPI0_MCR;
                  ^
/home/meissner/Arduino/libraries/ssd1351/ssd1351.h:743:3: error: 'KINETISK_SPI0' was not declared in this scope
   KINETISK_SPI0.PUSHR = data | (pcs_data << 16) | SPI_PUSHR_CTAS(0) | SPI_PUSHR_EOQ;
   ^
Multiple libraries were found for "ssd1351.h"
 Used: /home/meissner/Arduino/libraries/ssd1351
 Not used: /rock/shared/arduino/teensy-1.47beta4-1.8.9/hardware/teensy/avr/libraries/ssd1351
/home/meissner/Arduino/libraries/ssd1351/ssd1351.h:743:67: warning: there are no arguments to 'SPI_PUSHR_CTAS' that depend on a template parameter, so a declaration of 'SPI_PUSHR_CTAS' must be available [-fpermissive]
   KINETISK_SPI0.PUSHR = data | (pcs_data << 16) | SPI_PUSHR_CTAS(0) | SPI_PUSHR_EOQ;
                                                                   ^
/home/meissner/Arduino/libraries/ssd1351/ssd1351.h:743:71: error: 'SPI_PUSHR_EOQ' was not declared in this scope
   KINETISK_SPI0.PUSHR = data | (pcs_data << 16) | SPI_PUSHR_CTAS(0) | SPI_PUSHR_EOQ;
                                                                       ^
/home/meissner/Arduino/libraries/ssd1351/ssd1351.h: In member function 'void ssd1351::SSD1351<C, B, W, H>::sendDataAndContinue16(uint16_t)':
/home/meissner/Arduino/libraries/ssd1351/ssd1351.h:747:3: error: 'KINETISK_SPI0' was not declared in this scope
   KINETISK_SPI0.PUSHR = data | (pcs_data << 16) | SPI_PUSHR_CTAS(1) | SPI_PUSHR_CONT;
   ^
/home/meissner/Arduino/libraries/ssd1351/ssd1351.h:747:67: warning: there are no arguments to 'SPI_PUSHR_CTAS' that depend on a template parameter, so a declaration of 'SPI_PUSHR_CTAS' must be available [-fpermissive]
   KINETISK_SPI0.PUSHR = data | (pcs_data << 16) | SPI_PUSHR_CTAS(1) | SPI_PUSHR_CONT;
                                                                   ^
/home/meissner/Arduino/libraries/ssd1351/ssd1351.h:747:71: error: 'SPI_PUSHR_CONT' was not declared in this scope
   KINETISK_SPI0.PUSHR = data | (pcs_data << 16) | SPI_PUSHR_CTAS(1) | SPI_PUSHR_CONT;
                                                                       ^
/home/meissner/Arduino/libraries/ssd1351/ssd1351.h: In member function 'void ssd1351::SSD1351<C, B, W, H>::sendLastData16(uint16_t)':
/home/meissner/Arduino/libraries/ssd1351/ssd1351.h:751:18: error: 'SPI0_MCR' was not declared in this scope
   uint32_t mcr = SPI0_MCR;
                  ^
/home/meissner/Arduino/libraries/ssd1351/ssd1351.h:752:3: error: 'KINETISK_SPI0' was not declared in this scope
   KINETISK_SPI0.PUSHR = data | (pcs_data << 16) | SPI_PUSHR_CTAS(1) | SPI_PUSHR_EOQ;
   ^
/home/meissner/Arduino/libraries/ssd1351/ssd1351.h:752:67: warning: there are no arguments to 'SPI_PUSHR_CTAS' that depend on a template parameter, so a declaration of 'SPI_PUSHR_CTAS' must be available [-fpermissive]
   KINETISK_SPI0.PUSHR = data | (pcs_data << 16) | SPI_PUSHR_CTAS(1) | SPI_PUSHR_EOQ;
                                                                   ^
/home/meissner/Arduino/libraries/ssd1351/ssd1351.h:752:71: error: 'SPI_PUSHR_EOQ' was not declared in this scope
   KINETISK_SPI0.PUSHR = data | (pcs_data << 16) | SPI_PUSHR_CTAS(1) | SPI_PUSHR_EOQ;
                                                                       ^
/home/meissner/Arduino/libraries/ssd1351/ssd1351.h: In instantiation of 'void ssd1351::SSD1351<C, B, W, H>::sendCommandAndContinue(uint8_t) [with C = ssd1351::HighColor; B = ssd1351::SingleBuffer; int W = 128; int H = 128; uint8_t = unsigned char]':
/home/meissner/Arduino/libraries/ssd1351/ssd1351.h:152:25:   required from 'void ssd1351::SSD1351<C, B, W, H>::begin() [with C = ssd1351::HighColor; B = ssd1351::SingleBuffer; int W = 128; int H = 128]'
/home/meissner/Arduino/Tests/Oled/Oled_128x128_KurtE/Oled_128x128_KurtE.ino:40:17:   required from here
/home/meissner/Arduino/libraries/ssd1351/ssd1351.h:728:71: error: 'SPI_PUSHR_CTAS' was not declared in this scope
   KINETISK_SPI0.PUSHR = command | (pcs_command << 16) | SPI_PUSHR_CTAS(0) | SPI_PUSHR_CONT;
                                                                       ^
/home/meissner/Arduino/libraries/ssd1351/ssd1351.h: In instantiation of 'void ssd1351::SSD1351<C, B, W, H>::sendDataAndContinue(uint8_t) [with C = ssd1351::HighColor; B = ssd1351::SingleBuffer; int W = 128; int H = 128; uint8_t = unsigned char]':
/home/meissner/Arduino/libraries/ssd1351/ssd1351.h:153:22:   required from 'void ssd1351::SSD1351<C, B, W, H>::begin() [with C = ssd1351::HighColor; B = ssd1351::SingleBuffer; int W = 128; int H = 128]'
/home/meissner/Arduino/Tests/Oled/Oled_128x128_KurtE/Oled_128x128_KurtE.ino:40:17:   required from here
/home/meissner/Arduino/libraries/ssd1351/ssd1351.h:738:65: error: 'SPI_PUSHR_CTAS' was not declared in this scope
   KINETISK_SPI0.PUSHR = data | (pcs_data << 16) | SPI_PUSHR_CTAS(0) | SPI_PUSHR_CONT;
                                                                 ^
/home/meissner/Arduino/libraries/ssd1351/ssd1351.h: In instantiation of 'void ssd1351::SSD1351<C, B, W, H>::sendLastCommand(uint8_t) [with C = ssd1351::HighColor; B = ssd1351::SingleBuffer; int W = 128; int H = 128; uint8_t = unsigned char]':
/home/meissner/Arduino/libraries/ssd1351/ssd1351.h:189:18:   required from 'void ssd1351::SSD1351<C, B, W, H>::begin() [with C = ssd1351::HighColor; B = ssd1351::SingleBuffer; int W = 128; int H = 128]'
/home/meissner/Arduino/Tests/Oled/Oled_128x128_KurtE/Oled_128x128_KurtE.ino:40:17:   required from here
/home/meissner/Arduino/libraries/ssd1351/ssd1351.h:733:71: error: 'SPI_PUSHR_CTAS' was not declared in this scope
   KINETISK_SPI0.PUSHR = command | (pcs_command << 16) | SPI_PUSHR_CTAS(0) | SPI_PUSHR_EOQ;
                                                                       ^
/home/meissner/Arduino/libraries/ssd1351/ssd1351.h: In instantiation of 'void ssd1351::SSD1351<C, B, W, H>::sendLastData(uint8_t) [with C = ssd1351::HighColor; B = ssd1351::SingleBuffer; int W = 128; int H = 128; uint8_t = unsigned char]':
/home/meissner/Arduino/libraries/ssd1351/ssd1351_highcolor.inl:17:15:   required from 'void ssd1351::SSD1351<C, B, W, H>::pushColor(const C&, bool) [with bool HiddenMemberBool = true; typename std::enable_if<(HiddenMemberBool && (std::is_same<C, ssd1351::HighColor>::value)), int>::type <anonymous> = 0; C = ssd1351::HighColor; B = ssd1351::SingleBuffer; int W = 128; int H = 128]'
/home/meissner/Arduino/libraries/ssd1351/ssd1351_singlebuffer.inl:26:13:   required from 'void ssd1351::SSD1351<C, B, W, H>::updateScreen() [with bool HiddenMemberBool = true; typename std::enable_if<(HiddenMemberBool && (std::is_same<B, ssd1351::SingleBuffer>::value)), int>::type <anonymous> = 0; C = ssd1351::HighColor; B = ssd1351::SingleBuffer; int W = 128; int H = 128]'
/home/meissner/Arduino/Tests/Oled/Oled_128x128_KurtE/Oled_128x128_KurtE.ino:71:24:   required from here
/home/meissner/Arduino/libraries/ssd1351/ssd1351.h:743:65: error: 'SPI_PUSHR_CTAS' was not declared in this scope
   KINETISK_SPI0.PUSHR = data | (pcs_data << 16) | SPI_PUSHR_CTAS(0) | SPI_PUSHR_EOQ;
                                                                 ^
In file included from /home/meissner/Arduino/Tests/Oled/Oled_128x128_KurtE/Oled_128x128_KurtE.ino:3:0:
/home/meissner/Arduino/libraries/ssd1351/ssd1351.h: At global scope:
/home/meissner/Arduino/libraries/ssd1351/ssd1351.h:35:59: warning: always_inline function might not be inlinable [-Wattributes]
 template <typename T> void __attribute__((always_inline)) swap(T &a, T &b) {
                                                           ^
Using library SPI at version 1.0 in folder: /rock/shared/arduino/teensy-1.47beta4-1.8.9/hardware/teensy/avr/libraries/SPI 
Using library ssd1351 at version 1.0 in folder: /home/meissner/Arduino/libraries/ssd1351 
Error compiling for board Teensy 4-Beta2.

Note, these errors were caused by the directory hardware/teensy/avr/libraries/ssd1351. When I removed it from the teensy release directory, and used the t4_beta branch instead of the normal trunk branch, it did compile fine (other than the warning about the swap templated function). I'll try to try it tomorrow on the board.

I also tried it on my Teensy 3.5. There it compiles fine. I changed the program to use my defaults (CS = A9, DC = A1, RESET = A0, MOSI = 11, and SCLK = 13), and changed the size to 128x128. The 3.5 is setup for uncanny eyes, so it has one display on A9 and one on A8, but both displays show the same contents. I switched the CS to A8 instead of A9, and I get the same thing.

I also tried the fonts example, and it displays fonts, but again on both screens.

<edit>
I just realized I need to set the other pins that might be used for CS on the other display high so that only one display gets chosen. Note with the SSD1351, you need to set the CS pins HIGH when the display isn't active.
 
Last edited:
Note I was running into issues where the IDE would pick the copy of the library out of the Tensyduino install instead of the one in your libraries folder. I resolved it by deleting the teensyduino copy
 
Odd - every time I've looked at that it does it right:
Using library SPI at version 1.0 in folder: /rock/shared/arduino/teensy-1.47beta4-1.8.9/hardware/teensy/avr/libraries/SPI
Using library ssd1351 at version 1.0 in folder: /home/meissner/Arduino/libraries/ssd1351

That looks like it bypassed the private copy … if it was in : /home/meissner/Arduino/libraries
 
Odd - every time I've looked at that it does it right:


That looks like it bypassed the private copy … if it was in : /home/meissner/Arduino/libraries

My setup is somewhat weird, in that I have a perl script to link stuff into /home/meissner/Arduino/libraries depending on various options. I may have linked to the wrong directory, so the file may not have been there, so it found the standard version. But there are times, when it seems to pick up the Teensy/arduino version and not the version in the private directory.
 
Status
Not open for further replies.
Back
Top