Teensy 4.0 First Beta Test

Status
Not open for further replies.
Hi Kurt,

My experience with the ILI9341 and the T4 (and T3.6 BTW) is that it is nice to switch between DMA and non DMA mode within your application.
As the ILI9341 has both SD card reader and touch screen, you also want to use them.
On the T3.6 I have used SDIO for SD card reading and one single SPI bus to both DISPLAY and touch HW.
When DMA is used for the display, Touch cannot be used. When I need to use the touch screen, I switched to non DMA.
The ili9341_t_dma version I use for my emulator ports supports both ( see any emulator in https://github.com/Jean-MarcHarvengt/teensyMCUME)
If I want to stop DMA, I use the stopDMA() method and use the non DMA GFX functions and the touch functions. If I need the DMA I call startDMA() again.

On the T4, I had some issue because I also use the SD of the ILI. So I have on a single SPI bus of the T4 3 devices.
I noticed that after a stopDMA() I have to reset the SD library to use SD card and the display in non DMA. I think it has to do with the CS of the SD or the SPI speed of the SD library. Calling the SD.begin(cs) is enough as a work around.
(note that I never used the touch screen at same time because just linking the SCK line is loading the bus. I need to check with a scope)

I don't think having a task running the DMA transfert in a loop has an added value
The DMA interrupt does it anyway... (on the ESP32 I used that method BTW)

That is just my opinion.

I noticed that the 1062 had also a 2D GFX accelerator block.
I was thinking about start using it to speedup draw operations in the DMA frame buffer.
Unfortunately it seems only to support 32bit RGB as destination or YUV.
Anyone tried?
 
BTW, I have again the same issue with the T4.
No serial port detected at usb plug in.
Button pressed for 15 secs, red LED for few secs (intensive light)

But after, no sign of live.
short press on button show light red LED for 1 or 2 secs but no port detected.

;-(
 
Paul - was there by any chance a T4 bootloader update in the last beta10 TeensyLoader? I didn't see signs of it - just wondering.

Jean-Marc: what OS? What SerMon - the IDE?
I've been mostly otherwise engaged since the quick test on the Beta 10 release.
For weeks prior I've been (on Windows) using TyCommander almost exclusively within SublimeText and the TSet mods I made to auto create FrankB's Compile.cmd to start the IDE Builder from CmdLine (as sublime runs it and parses errors), and seeing no issues.
With parallel some testing of T4 and T_3.6 on the USBHost thread it was mostly T_3.6 - and like @mjs513 returning to do a USBHost confirmation test on T4 - I got some odd results and ended up doing a 15 second T4 reset myself and then it worked.
With the T4's USB where it is I have two T_3.1's for Serial UART debug on the T4, and a T_3.6 on the T_3.6 for UART Debug - and another T_3.6 and T_3.5 for display/touch testing.

I did use the IDE w/beta10 for minimal testing and found it to work as noted - but mostly just to compile and upload and see proper function.

Though eschewing the IDE as the SerMon with so many Teensy's online was short on needed sermon connectivity - and was more reliable and deterministic with TyComm handling the serial monitor and upload duties for 5 or more active Teensy's when I took IDE and TeensyLoader [t_sermon,t_ports] out of the loop. But that isn't news as I've been a TyComm(TyQt) fan for years now given that I always find a reason to have 2 or more Teensys online.

I gave KurtE feedback on the other thread about display - indeed each sketch may have unique needs. So ALL or Everything would be ideal :) As noted by Jean-Marc selective DMA with manual update would be needed with shared SPI, and tracking 'dirty' in display funcs to allow DMA_update to skip when not needed would allow it to be part of loop() processing - as noted on other thread.
 
I am using MacOS 10.13.6 with Arduino IDE 1.8.5.
I did not try if the behavior was different with another OS as the T3.6 is still recognized correctly. Only the T4 is giving issues.
Thanks!
 
I am using MacOS 10.13.6 with Arduino IDE 1.8.5.
I did not try if the behavior was different with another OS as the T3.6 is still recognized correctly. Only the T4 is giving issues.
Thanks!

Is the 'optionally provided' PJRC T4 Breakoutboard in use? If so make sure the T4 is seated firmly into the POGO pins as they push up and unseat the T4 and that causes issues.

Just to exhaust the chance you might download a copy of TyCommander and see if it sees anything different. It can show up as just SerMon and will identify devices it can see on USB. Given an appropriate HEX file it can upload to T4 when the TeensyLoader is not active to a visible Teensy. And has a GUI button for reset and bootloader - if the device is visible. And with the step of 'integrate to Arduino' will update the IDE when restarted to use TyComm to upload rather than TeensyLoader. That will either work if the confusion is in the IDE tools - or also not work if the problem is in the cable/port/OS or T4.
 
BTW, I have again the same issue with the T4.
No serial port detected at usb plug in.
Button pressed for 15 secs, red LED for few secs (intensive light)

But after, no sign of live.
short press on button show light red LED for 1 or 2 secs but no port detected.

;-(

@Jean-Marc. After reset try loading the blink sketch - you will probably have to press the reset key. It should then find the port. At least that was what worked for me. If not sure.
 
@tonton81, @manitou and @JBeale
Just ran a quick test and on pad config and will create a PR to incorporate into the Core. Now just have to see what state my version of the core is in.

Here's the final change:
Code:
for(uint8_t i = 14; i < 24; i++){
  p = digital_pin_to_info_PGM + i;
  *(p->pad) &=  ~IOMUXC_PAD_PKE;
}
I am thinking that clearing the keeper bit (PKE) needs to be done for the given pin in analogRead() and not in analog_init() (or in addition to). I can imagine a scenario where a sketch changes the pinMode() of an analog pin, and then later wants to use it in analogRead().

Code:
int analogRead(uint8_t pin)
{
    [B]const struct digital_pin_bitband_and_config_table_struct *p;[/B]

    if (pin > sizeof(pin_to_channel)) return 0;
    if (calibrating) wait_for_cal();
    uint8_t ch = pin_to_channel[pin];
    if (ch > 15) return 0;
[B]    p = digital_pin_to_info_PGM + pin;
    *(p->pad) = IOMUXC_PAD_DSE(7);    // disable PKE[/B]
    ADC1_HC0 = ch;
    while (!(ADC1_HS & ADC_HS_COCO0)) ; // wait
    return ADC1_R0;
}

hardware/teensy/avr/cores/teensy4/analog.c

Reference: ADC keeper glitch post #1789
 
Last edited:
I am thinking that clearing the keeper bit (PKE) needs to be done for the given pin in analogRead() and not in analog_init() (or in addition to). I can imagine a scenario where a sketch changes the pinMode() of an analog pin, and then later wants to use it in analogRead().

Code:
int analogRead(uint8_t pin)
{
    [B]const struct digital_pin_bitband_and_config_table_struct *p;[/B]

    if (pin > sizeof(pin_to_channel)) return 0;
    if (calibrating) wait_for_cal();
    uint8_t ch = pin_to_channel[pin];
    if (ch > 15) return 0;
[B]    p = digital_pin_to_info_PGM + pin;
    *(p->pad) = IOMUXC_PAD_DSE(7);    // disable PKE[/B]
    ADC1_HC0 = ch;
    while (!(ADC1_HS & ADC_HS_COCO0)) ; // wait
    return ADC1_R0;
}

hardware/teensy/avr/cores/teensy4/analog.c

I agree with that it probably should be in the read function to disable the PKE bit. But by that same token, most users won't be automatically setting the PKE bit.

I think that when I checked alternate functions for those pins, the PKE bit was set, eg., if you use SDA/SCL it does set the PKE same for Serial pins. The only thing I think I forgot is to check whether the PKE was set if you used it as a digital pin. I know for FLEXCAN0 we do set the pad config.
 
I agree with that it probably should be in the read function to disable the PKE bit. But by that same token, most users won't be automatically setting the PKE bit.

I think that when I checked alternate functions for those pins, the PKE bit was set, eg., if you use SDA/SCL it does set the PKE same for Serial pins. The only thing I think I forgot is to check whether the PKE was set if you used it as a digital pin. I know for FLEXCAN0 we do set the pad config.

PKE is set by default on power-on reset. also pinMode() is setting PKE for various modes.

I don't know what the "optimal" pad setting is for an analog pin, just clearing PKE may not be optimal. SDK uses 0xB0
 
Glancing at T_3.x AnalogRead shows IIRC each read does a number of things [thought I posted this before?] - having T4 assure valid AnalogRead with a simple set or check/set doesn't seem extreme -
 
I also bought 2 of those, but not really expecting to have time to do much with them.

View attachment 15820

Here's the Aliexpress link for those 3.5 inch, 480x320 displays. Right now is Chinese New Year, so expect any order to take a couple extra weeks.

https://www.aliexpress.com/item/3-5...reen-with-Touch-Panel-Driver/32908809356.html


@Paul - let me know if you see this RE the ILI9488 Display board you have. reporting here with your posts .... If you could confirm the test results you'd know for sure.

Just tested MISO on ILI9341 and 9488 - on the Touch and TFT halves :: pjrc.com/better-spi-bus-design-in-3-steps/

As it seemed the TFT MISO on the ILI9488 I got from your posted link is not Tri-Stated

The Touch MISO on 9488 does go to 3.3V/2 between the two 10K's when its CS is made HIGH. And the same for BOTH TFT and TOUCH MISO on the ILI9341

The TFT MISO on 9488 does NOT go to 3.3V/2 between the two 10K's when its CS is made HIGH, is seems to drop to Zero.
 
Glancing at T_3.x AnalogRead shows IIRC each read does a number of things [thought I posted this before?] - having T4 assure valid AnalogRead with a simple set or check/set doesn't seem extreme -

Dumb idea? How about an analogReadFast() like we have for digitalReadFast() that bypasses checks for the finicky who want to save every single cycle but not use DMA?
 
Dumb idea? How about an analogReadFast() like we have for digitalReadFast() that bypasses checks for the finicky who want to save every single cycle but not use DMA?

Teensy3 analogRead has lines #438 to 518 - with split in code for ADC0 and ADC1 and one or more irq() toggles
Teensy4 analogRead has lines #52 to 61

T4 seems to have less setup/check/wait overhead - the time spent likely in simple "while() //wait" for sample to complete
 
Quick update: The first 6 layer prototype PCBs arrived. It's a little panel with 8 boards, now finally the actual 1.4 by 0.7 inch size! I took them and 1062 chips over to the contract manufacturer. They're soldering only the 1062, diodes and voltage regulator. They said they're likely to finish by the end of this week. So odds are good by the weekend I'll be hand soldering the rest of the parts onto a couple boards.

I created another breakout board. I took off the switch, so the audio shield is wired only to I2S1 (hand soldering those little mux chips took a lot of time...). This new breakout board will bring out the CANFD, using a MCP2558 transceiver chip. I also put 8 pads to solder P50 size pogo pins, which connect to a micro SD card socket. This is my first attempt at a PCB using those tiny P50 pogo pins, so I'm not sure if that part will work. USB host (with TPS2055A current limit) and breaking out the serial ports is the same as before, except this time I just connected the serial pins directly. Hand soldering so many series resistors also took quite a lot of time for building those first breakouts.

I've also started working on the design of the bed-of-nails test fixture we'll use. Fortunately, the design is similar to testing Teensy 3.6, but this board has many more power supply voltages to check, and more capacitors to discharge when power cycling the board.

For the last several days, I've been mostly absent from this thread. I'm not good at working on software while also doing PCB layout. If you don't hear much from me this week, know it's the test fixture stuff.

Hopefully by the end of the weekend we'll know how the 6 layer boards with 1062 chips work.
 
PKE is set by default on power-on reset. also pinMode() is setting PKE for various modes.

I don't know what the "optimal" pad setting is for an analog pin, just clearing PKE may not be optimal. SDK uses 0xB0

@manitou
Oh, think you misunderstood me - I agree with the change was talking out load about my rationale for doing it the way I did - but better to be on the safe - I will make the change - have to make sure my git copy is updated and all that stuff :)

EDIT:
Ok. Pull request modified to include your recommended change to the analogread function
 
Last edited:
Quick update: The first 6 layer prototype PCBs arrived. It's a little panel with 8 boards, now finally the actual 1.4 by 0.7 inch size! I took them and 1062 chips over to the contract manufacturer. They're soldering only the 1062, diodes and voltage regulator. They said they're likely to finish by the end of this week. So odds are good by the weekend I'll be hand soldering the rest of the parts onto a couple boards.

I created another breakout board. I took off the switch, so the audio shield is wired only to I2S1 (hand soldering those little mux chips took a lot of time...). This new breakout board will bring out the CANFD, using a MCP2558 transceiver chip. I also put 8 pads to solder P50 size pogo pins, which connect to a micro SD card socket. This is my first attempt at a PCB using those tiny P50 pogo pins, so I'm not sure if that part will work. USB host (with TPS2055A current limit) and breaking out the serial ports is the same as before, except this time I just connected the serial pins directly. Hand soldering so many series resistors also took quite a lot of time for building those first breakouts.

I've also started working on the design of the bed-of-nails test fixture we'll use. Fortunately, the design is similar to testing Teensy 3.6, but this board has many more power supply voltages to check, and more capacitors to discharge when power cycling the board.

For the last several days, I've been mostly absent from this thread. I'm not good at working on software while also doing PCB layout. If you don't hear much from me this week, know it's the test fixture stuff.

Hopefully by the end of the weekend we'll know how the 6 layer boards with 1062 chips work.

@Paul - WOW!!! you have been busy and sounds like you are going to be a lot busier!

Don't think anybody is very good at doing software at the same time as doing Hardware design and layout and running a business so my hats off to you!
 
For the last several days, I've been mostly absent from this thread. I'm not good at working on software while also doing PCB layout. If you don't hear much from me this week, know it's the test fixture stuff.

Hopefully by the end of the weekend we'll know how the 6 layer boards with 1062 chips work.
Great news. I like the idea that you can hopefully be able to get to the SD pads using pogo. Should hopefully make it possible to remote mount SD and or use the signals. Cant wait to see how well this new board works!

I was sort of wondering as you started up the beta build to release new Arduino version... Makes Sense!

Kurt
 
Yeah, I had meant to merge some stuff and publish another beta installer... but got "distracted" with lots of PCB layout.

I still have Adafruit's latest GFX library open here. They've changed quite a lot recently. A copy of GFX that works with all their newer libs, and the older stuff we have is near the top of my priority list for 1.46.

Also haven't forgotten about your USB Host Bluetooth work, or Frank's SPDIF code, just been really distracted with PCB layout.
 
Yeah, I had meant to merge some stuff and publish another beta installer... but got "distracted" with lots of PCB layout.

Personally I think that is a great distraction! I was glad that it was not something like you were not feeling good... Keep up the good distractions :D
 
Great news. I like the idea that you can hopefully be able to get to the SD pads using pogo. Should hopefully make it possible to remote mount SD and or use the signals. Cant wait to see how well this new board works!
maybe the spacing and locations are good for direct soldering a uSDcard holder or connector(I don't trust pogo pins for 50+ MHz signals (springs are coils) but I may be wrong).
 
maybe the spacing and locations are good for direct soldering a uSDcard holder or connector(I don't trust pogo pins for 50+ MHz signals (springs are coils) but I may be wrong).
It will be interesting to see the current stuff, like where the connections are versus where the connections for USB Host. At least on the last setup, it sounded like the USB Host pins would be covered up by a uSDCard holder, so it would be great if we had a way to get both.
 
If you were imagining I could make physical space for both of these features to be populated with connectors, while also eliminating ~28% of the PCB real estate, I'm afraid you're going to be disappointed. The arrangement on the bottom of the board is pretty similar to the 1052-based beta board.

However, I did recently guy some very short SD sockets. When I get the boards next week, going to see if those can work. They could at least allow access to the 2nd USB port pads when the card isn't present.

With pogo pins, the steel spring is encased in a steel tube with nickle & gold plating. Most of the electrical conduction is probably through the plating materials on the surface, partly because they're lower resistance than steel, partly because skin effect at high frequency.
 
If you were imagining I could make physical space for both of these features to be populated with connectors, while also eliminating ~28% of the PCB real estate, I'm afraid you're going to be disappointed. The arrangement on the bottom of the board is pretty similar to the 1052-based beta board.
Actually for me, if I can get access to all of the pins in a reasonable way I will be very happy!
As 6 extra IO pins with special functions may be more valuable to me than SD access...

And the only way I could imagine having the SD installed on the bottom of the board and still have USB Host access would be if the pads for USB Host were after the SD Card... But I am assuming there are very good reasons on why they are where they are...
 
Status
Not open for further replies.
Back
Top