Teensy 4.0 First Beta Test

Status
Not open for further replies.
Thanks :) I've ordered 10pcs.. did not find any source in Germany, so they'll come from china in 1-2 month :(

I guess I can connect the Display-LED-backlight and a small audio-AMP to the "out"-pin, too?

Frank, doesn't digikey have a site over there that you can use? May be faster.
 
Faster yes.. but for 7x the price(10pcs incl shipping - 36€), I'm happy to wait :)
I'll add it to my boards, but I hope they work without, for a few weeks.

It sits under the T4, on the left. (Still not sure about the SD - so i've omitted it, but added a connector with all unneeded pins) - That's ok for the 1st alpha. Sound .. similar..
 
Last edited:
Has anyone tried to read/write the empty area of the SPI-Flash?
Any hints... or sample code? I don't even know where to begin...

I don't think I'llhave a problem with SD - but it will be not that easy for beginners to use the SD-Connection.. so, I'm looking for a easier solution to store some small files.
@Paul, it would be really good if the T4 supported MTP... it could be used to write code to write/read at least smaller files to the T4.. my "teensy transfer" is not really a solution (too complicated to use, and not ported so far).
I'm not looking for a "ready to use" solution - I'm willing to write all that code or help with it - but I need at least the basic minimum information how to start...
As I understand it, the T4 accesses the flash automatically, and there is a "configuration" - so, all what to do is modify this area, or create a new one?
Is there a "stub" or begun code to access the emulated eeprom?
 
Last edited:
Faster yes.. but for 7x the price(10pcs incl shipping - 36€), I'm happy to wait :)
I'll add it to my boards, but I hope they work without, for a few weeks.

It sits under the T4, on the left. (Still not sure about the SD - so i've omitted it, but added a connector with all unneeded pins) - That's ok for the 1st alpha. Sound .. similar..
when in DEU I usually buy from Digikey. If required I add some Teensies or PJRC products to exceed 50 Euro to qualify for free shipping.
It comes usually on the 3rd day after order.
 
Last edited by a moderator:
@Frank B (and @Paul) - Was not sure about posting pictures about the probable layout, although probably does not matter as the data is in the forum posts anyway...

I have not yet stated to layout my own board to play with yet. I did start on a diptrace pattern for the T4. Looks like you are setup to use Pogo pins to connect the inner pins?
So far I decided to setup to use the surface mount pins like we do for T3.x. So the holes line up with some of the outer pins. Although I am curious if I might be able to setup these pads with two holes, so I can choose later on using POGO pins or through hole. That way if I get a updated T4 beta board, I can plug it in without needing to solder it into the board...

As for SD Card, I am wondering about how to maybe setup to run something like POGO pins to the six (or 8 if you want the 3.3v and GND). That way maybe can choose to optionally install a remote SD adapter and/or use the 6 pins for other purposes. Again not sure about using SD card coming out of Front, if I also wish to use Host USB connections.

Too many distractions :)
 
ALL

Just had something strange going on with ILI9341_t3 library with the T4. I tried to do a compile and keep getting errors like:
Code:
F:\arduino-1.8.8-t4\hardware\teensy\avr\libraries\ILI9341_t3/ILI9341_t3.h:314:9: error: 'KINETISK_SPI0' was not declared in this scope
    sr = KINETISK_SPI0.SR;
Same thing happens with Arduino 1.8.9. Has anybody else seen this or do I have something strange going on?
 
ALL

Just had something strange going on with ILI9341_t3 library with the T4. I tried to do a compile and keep getting errors like:
Code:
F:\arduino-1.8.8-t4\hardware\teensy\avr\libraries\ILI9341_t3/ILI9341_t3.h:314:9: error: 'KINETISK_SPI0' was not declared in this scope
    sr = KINETISK_SPI0.SR;
Same thing happens with Arduino 1.8.9. Has anybody else seen this or do I have something strange going on?

Again unclear on what to do with this library as the T4's SPI has completely different registers (so KINETISK_SPI0 does not exist. And the IMSRT SPI registers do not have the ability to encode the logical CS pins into the logical PUSHR stack.

Note: That is not 100% correct. There is more details earlier in the thread. I have made a version of my ili9341_t3n library (T4_WIP branch), where I have done some stuff.

That is the write queue can have data elements TDR and Control elements TCR, and you can choose one of the CS pins in the TCR, (and we only have one). So I experimented with using that for DC pin and use keep the queue running about as fast as I could...

More details in the previous postings.
 
Kurt, quick question in between:
You've been working with Flexspi:
- Is it possible to realize QuadSPI with it?
- I'm planning a board - should I consider certain pins for it (which?), or doesn't it matter?

(the 8MB RAMs arrived)
 
Again unclear on what to do with this library as the T4's SPI has completely different registers (so KINETISK_SPI0 does not exist. And the IMSRT SPI registers do not have the ability to encode the logical CS pins into the logical PUSHR stack.

Note: That is not 100% correct. There is more details earlier in the thread. I have made a version of my ili9341_t3n library (T4_WIP branch), where I have done some stuff.

That is the write queue can have data elements TDR and Control elements TCR, and you can choose one of the CS pins in the TCR, (and we only have one). So I experimented with using that for DC pin and use keep the queue running about as fast as I could...

More details in the previous postings.

I been trying to get the Adafruit ILI9341 lib working with the T4 again and its failing miserably. The first thing is that the adafruit 9341 lib is a very old version and has not been updated to the latest version which I had working previously. Just loaded the new version and it is no longer working with the display I have - the display did work on the T3.5 with ili9341_t3.

So now back to debugging why it is no longer working for me with the T4. Hate these kind of problems.
 
You can try playing around with the FlexSPI code up at: https://github.com/KurtE/FlexIO_t4
Note: Each one takes two timers and two shifts... And with DMA, code is sort of tries to allocate two timers with different DMA channels, so only one FlexSPI per Flex IO controller...
 
Kurt, quick question in between:
You've been working with Flexspi:
- Is it possible to realize QuadSPI with it?
- I'm planning a board - should I consider certain pins for it (which?), or doesn't it matter?

(the 8MB RAMs arrived)

Sorry, meant FlexIO
Thank you, Kurt. Would it be restricted to special pins, or is every combination possible?
 
Sorry, meant FlexIO
Thank you, Kurt. Would it be restricted to special pins, or is every combination possible?

The current Flexio-> flexSPI class is etup where MISO, MOSI, and SCK (and CS if specified) must be on the same Flex IO controller.
So I believe on current Beta board:
FlexIO1 has (2, 3, 4, 5, 33)
FlexIO2 has (6, 7, 8, 9, 10, 11, 12, 13, 32)

When we go to 1062 board It also has a FlexIO3

Will have to see what the final pin layout for that one is:
But the early ones on Page 1 shows pins like 6,7,14-23, 26, 27
 
@Paul,

Again wondering how hard it would be to get at least a version of USB Serial limping along enough to handle some simple Serial Monitor inputs and outputs...

That is it would be nice to get it to at least the point that sketches that do things like:
Read a simple string in work. Especially those that do something as simple as:
Code:
    Serial.println("Hit any key to continue");
    while (Serial.read() == -1) ; 
    while (Serial.read() != -1);
And similar things like: while (!Serial.available()) ;
Work again.

Again I know that there are a few of us that are probably willing to do some hacking, to get it limping along until you get a chance to rewrite the whole USB system. But hints and (or better) any sketches/outlines of code would be great!

Thanks
Kurt
 
Hi Frank, hi Paul,

I now ported all emulators from the T3.6 to the T4, with the I2C keyboard support.

https://github.com/Jean-MarcHarvengt/teensyMCUME
Code can be compiled for both targets.

I also fixed the switching between DMA and non DMA mode for the ILI9341, when the touch screen is used.
I wanted to make a PCB this w-e where I could fit one of the 2 MCUs (it is pin compatible for what I use) but now my T4 does not answer anymore????
I did not do anything special...

The IDE (teensy loader) always detects the boot loader mode and no way to flash anything nor have the monitor running (the port detected is always the bootloader)
LED goes red when pressing the button. Sometimes the teensy loader shows that something is flashed (not sure what) but the IDE does not detect the port.

Any idea how I can recover the T4?

Thanks,

J-M
 
Hi Frank, hi Paul,
...
Any idea how I can recover the T4?

Thanks,

J-M

Try the 15 second T4 Button press.

With an eye on the RED bootloader LED - press the button. Start a timer and watch for 15 seconds from press then release the button ... IIRC the Red LED gives a change when the 15 second interval is recognized.

That is a clean way to wipe the T4's MCU. I've done it at least a time or two when it seems it was needed.
 
... just remembered this again. possible that the pinout on p.1 (and above code) is wrong on UART2 / CTS?

on p. 472 of the IMXRT1050RM datasheet it says CTS = AD_B1_00, which would be pin 19, right? (whereas AD_B1_01 / 18 = RTS)

I think you are probably correct. I think I took it directly from the table on Page 1 showing CTS when it was RTS...

Could change it in HardwareSerial3.cpp to pin 19 info instead.

@Paul - Does that seem correct? Want me to do a PR?
 
ILI9341 (and like displays)

Wondering what we should do for T4? As mentioned several times in this thread, the ili9341_t3 library would take a rework to run on T4 as it is highly dependent on the KinetisK SPI register set, which is very different than how the T4 SPI registers work. The biggest difference is on how the PUSHR and POPR work....

I can imagine a few different options for this:
a) Punt - make ILI9341_t3 work like the Adafruit_ili9341 library with no real speed ups...
b) Take advantage of the one hardware CS pin for DC and get a lot of the speed ups but is very limited.
c) DMA and Screen Buffer - Make a version of a library that does all of the graphic Primitives in memory and then use DMA to transfer the buffer to the display...

I know that we discussed some of this already. Also a few of us have talked about it some on the Bluetooth thread:
https://forum.pjrc.com/threads/49358-T3-6-USB-Host-Bluetooth?p=201416&viewfull=1#post201416

Note: I do have a version of my ili9341_t3n library that does both b) and c) Although in c) it currently either does continuous DMA update or on when the user says update me now. in the other thread, I also proposed a third method, of combination of both in that when you call any graphic primitive it sets the screen dirty and then starts up a screen update...

My first main question here is: Should we create a new thread for this as while it is needed to solve for T4 it can also be used on T3.5/3.6 as well. Or should we only discuss here?

Also assuming no other feed back, I may continue to hack my ILI9341_t3n library to add the on demand? Then the question will be should a version of the library be created that removes all of the code that actually updates the screen except for the DMA update? That is my current code this is a mode, where you can choose either to have a frame buffer or not...

I can imagine there are some up here who primarily want fast speed and don't care that a lot of memory is used up for buffer and I can also imagine others who would rather use this memory for something else... And I can imagine that the choice of this would be on a sketch by sketch basis...

Thoughts?
 
@KurtE
In regards to your post 2021 I think I already gave you my opinion. But like you said it all depends on what you are doing:
I can imagine there are some up here who primarily want fast speed and don't care that a lot of memory is used up for buffer and I can also imagine others who would rather use this memory for something else... And I can imagine that the choice of this would be on a sketch by sketch basis...
So it would be nice to give the user the option maybe in a single define on the way he wants the library to work.

Now on to more pressing needs. I tested you library and the latest Adafruit library with the T4 with a ILI9341 display and the graphicstest sketches they worked without a problem. Now for the interesting part.

I loaded our pacman demo onto the T4 and it ran but I went to make a change and reloaded it but it lost the serial port and hung,i.e., sketch stopped. I then tried just running the JoystickBT and the MouseBT sketches and same thing - lost USB and hung in all cases had to use the button to upload the next sketch. Tried the wired version but no data from the joystick was received, but at least didn't loose USB. I also tried the wired version on the T3.6 and that worked no problem. This is with the latest version of the USBHost_t36-BT-WIP library.

EDIT: IGNORE WHAT I WROTE ABOUT IT NOT WORKING WITH T4. I disconnected for a hour and reloaded again and it worked fine. Not sure what the problem is - maybe something didn't clear out between loads.
 
Last edited:
@mjs513 - Thanks and I think we are in agreement.

Again unless I hear otherwise, Over time, I will continue playing with my _t3n library and add in some of the additional stuff. I just wish at times that there was some clean way to build libraries with per sketch options!

Some of the next steps I will do include:
a) Maybe make a thread as again not fully specific to T4
b) Make the my _t3n/spin libraries work on T4 when DC is not pin 10. Currently DC must be pin 10 as it is the only hardware CS pin... But I will see how hard it will be to allow it to degrade (instead of just not working). Again if using DMA probably does not really matter.

c) Try adding the display is dirty, update it now support.

d) Try to figure out how different memory configurations will work with this. That is currently if you simply update memory with the graphic primitives and dma is happening in the background, I believe still with the current release, that the stuff may or may not show up on the display (write through versus...)...

With my current code, when the user is using the Update Now support, I can for example tell the memory system to update the physical memory from the cache before I start up the DMA operation. But if DMA is automatic and the user has other operations going on while this happening, this may not get done? I understand that you can configure memory to disable the cache, but not sure yet what the default memory configuration will be or should be.

@mjs513 As for Bluetooth? Might have to debug some more and see what might be failing? Could something be now writing too much to USB Serial and/or trying to read from it as I tried to remove the usage of Serial1 for debug?

I am hoping that the current level of BT support gets merged into the main library soon, and at then we might look into the next level of changes. That is support multiple PS devices connecting through the same BT device at the same time.
 
@mjs513 As for Bluetooth? Might have to debug some more and see what might be failing? Could something be now writing too much to USB Serial and/or trying to read from it as I tried to remove the usage of Serial1 for debug?

I am hoping that the current level of BT support gets merged into the main library soon, and at then we might look into the next level of changes. That is support multiple PS devices connecting through the same BT device at the same time.

@KurtE - not sure what happened that it didn't work. Think its on the T4 side though not the USBHost side. Did a bunch of testing just now and reloaded Pacman - not it hung USB> So I think the issue is T4 USB which we already know Paul is planning on reworking.
 
ILI9341 (and like displays)

Wondering what we should do for T4? As mentioned several times in this thread, the ili9341_t3 library would take a rework to run on T4 as it is highly dependent on the KinetisK SPI register set, which is very different than how the T4 SPI registers work. The biggest difference is on how the PUSHR and POPR work....

From a user point of view and not from the view of somebody who has grok'ed the internal workings of the data sheet, I would prefer that we have separate Teensy libraries with the optimizations, and not modify the Adafruit (or whatever) libraries in place. Otherwise, you get to the sad case of the ST7735, where the Teensy version of the library is 2 or 3 years out of date. Adafruit has rewritten the library to add more new displays, adding new displays based on the ST7789 chipset. Furthermore, the Adafruit-GFX library has also diverged, so that if I want the Adafruit version of the ST7735 library, I also have to not load the Teensy version of Adafruit-GFX, and use the stock version as well.

One problem of naming is whether we want the user to have to include a t3 variant of the library and a separate t4 variant, or whether we can combine them under the covers. If you combine them, then the old naming scheme of <xxx>_t3 doesn't work as well for a name. Of course <xxx>_teensy doesn't work either since the Teensy 2s are not compatible.

Also as a user, I would prefer if the display primitives in the class structure were the same as the base display (or at least there were mappings), so that I only need #ifdef's around the constructor, and not around the display primitives.

I like having an optimized version and a standard version, as long as you don't have to edit the standard files to choose which version to use (i.e. perhaps using a different constructor, perhaps using a different library). I do like fall back in the libraries, so if you don't get the pins right, it will still function as a standard display.

I would expect requiring the user to edit the library file to change the defaults, would be seen as a relic of the past, and not something we do now.

I can imagine a few different options for this:
a) Punt - make ILI9341_t3 work like the Adafruit_ili9341 library with no real speed ups...
b) Take advantage of the one hardware CS pin for DC and get a lot of the speed ups but is very limited.
c) DMA and Screen Buffer - Make a version of a library that does all of the graphic Primitives in memory and then use DMA to transfer the buffer to the display...

I know that we discussed some of this already. Also a few of us have talked about it some on the Bluetooth thread:
https://forum.pjrc.com/threads/49358-T3-6-USB-Host-Bluetooth?p=201416&viewfull=1#post201416

Note: I do have a version of my ili9341_t3n library that does both b) and c) Although in c) it currently either does continuous DMA update or on when the user says update me now. in the other thread, I also proposed a third method, of combination of both in that when you call any graphic primitive it sets the screen dirty and then starts up a screen update...

My first main question here is: Should we create a new thread for this as while it is needed to solve for T4 it can also be used on T3.5/3.6 as well. Or should we only discuss here?

Probably a new thread, as this thread is already long.

Also assuming no other feed back, I may continue to hack my ILI9341_t3n library to add the on demand? Then the question will be should a version of the library be created that removes all of the code that actually updates the screen except for the DMA update? That is my current code this is a mode, where you can choose either to have a frame buffer or not...

I can imagine there are some up here who primarily want fast speed and don't care that a lot of memory is used up for buffer and I can also imagine others who would rather use this memory for something else... And I can imagine that the choice of this would be on a sketch by sketch basis...

Thoughts?

Yes, I routinely bounce between different sketches, that each have different constraints. And at times, I even build for non-Teensys, so I like choice, at least to fall back to the standard drivers. But as a programmer, I also realize that too much choice means things can be unstable to keep working.
 
Status
Not open for further replies.
Back
Top