Teensy 4.0 First Beta Test

Status
Not open for further replies.
@KurtE
Not sure what else I can do with combining libraries, what is left:
1. sizeofFifo for T3x
2. framebuffer
3. DMA?
 
Moved my T4 reset to 8 from 23 to match github, it works w/graphicstest.
Slow without the post #2221 ILI9488_SPICLOCK edit … not sure how fast is legal?
The graphicstest Sum time was not added :(

Not sure what the INO pics above come from?
 
Moved my T4 reset to 8 from 23 to match github, it works w/graphicstest.
Slow without the post #2221 ILI9488_SPICLOCK edit … not sure how fast is legal?
The graphicstest Sum time was not added :(

Not sure what the INO pics above come from?

Not sure with version of the lib we are talking about but the numbers are about the same as before for the T4 from what I remember. The pics in the previous post was with the updated lib with all the ILI9341_t3n changes incorporated for the T4 (t3 not operational yet) ILI9488 library that I posted on GITHUB. Might say they were debugging images.

Are you saying "you feel the need for speed...".
 
@KurtE
Not sure what else I can do with combining libraries, what is left:
1. sizeofFifo for T3x
2. framebuffer
3. DMA?

Hi @mjs513 - I pushed up a fix for hline/vline to make sure last pixel goes out _last...

Also had fix for updating clip rectangle when you set rotation, but you beat me to it.

Assuming clip/offset code as partially in place it sort of shows that some things are not clipped yet. Like the text output, fillRect, fillCircle ...

FYI - that is why there is a semi random app in the ili9341_t3n library (Kurts_Ili9341_t3n_FB_and_clip_tests), there are lots of random pieces I added to check bits and pieces of the library out. But with T4, issue that a lot of it is controlled by simple Serial.read() commands, like empty line alternated display between regular output and Framebuffer output (changed background color), but it allowed me to go back and forth to see if everything was working or not..

Then simple d<cr> line turned on or off DMA testing, and then when it was to do Frame buffer outputs, it used the Async version...
I think there was a c<cr> to turn on/off clipping rectangle o<cr> to turn on/off an offset...

My guess is probably easier for me to Fork, so we/you can more easily decide when to take in PR...

EDIT: Wonder if we should start an ILI9488 thread? since a lot of this again is not T$ specific... Probably questions on how to get DMA to work properly on it should be here.

Also I would like to get rid of some of the code that looks like:
Code:
void ILI9488_t3::begin(void)
{
    // verify SPI pins are valid;
    #ifdef KINETISK
    #if defined(__MK64FX512__) || defined(__MK66FX1M0__)
    // Allow to work with mimimum of MOSI and SCK
    if ((_mosi == 255 || _mosi == 11 || _mosi == 7 || _mosi == 28)  && (_sclk == 255 || _sclk == 13 || _sclk == 14 || _sclk == 27)) 
	#else
    if ((_mosi == 255 || _mosi == 11 || _mosi == 7) && (_sclk == 255 || _sclk == 13 || _sclk == 14)) 
    #endif	
    {
        
		if (_mosi != 255) SPI.setMOSI(_mosi);
        if (_sclk != 255) SPI.setSCK(_sclk);

        // Now see if valid MISO
	    #if defined(__MK64FX512__) || defined(__MK66FX1M0__)
	    if (_miso == 12 || _miso == 8 || _miso == 39)
		#else
	    if (_miso == 12 || _miso == 8)
	    #endif
		{	
        	SPI.setMISO(_miso);
    	} else {
			_miso = 0xff;	// set miso to 255 as flag it is bad
		}
	} else {
        return; // not valid pins...
	}
	SPI.begin();
And instead: do things like:
Code:
void ILI9488_t3::begin(void)
{
    if (SPI.pinIsMOSI(_mosi) && ((_miso ==  255) || SPI.pinIsMISO(_miso) && pinIsSCK(_sclk))
...
That is SPI now knows the valid pins, so don't have every library have to check and change for new boards....
 
@KurtE
I thought I caught it all. But just checked and you are right - missed those.

Probably right to go ahead and fork - will be easier to make changes.
 
@KurtE

Sounds like a plan about starting a ILI9488 thread otherwise this is going get bogged down like with Bluetooth.

Also, think we need to update functions like: writeRectxxBPP with write16bitcolor as well. I also left all the use_framebuffer test in the functions I changed - figured it would be easier later.

Have at it streaming lining the code, no pride of authorship here since I didn't do anything except copy and paste anyway :)
 
I am also wondering about the font text char output if it has any issues or not... Probably should try it on ILI9341 as well, but if you update my test case program like:
Code:
//=============================================================================
//=============================================================================

#include <ILI9488_t3.h>
#include <ILI9488_t3_font_Arial.h>
#define TFT_RST 8
#define TFT_DC 10
#define TFT_CS 9
ILI9488_t3 tft = ILI9488_t3(TFT_CS, TFT_DC, TFT_RST);
//=============================================================================
// Setup
//=============================================================================
void setup()
{
  tft.begin();
  tft.setRotation(3); // 180
  delay(100);

  tft.fillScreen(ILI9488_BLACK);
  delay(250);
  tft.fillScreen(ILI9488_RED);
  delay(250);
  tft.fillScreen(ILI9488_BLUE);
  delay(250);
  tft.fillScreen(ILI9488_GREEN);
  delay(250);
  tft.fillScreen(ILI9488_BLACK);
  

  drawColor(0, 0, "Red", ILI9488_RED);
  drawColor(0, 80, "Green", ILI9488_GREEN);
  drawColor(0, 160, "Blue", ILI9488_BLUE);
  drawColor(0, 240, "White", ILI9488_WHITE);

  drawColor(240, 0, "Yellow", ILI9488_YELLOW);
  drawColor(240, 80, "Orange", ILI9488_ORANGE);
  drawColor(240, 160, "Cyan", ILI9488_CYAN);
  drawColor(240, 240, "Pink", ILI9488_PINK);
}

void drawColor(uint16_t x, uint16_t y, const char *psz, uint16_t color)
{
  tft.setFontAdafruit();
  tft.setTextColor(color);
  tft.setTextSize(2);
  tft.setCursor(x,y);
  tft.print(psz);
  tft.drawRect(x+100, y, 50, 50, color);
  tft.fillRect(x+110, y+10, 30, 30, color);
  tft.drawLine(x+100, y+70,x+200, y+70, color);
  tft.drawLine(x+220, y, x+220, y+70, color);
  tft.drawLine(x+100, y+70, x+220, y, color); 
  tft.drawCircle(x+50, y+50, 30, color);
  tft.fillCircle(x+50, y+50, 20, color);  
  tft.setFont(Arial_12);
  tft.setCursor(x+160, y+50);
  tft.print(psz);
}


//=============================================================================
// Loop
//=============================================================================
void loop()
{
}
The text looks like it might be missing some pixels... Looked worse with with Arial_10...

Now to continue on new thread...

New thread for ILI9488_t3 library (https://forum.pjrc.com/threads/5573...LI9488-on-T3-x-and-beyond?p=203047#post203047)
 
@KurtE

Just updated the sketch and played around with Arial fonts and it doesn't look like it is - looked at it under a magnifier. You think the issue may be with the font being really setup for a 320x240 display vs a 480x320.

As for fifosize I did find this in the SPI library:
Code:
hardware().queue_size
Is that what you were referring to as a substitute for fifosize?
 
FYI
1.46-beta9 + regular installer 1.8.9
"Checking Arduino 1.8.8:
version: "lib/version.txt" wrong version: 1.8.9 Does not match Arduino 1.8.8
"
 
You shouldn't worry about a ticket.

Not a ticket :) … but the screen going all WHITE at about 30 minutes :( while the code was running showed something was not right when using T4 w/ SPI 48,60,64,72 MHz. It seems to work at 30 and 36 MHz on the ili9488 library thread - and the T_3.6 runs that DemoSauce code at 60 MHz for a full day with no issue.

Not sure what valid SPI clock values are expected to work … it may be the SPI clock is okay, but the other bits (CS or D/C) toggle timing it off? T4_1062 will change the equation some if I/O is really faster in use?
 
Teensy Loader; SAI audio signals; gdb debugging with SWD/JTAG

Will the Teensy 4.0 support an end-user writing new firmware into it via USB and the Teensy Loader https://www.pjrc.com/teensy/loader.html or similar?

I am interested in the Teensy 4.0 for audio work. Looking at IMXRT1060RM.pdf I see the SAI1 to SAI3 signals can be directed to various pads, but I am not sure if such pads are brought out to Teensy pins, according to the pin list in message #3.

I will be using gcc and gdb under the MCUXpresso or perhaps some other IDE:

https://www.nxp.com/support/develop...valuation-kit:MIMXRT1060-EVK?tab=In-Depth_Tab

The "Use MCUXpresso" page there mentions an inbuilt debug circuit on that development board, while the "Use Arm GCC" page mentions an SWD/JTAG connector on that board. To what extent will gdb debugging be possible with the Teensy 4.0?
 
Will the Teensy 4.0 support an end-user writing new firmware into it via USB and the Teensy Loader https://www.pjrc.com/teensy/loader.html or similar?

Yes, this is always only and unique way to write firmware into whatever Teensy.

I am interested in the Teensy 4.0 for audio work. Looking at IMXRT1060RM.pdf I see the SAI1 to SAI3 signals can be directed to various pads, but I am not sure if such pads are brought out to Teensy pins, according to the pin list in message #3.

The info is somewhere buried here in this 90 page thread. From memory not sure if all 3 SAIs will be fully brought out. Knowing that each SAI has RX and TX bit clock, frame sync and 2x data signals plus a common master clock, that makes 9 signals per SAI...

I will be using gcc and gdb under the MCUXpresso or perhaps some other IDE:

https://www.nxp.com/support/develop...valuation-kit:MIMXRT1060-EVK?tab=In-Depth_Tab

The "Use MCUXpresso" page there mentions an inbuilt debug circuit on that development board, while the "Use Arm GCC" page mentions an SWD/JTAG connector on that board. To what extent will gdb debugging be possible with the Teensy 4.0?

Moving away from the Teensyduino platform (which is a crucial part of Teensy's success because it aims at a maximum of Arduino compatibility) will drastically reduce the chances of getting competent support in these forums because most people work within that ecosystem and rarely use hardware debugging which was not officially supported up to T3.6 and I guess it won't be different for T4.0.
 
Thanks Theremingenieur for your answers. By Googling I found message #519 which mentions that SAI1 works and that there was a problem with SAI2 - which message #6 indicates is solved. I will wait for the final product documentation to find out the connection details.

Teensy 3.6 was apparently intended to support hardware debugging, but the requisite firmware was not completed, according to message #62 of https://forum.pjrc.com/threads/42728-Debugging-strategies/. Message #48 and https://mcuoneclipse.com/2017/04/29/modifying-the-teensy-3-5-and-3-6-for-arm-swd-debugging/ show how a hardware debugger can be attached to a modified Teensy 3.5 or 3.6.

I should be able to develop with an NXP dev board wired up to a DIP header with the appropriate signals to match those of the Teensy 4.0.
 
Another quick update... as usual, everything takes longer than expected. At the moment I'm working on the restore image, which is the tiny copy of a Blink+RawHID program stored in the top 4096 byte sector of the flash chip. When you hold the pushbutton for 15 seconds, after the flash is fully erased (except that top 4096 bytes), the restore program is copied to the beginning of the flash. Unlike Teensy 3.5 & 3.6 where the flash ends up blank and you have to press the button again, the idea is Teensy 4.0 gets restored to a condition that's functionally the same as when brand new.

I *finally* figured out why it wasn't working with Windows. I had misconfigured the queue head structures for the unused USB endpoints, causing it to sometimes respond to IN tokens with zero length packets, rather than a NAK token. Microsoft's HID driver *really* doesn't like that wrong behavior!

Getting the restore image into the flash chip during testing is also turning out to be quite difficult. For the 1052 beta, I used a very kludgey & labor-intensive process where I programmed a custom bootloader which writes to the top 4K, then used a hacked copy of Teensy Loader to send the data. It took a lot of fiddling, but there were only a couple dozen boards. I also never set the flash chip's lock bits, so those 4096 bytes can be erased or overwritten. This is one of so many things I planned to fix later, and now that we're getting close to release it's time to get all this stuff right.

When we ship the 1062 betas, I'm really hoping everyone will give the 15 second button press a try. My hope is this restore feature together with the red LED will finally give us a good answer to the very common question "something went wrong, is my Teensy dead, how do I revive it".
 
@Paul - Sounds great,

Looking forward to seeing the final (or near final product!) - Wondering are you thinking about doing something like KickStarter (or the other one) for this?

Just wondering.
 
... which is the tiny copy of a Blink+RawHID program stored in the top 4096 byte sector of the flash chip. When you hold the pushbutton for 15 seconds, after the flash is fully erased (except that top 4096 bytes),
...

@Paul - Sounds like good progress, and 'work' too.
Question - If EEPROM area is going to be on same Flash chip should you reserve and specify that area and not wipe it as well as that 4K during 15 sec reset?

Asked before: What if any value does the 1062 BOOT EEPROM area have? Can that be written by any chance during normal run time code?
 
fwiw / re post #4, the OSC (https://github.com/CNMAT/OSC) and MIDI libraries both work ok.

(NB: i didn't extensively test all the various options (like midi clock), and didn't test USB (yet), but sending/receiving OSC via serial/slipserial (to/from a ESP8285 thingie @ 1000000 baud, in this case) works; ditto for midi in/out (in this case, i found the nomenclature a bit confusing though ... i've tried with pins 6/7, which is serial2, though really UART4, and will be called "RX3/TX3" à la T.3x (?))
 
restore - and debug?

My hope is this restore feature together with the red LED will finally give us a good answer to the very common question "something went wrong, is my Teensy dead, how do I revive it".
That sounds like a great idea - makes it almost foolproof.
Read the recent thoughts on hardware debug - that would be super if possible. In the bad old days we took such ability for granted, but more recently I have almost forgotten what it would be like. What is the current thinking on a debugging interface and code support? I'd be willing to help with that if there was some way I could be useful.
 
1062 beta boards are shipping today to Kurt, Mike, Frank & Tim.

I have 3 more here which passed testing but still need breakout boards, and 2 more that are untested. Hoping to get those ready early next week.
 
Saw email from Robin ... Good work Paul. Excited to see it - as good as the 1052 board has been, it is hard to expect the 1062 with newer MCU to be any better - but then again it is a PJRC production :cool:
 
You'll see I've made several improvements to the breakout board.

Underneath the T4 are 8 tiny pogo pins for the native SD card, and a micro SD socket near the middle of the breakout board. If you take the T4 out of the socket, there's a chance those 8 pins won't line up again. Here's the test program I ran on each board.



EDIT: do not use this code with 1.47-beta1 or later. An updated copy is on msg #2443.


Code:
// Create 6 different frequencies on the SD card pins
// for easy testing whether all 6 signals are connected.

void setup()
{
    GPIO3_GDIR |= (0x3F << 12);
}

uint32_t n=0;

void loop()
{
    n++;
    GPIO3_DR = (GPIO3_DR & ~(0x3F << 12)) | ((n & 0x3F) << 12);
    delayMicroseconds(100);
}

I used a multimeter in frequency mode to check that all 6 signals were connected, and each was a different frequency from the other 5. I didn't test with the SD lib or any actual SD cards, only this very quick check to make sure those pins were really bringing the signals out.

You'll also see the new board has a CAN port, which connects to CAN3 (CAN FD) on pins 30 & 31. The CAN stuff is completely untested. The transceiver chip is MCP2558FD. The "S" signal connects to pin 6.

You'll see the same serial connectors on the right hand side, but there's only 7 now since we lost Serial8 to get CAN3. I only tested Serial4.

The audio lib isn't yet working on 1062. The breakout boards have an audio shield like the 1052 ones, but it's also untested.

I did test the USB host port on each board. It has the same TPS2055A chip as before.

I also added a pushbutton for the ON/OFF signal, and a green LED to show when the 3.3V power is turned on. Support for shutting off the 3.3V power is new on these 1062 boards. The 1052 boards had the 3.3V regulator permanently enabled. I hoping everyone will experiment with ON/OFF in ways I didn't anticipate!
 
Last edited by a moderator:
Status
Not open for further replies.
Back
Top