Teensy 4.0 First Beta Test

[KurtE]

@Frank - Not sure what you are asking? I believe currently the beginTransaction/endTransaction does not currently setup anything distinctive. Only if you wish for it to maybe turn on an LED if it looks like you have a mismatch does it actually define and use inTransaction (#define SPI_TRANSACTION_MISMATCH_LED)

So I don't know any way to detect if you are logically in a transaction or not. As you know in libraries like ili9341_t3, we mainly use it to hopefully make sure we have the right settings, when we are doing anything to output to SPI...

If this is for ili9488 display? I was playing with one... Have not dealt with DMA yet as this display required 3 times as much memory as ILI9341 and current beta board does not have enough...

Thought about maybe trying a reduced memory (reduced color mode), where I think we only output a byte per pixel, but not sure how well that would work.

 

[PaulStoffregen]

I'm about the make the final pinout changes for the 1062 chip. Here's a final call for feedback....


First, pins I'm considering removing:

1: Pins 30-31 on the bottom side. This means giving up Serial8, for only 7 serial (plus FlexIO). I want to reserve these 2 pins (and 13 others not currently used) for FlexSPI2, so far likely to remove these 2 signals.

2: Pins 26-27 on the bottom side. This means giving up signals for a 2nd SPI port.


Pins I'm considering adding:

1: AD_B0_14+AD_B0_15 for CANFD. These both come with analog inputs, plus 1 XBAR input.

2: EMC_36+EMC_37 for CANFD. These give access to 2 channels of GPT1 timer, plus 2 XBAR inputs.

3: AD_B1_04+AD_B1_05: These have analog inputs, but not much else - but they would allow 8 continuous bits for the AD_B1 port. Whether that's useful is debatable since the GPIO registers only support 32 bit access.


Pins I'm considering moving:

1: pin 6->7, pin 7->8, pin 8->6. This would put Serial3 on the same pins whee it is on Teensy 3.x.

2: swap pins 5<->33. This would allow I2S2 to both transmit & receive on the outside pins. Unanswered question so far: to codec chips work on I2S2 if connected to I2S1's MCLK?

 

[WMXZ]

No comments on updated pin layout

 

[KurtE]

@Paul,

I know it is difficult to please everyone with so few pins available and so many things that everyone would like those pins to do.

Personally I am sort of sad to lose a 2nd SPI port, especially since I have never used CAN. But I understand that there are a lot of others that do.

One argument I remember from before is you can create an SPI object using FlexIO pins, which I have done, as part of the library: https://github.com/KurtE/FlexIO_t4
Again wonder if parts of this should make it into the mainline...

Problem is, we are finally starting to see a few more libraries, where you maybe can pass in a pointer to which SPI object to use as a way to be able to use different SPI objects without having to change libraries. The problem is that we are passing in pointer (or reference) to the SPIClass library.

Not easy for these to support both types of SPI objects as we have simple non-virtual functions that do the majority of the work, like transfer(byte):

uint8_t transfer(uint8_t data) {
		// TODO: check for space in fifo?
		port().TDR = data;
		while (1) {
			uint32_t fifo = (port().FSR >> 16) & 0x1F;
			if (fifo > 0) return port().RDR;
		}
	}

Which is directly using the SPI registers...
Obviously there are ways to solve this, like make all of these functions virtual, and have the Flex version be a sub-class. Or you could have the SPI library be hacked up, where if it is not SPI object it uses different code for each of these functions...

 

[mxxx]

Here's a final call for feedback....

fwiw, it's more questions rather than feedback:

First, pins I'm considering removing: [...]
2: Pins 26-27 on the bottom side. This means giving up signals for a 2nd SPI port.

is/will be FlexSPI2 as, say, capable as a/the second SPI port? (sorry if this was discussed previously in this thread, it's grown a bit unwieldy). lack of a second SPI port was (to me at any rate) one of the main bottlenecks of T3.2, so me too would be sad to see this go ... but i suppose like pretty much everything else that's a matter of idiosyncratic taste/needs.

Pins I'm considering moving:

1: pin 6->7, pin 7->8, pin 8->6. This would put Serial3 on the same pins whee it is on Teensy 3.x.

if that's easy to do ... i'd suspect though the number of people profiting from this will be fairly small (i can't be sure, of course, but my hunch would be that pins 7/8 more typically would be used as DOUT/DIN, not RX/TX, ie if the concern is using T.4 as a drop-in replacement for existing hardware)

 

[jmr]

Me too. Sadly, this is the largest one we could buy in a 6 sq mm package. The next largest package is 12 sq mm, and the smallest package that goes up to substantially higher capacity is 40 sq mm.

After 4.0 is released, I'm considering making a larger (and more expensive) board using this same processor, but with one of those bigger flash chips, an audio codec chip, and probably an ethernet phy chip, and some way to break out more of the I/O pins.

On this larger board, will the debug pins be available to the developer?

 

[Frank B]

Here's a final call for feedback....

1: AD_B0_14+AD_B0_15 for CANFD. These both come with analog inputs, plus 1 XBAR input.

I have no use for CAN in any flavour - and normally, in Europe if you even try to connect anything to that bus in your car, the insurance doesn't pay if you're involved in an accident.
Other uses: Hm.. still, have not needed that.

3: AD_B1_04+AD_B1_05: These have analog inputs, but not much else - but they would allow 8 continuous bits for the AD_B1 port. Whether that's useful is debatable since the GPIO registers only support 32 bit access.

Why not?


Do we need that many SERIALx? So far I haven't read of any user that needed all.
Sorry, but you asked for feedback

 

[brtaylor]

I'm about the make the final pinout changes for the 1062 chip. Here's a final call for feedback....


First, pins I'm considering removing:

1: Pins 30-31 on the bottom side. This means giving up Serial8, for only 7 serial (plus FlexIO). I want to reserve these 2 pins (and 13 others not currently used) for FlexSPI2, so far likely to remove these 2 signals.

2: Pins 26-27 on the bottom side. This means giving up signals for a 2nd SPI port.


Pins I'm considering adding:

1: AD_B0_14+AD_B0_15 for CANFD. These both come with analog inputs, plus 1 XBAR input.

2: EMC_36+EMC_37 for CANFD. These give access to 2 channels of GPT1 timer, plus 2 XBAR inputs.

3: AD_B1_04+AD_B1_05: These have analog inputs, but not much else - but they would allow 8 continuous bits for the AD_B1 port. Whether that's useful is debatable since the GPIO registers only support 32 bit access.


Pins I'm considering moving:

1: pin 6->7, pin 7->8, pin 8->6. This would put Serial3 on the same pins whee it is on Teensy 3.x.

2: swap pins 5<->33. This would allow I2S2 to both transmit & receive on the outside pins. Unanswered question so far: to codec chips work on I2S2 if connected to I2S1's MCLK?

I really like these changes. CAN-FD is something that I'm interested in using for the higher data rate transfers compared with CAN and I'm happy to have the UART bumped over to match Teensy 3.x - some of my breakout boards use that port.

 

[tonton81]

sacrificing an SPI port for the CANFD ain’t that bad, who here doesn’t know how to share the SPI bus?, unless you’d want to communicate between 2 devices at same time... I would assume that the initial boards would be a base model like a 3.2 and the t3.5/3.6 form factor later on with more pins/pads available.

 

[PaulStoffregen]

I know it is difficult to please everyone with so few pins available and so many things that everyone would like those pins to do.

Yes, so much this!

Since last summer, I've juggled so many combinations of pin decisions. This will be the very last time, and then everything we do with the 106X chips going forward will have to support this decision (or make painful sacrifices).


At this moment, I'm feeling like we should probably keep the 2 pins for the other SPI port, but something has to go for CANFD and that's going to be Serial8. I have indeed heard from some people who are really looking forward to 8 real serial ports. They're going to have to settle for FlexIO to get beyond 7. CANFD is just too important to leave out.

This means CANFD is going to end up on bottom-side pins. Not ideal for the most capable CAN port, but I don't see much alternative without sacrificing really important features already on the outside pins.

Keeping the 2nd SPI port means having no contiguous set of 8 pins on any port.


On a future larger format board, if FlexSPI2 is used (a pretty big if), it's really most useful for connecting a memory chip. Using FlexSPI as for ordinary SPI devices would be awkward, though you could set up its LUTs in some way to accomplish that. But FlexSPI is really optimized for connecting memory chips rather than ordinary SPI peripheral chips.

I'm not prepared to talk about long-term plans for debug at this time.

 

[mjs513]

Yes, so much this!

Since last summer, I've juggled so many combinations of pin decisions. This will be the very last time, and then everything we do with the 106X chips going forward will have to support this decision (or make painful sacrifices).


At this moment, I'm feeling like we should probably keep the 2 pins for the other SPI port, but something has to go for CANFD and that's going to be Serial8. I have indeed heard from some people who are really looking forward to 8 real serial ports. They're going to have to settle for FlexIO to get beyond 7. CANFD is just too important to leave out.

This means CANFD is going to end up on bottom-side pins. Not ideal for the most capable CAN port, but I don't see much alternative without sacrificing really important features already on the outside pins.

Keeping the 2nd SPI port means having no contiguous set of 8 pins on any port.


On a future larger format board, if FlexSPI2 is used (a pretty big if), it's really most useful for connecting a memory chip. Using FlexSPI as for ordinary SPI devices would be awkward, though you could set up its LUTs in some way to accomplish that. But FlexSPI is really optimized for connecting memory chips rather than ordinary SPI peripheral chips.

I'm not prepared to talk about long-term plans for debug at this time.

Just my two cents here, while not ideal to put CANFD on the bottom side and giving up serial8 its probably the best option for this size board. Would not like to give up the second SPI port either. To be honest I have never had need for 8 serial ports but that is just me. I think I have an idea why you want that though but if for future T4's its possible maybe you could recover Serial 8.

 

[KurtE]

Thanks @Paul, and for what it is worth, again I have code in the library: https://github.com/KurtE/FlexIO_t4
Where you can define a few more Serial ports if you really need them. They may not work as fully as a real hardware Serial port, but was able to do stuff with them.

 

[PaulStoffregen]

My hope is to eventually have FlexIO serial ports implemented in the SoftwareSerial library. I guess the question there is how realistic is implementing on transmit on a different FlexIO than receive?

After the switch to RT1062, we'll have 3 FlexIO modules which cover all the outside pins, except 0 & 1 which are normally used for Serial1.

 

[defragster]

REin ReMap >> If only T_3.0 had been rounded up to an even 1.5"

Are the SD pads on the bottom going to work out to be usable? [socket mountable - card accessible - enough power - current/noise interference] ? Would that area repurpose better to keep 2nd SPI and Serial8 and gain CANFD.

Moving pins for Serial3 to be 'home' sounds like fun - Was it mjs513 noting that some time back.

 

[KurtE]

I think the code in my library will already handle it (FlexIO for SoftwareSerial). I don't think there is any common need between the RX and Tx, they both require a timer and shifter and my underlying code tries to figure out which ones are free. My SPI code tries to get two on the same FlexIO module and for DMA to work they have to be on two different DMA sources. Only two channels per FLEX Io object...

Note: I have not implemented everything, only most of the basics.

 

[brtaylor]

SBUS works: https://github.com/bolderflight/SBUS

 

[nicfaust]

Hi there. Has Teensy 4.0 First Beta Test already done? Has it been released?

 

[Theremingenieur]

Hi there. Has Teensy 4.0 First Beta Test already done? Has it been released?

Beta test is ongoing. Not yet released, see https://www.pjrc.com/teensy/

 

[Frank B]

Ili9488

I played a bit with the ILI9488 Display.

With max SPI-Speed (around 66MHz - the ili9341 accepts a bit more), the max fullscreen-refresh rate I got is ~15.3Hz (65ms) :-(


Is this enough for a flicker-free display (let's say a movie)?

- The max refresh-rate of the display itself is ~90Hz (ILI9341: 119Hz)
- it does not support 16BIT colors - it wants 18 Bit (3 bytes with two LSBs= 0)
- way more pixels

- so, we have to transfer 320*480*3 bytes, = 450 KB!! for a full screen.
- we can save only 3 of such images in the flash.

Because of the high memory-usage, I'm currently working on a 256-color library.
It uses a CLUT (or some CLUTs) to translate 8BIT Palette-color to RGB.
To improve the speed, for every line it stores the minimal-x and maximal-x used pixel-coordinates if a fullscreen-update is triggered it checks these values and transfers only the pixels in between.
It is still possible to display fullRGB-pictures with sending the RGB-data to the display directly - without using the memorybuffer.

Thoughts? Is there any need for this 256-color "mode"? Does it make sense? I'm not sure..

I'm not very satisfied.. fullscreen-applications (like console-emulators, or T64) may flicker because of the slow refresh-rate, if the whole display changes its content - which is quite often the case, for example whith scrolling.

What do you think...is 15Hz enough??

(p.s. and even that only with dirty tricks like IPG-CLOCK = CPU-CLOCK / 2 - without that, its ~10Hz)

 

[KurtE]

I played a bit with the ILI9488 Display.
...
Because of the high memory-usage, I'm currently working on a 256-color library.
It uses a CLUT (or some CLUTs) to translate 8BIT Palette-color to RGB.
To improve the speed, for every line it stores the minimal-x and maximal-x used pixel-coordinates if a fullscreen-update is triggered it checks these values and transfers only the pixels in between.
It is still possible to display fullRGB-pictures with sending the RGB-data to the display directly - without using the memorybuffer.

Thoughts? Is there any need for this 256-color "mode"? Does it make sense? I'm not sure..

I'm not very satisfied.. fullscreen-applications (like console-emulators, or T64) may flicker because of the slow refresh-rate, if the whole display changes its content - which is quite often the case, for example whith scrolling.

What do you think...is 15Hz enough??

Hi Frank, I also wondered about a 256 color mode as well, but was not sure if the display has the ability to set what the 256 colors are (i.e. in the displays lookup table).

Or if there was some ability with DMA to be able to do a DMA from your logical frame buffer, through a color table to then to the display?

Now if you could go directly to the display in 256 color mode, should both reduce the memory requirements it should also speed up the drawing of the display... Where the in memory look up table would only reduce memory requirements.

 

[Frank B]

The LUT is on the teensy-side, and it's only there to reduce the memory requirements. The SPI Interface supports 18 Bits ( physically 24Bits) only ( or 8 colors only) , so I think there is no other way. A short,fast function translates this to RGB, for the current line, short before DMA for that line starts.

 

[itec]

@Frank B
I don't think 15 fps is going to be good for video, at least 25-30 fps is needed for persistence of vision or it's going to look choppy. For game and computer emulators, 50-60 fps is needed or it's just going to look like the games / demos are dropping frames. I guess the 256 color mode is a good idea to allow double buffering without clobbering memory.

 

[defragster]

This data sheet for the ILI9488
shows "5.2.34. Interface Pixel Format (3Ah) " that suggests there is a command to set display to '16 bits/pixel'. Not sure if this conflicts with or overrides hardware wiring of the device? That would go to the 565 color scheme used for the ILI9341

<edit>: So I found changed/this in the code:

writecommand(0x3A);      // Interface Pixel Format
  // writedata(0x66);    //18 bit
	writedata(0x55); 	  //16 bit

Swapped 18 for 16 and the 9488 stays all white with no other change. Posted before that the ILI9341 worked with wrong colors using the 9488 working 18 bit code and - it also works with this change to "16 bit" only now the colors are just mostly grays and a muted yellow on the Groop testText().

This is 9488 specific as my display doesn't run on T4 - KurtE indicated it worked - but not sure how mine is different as noted.

 

[Frank B]

Hi Tim,
yes I tried the 0x55, too. Does not work - and the chapter about 4-Wire SPI clearly says only 18BIT are supported.

I hope I can find 3.5" or bigger ILI9341 Display for my usage. I don't need the increased resolution.

 

[defragster]

Hi Tim,
yes I tried the 0x55, too. Does not work - and the chapter about 4-Wire SPI clearly says only 18BIT are supported.

I hope I can find 3.5" or bigger ILI9341 Display for my usage. I don't need the increased resolution.

Indeed - larger display would be nice - though the minor screen growth is dwarfed by the doubled resolution on the 3.5" 9488

Good to know my attempt was as good as yours I did not edit the library to only send 2 color bytes - but 9341 gave some pixels. The rPi mounting display I got has silkscreen saying '16/18 bit' - mjs513 got a similar/same board - but no apparent jumper or board edit to change that - I'll run those wires again and see if it works where it did not with 18 bit - though it oddly is missing the Data/Cmd pin. Somehow it works on rPi and my scan of the 9488 PDF didn't find a mode where that is not expected - I wonder if it works when held either Hi or Low? The 9488 KurtE got seemed to have a large number of external components that could/had to be edited to work - not sure if one of those sets the controller mode 16 .vs. 18?

I just found it very odd the old trusted ILI8341 displays 'something showing function' with the 9488 library - in both 16 and 18 bit modes where the 9488 goes blank. Also odd that the MISO trace to display had to be cut to use the Touch on the one I have that looks like Paul's.