Any Chance of a Teensy ++ 3.1?

Status
Not open for further replies.
I hope for a Teensy 3++ or Teensy 4 (better name) that has 1MB flash and at least 128KB of RAM in the MCU - so I could install and NXP-ize the port of MicroPython and have enough app space. And floating point in hardware.
 
stevech said:
I hope for a Teensy 3++ or Teensy 4 (better name) that has 1MB flash and at least 128KB of RAM in the MCU - so I could install and NXP-ize the port of MicroPython and have enough app space. And floating point in hardware.
Click to expand...
It has, it's a MK66FX1M0, see previous post in this thread, but I'm concerned about the bootloader chip, not the main MCU!
 
WMXZ said:
if the bootloader chip is the MK02
Click to expand...

So far, that is the plan (and the prototypes).

While unlikely, the plan may change before final release. I can not make any hard promises at this time.

I can tell you we're very certainly on the path for the K64 (5V tolerant version) & K66 (3.3V only version), which have 192K and 256K RAM respectively.
 
Last edited:
Very nice to have: an MCU with the chip maker's bootloader in ROM, and by 0 ohm jumper it's disabled so the PJRC MK02 type strategy is the default.
And let us use the SWD and trace pins if we wish.
 
@Paul
Accepting the risk of asking too much,
I know there will be 48 pins, at least I believe I read it before, but is the form factor similar to the T3.2 reference board (long), or are there double rows (short but wider than T3.2)?
 
The last posting I remember seeing was maybe posting #72 his plans at that time were to add one inch to the board length wise...
 
FYI, I updated my MK64F performance data in post #411 to include timings on floating-point intensive sensor fusion from prop shield testing.
 
I'd like to ask everyone following this thread to refrain from creating illustrations or mock-up images. Please keep the conversation here on this forum thread, and please do not repost this info on social networking sites. Teensy is still nowhere near the scale and need for new product secrecy of Arduino. But we are at the point where new products are newsworthy for sites like Makezine & Hackaday, which is the main reason I've asked everyone to refrain from photos during beta tests.

KurtE said:
plans at that time were to add one inch to the board length wise...
Click to expand...

Yes, that's still the plan, for a total PCB size of 2.4 by 0.7 inches.

The 28 pins on the left side will retain close compatibility with Teensy 3.2. The 20 new pins will add 3.3V (next to pin 12) and GND (next to pin 13), and digital pins 24 to 39 with analog on 31-39, and two analog-only pins for DAC0/A19 & DAC1/A20.

Most of the new left-side area will be occupied by a SD socket, with fast 4-bit SDIO bus, which is not shared with SPI or any other normally used pins.

A location solder a 5 pin through-hole header is planned, for the 2nd USB port (with 480 Mbit/sec speed & USB host mode). The pinout will be the same as 5 pin USB headers on PC motherboards, so you can add a header and plug in a commonly available USB front-panel cable. This is likely to be located close to pins 2-6.

Double rows or other changes in form factor are not planned. Best possible pinout compatibility with Teensy 3.x & LC is a major goal.
 
Last edited:
PaulStoffregen said:
I'd like to ask everyone following this thread to refrain from creating illustrations or mock-up images. Please keep the conversation here on this forum thread, and please do not repost this info on social networking sites. Teensy is still nowhere near the scale and need for new product secrecy of Arduino. But we are at the point where new products are newsworthy for sites like Makezine & Hackaday, which is the main reason I've asked everyone to refrain from photos during beta tests.



Yes, that's still the plan, for a total PCB size of 2.4 by 0.7 inches.

The 28 pins on the left side will retain close compatibility with Teensy 3.2. The 20 new pins will add 3.3V (next to pin 12) and GND (next to pin 13), and digital pins 24 to 39 with analog on 31-39, and two analog-only pins for DAC0/A19 & DAC1/A20.

Most of the new left-side area will be occupied by a SD socket, with fast 4-bit SDIO bus, which is not shared with SPI or any other normally used pins.

A location solder a 5 pin through-hole header is planned, for the 2nd USB port (with 480 Mbit/sec speed & USB host mode). The pinout will be the same as 5 pin USB headers on PC motherboards, so you can add a header and plug in a commonly available USB front-panel cable. This is likely to be located close to pins 2-6.

Double rows or other changes in form factor are not planned. Best possible pinout compatibility with Teensy 3.x & LC is a major goal.
Click to expand...

Paul,
thanks lot, this helps me tremendously in preparing my next PCB adapter board (layout, gross dimension), where every cm counts.
 
Last edited:
In relation to WMXZ's comment, do you think it will be possible to make the definitive pinout (once known) available to those of us who make addons, say during the beta phase, so that we can then start designing compatible boards?
 
PaulStoffregen said:
Most of the new left-side area will be occupied by a SD socket, with fast 4-bit SDIO bus, which is not shared with SPI or any other normally used pins.
Click to expand...

Do you have driver software for 4-bit SDIO? I've looked a bit on the internet and not found driver software. The mbed K64F uses SPI for its onboard microSD, though MCU supports SDHC/SDIO.
 
If there is a desription in the manual, it should be doable..
I played with parallel access long time ago.. i was able to read to read raw blocks. But that was with GPIO, not with extra hardware.
 
manitou said:
Do you have driver software for 4-bit SDIO? I've looked a bit on the internet and not found driver software. The mbed K64F uses SPI for its onboard microSD, though MCU supports SDHC/SDIO.
Click to expand...

I suggest to wait for HW release, I'm pretty sure that there will be HW support for SDIO once HW is released, as there is no SPI access to uSD.
 
WMXZ said:
... as there is no SPI access to uSD.
Click to expand...

On the NXP/Freescale K64F the SDHC GPIO pins (PTE0-6) can be configured for SPI1 or SDHC/SDIO. To put the SD card into SPI mode you pull CS low and send CMD0.
 
Last edited:
Last edited:
most interesting is c3b.pdf, the last pages..ah-- i looked at the zipfile..lol.. ok, first i thought that it was my code :) but it's not. That code is from elsewhere.
But as far as i remember, i used that to write my teensy-gpio-version.

Well, the teensy must handle all the data at that speed, so i asume, those 200mbs are more theoretical..
 
manitou said:
Do you have driver software for 4-bit SDIO? I've looked a bit on the internet and not found driver software. The mbed K64F uses SPI for its onboard microSD, though MCU supports SDHC/SDIO.
Click to expand...

I've made a bit of progress experimenting with SDHC on mbed K64F. Here is a link describing an RTOS implementation of SDHC driver
https://community.freescale.com/thread/85176
I downloaded the brtos.rar and hacked away. The driver does talk directly to the SDHC module (no SPI), but doesn't utilize the FIFO or DMA. I got driver to read a sector of my choosing from a SanDisk microSD card. Driver is reading 32-bit data from SDHC_DATPORT register in a loop. With 120MHz K64F, driver sets SDHC clock to 20mhz. I get 4.9mbs (megabits/sec) reading a 512-byte sector (1-bit width). I don't have a fast SPI driver for the SDHC, but @120mhz, teensy SdFat SPI (FIFO/16-bit) can do 27mbs. A simple byte-loop SPI read of the microSD on the K64F's SDHC runs at 2.7mbs, even with the SPI clock @30mhz.

i'll see what i can figure out about SDHC FIFO, high speed (50mbs), and DMA ...

EDIT: setting to 4-bit width, get modest improvement to 6.2mbs (you have to configure the card to use 4-bit and the SDHC module). Here are bits in the two main SDHC control registers
Code: 
SDHC_SYSCTL 0xe0128
SDHC_PROCTL 0x2a

EDIT 2:
I upped the clock to 40mhz, and think I enabled FIFO, but the data rate improvement was negligible (6.3mbs). The sector read's were correct.

The slow data rate is due to a 630us delay in
while (SDHC_PRSSTAT & SDHC_PRSSTAT_DLA_MASK){};
If i put a testpin toggle around the the word-copy loop in the driver and use a logic analyzer, I measure 137mbs. In FIFO mode, with a 16-word threshold, I measure 400mbs to read the 512-byte sector from the SDHC buffer/FIFO. If I remove the while(), then the sector read returns bad data. If the timed sector read is not the first disk_read(), the delay is reduced to 280us, effective data rate of 14mbs. Presumably a multi-sector read would amortize the delay (though I haven't succeeded yet with a multi-sector read).


EDIT 3: The driver must be out of sync with DLA. The DLA wait-times are the short duration numbers, the longer times are data transfer times. so 400mbs rate is just time for reading words from DATPORT. The SDHC hardware has a 512-byte FIFO/buffer, when DLA is no longer active, the program can read from the DATPORT (32 bits), or use DMA (see K66 beta testing WMXZ driver and uSDFS)

uTasker also has a kinetis SDHC driver.
 
Last edited:
Great!

The Cryptographic Acceleration Unit (CAU) and RNG are interesting.. can't wait to play with it.. :)
I wonder whether there might be a way to connect the CAU via DMA with the SDHC (or Ethernet) ? Both directions r-w ?
 
I could really use a 3++ yesterday.
I just finished laying out a PCB to use a 3.2. I used every single I/O pin (including the ones in the middle).
I'm using all 3 uarts and AltSoftSerial, AND I have a 4x1 mux on one of the hardware uarts (so I can have a total of 7 serial streams). I just started working on code and I'm hoping I don't run out of sram.
(So hurry up so you can take our money)
 
Status
Not open for further replies.
Back
Top