Any Chance of a Teensy ++ 3.1?

Status
Not open for further replies.
Frank B said:
Teensy++ 3.x: Do you know if the new chip supports Dual / Quad SPI? Perhaps with the SDIO interface?
Click to expand...

I looked at what I think is the data sheet for the processor. "Two CAN, three SPI and four I2C modules". The bigger challenge IMO is going to be how to make all these communication interfaces play nice with each other. When people see multiple I/O interfaces they get really excited but communicating at high speed, consistently well, and without requiring the user to make some compromises is something that will likely require a lot of very good library support to make it happen.
 
Frank B said:
Teensy++ 3.x: Do you know if the new chip supports Dual / Quad SPI? Perhaps with the SDIO interface?
Click to expand...

No, as far as I know it doesn't support QSPI or DSPI.

The SDIO controller is very tightly tied to the SD protocol. It closely follows the SD host controller spec. Perhaps there's some way to shoehorn it into QSPI, but it'd probably involve some incredible hackery, since the SD state machine is doing whole commands that involve protocol on the 1 bit CMD and 4 bit DAT bus. Tricking it to be happy with responses on the CMD line seems like quite a challenge!

Hardware-wise, I'm planning to bring the 6 SD signals to a Micro SD socket (the same type as used on the audio shield), but not to outside pins or dedicated pads. The SD bus will run at 45 or 48 MHz in most modes, so it's probably not a good plan to connect it to other stuff, especially with lengthy wires.


Constantin said:
I looked at what I think is the data sheet for the processor. "Two CAN, three SPI and four I2C modules".
Click to expand...

Yup, that's the datasheet, but it's only the fairly mundane electrical specs. That's why it's only 90 pages.

To really learn about the chip, you want this 2237 page reference manual.

http://cache.freescale.com/files/32bit/doc/ref_manual/K66P144M180SF5RMV2.pdf

Freescale does seem to be trying to improve their manuals. They've eliminated the "chip configuration" chapter and actually put the info about how each peripheral is configured at the beginning of each chapter.


The bigger challenge IMO is going to be how to make all these communication interfaces play nice with each other. When people see multiple I/O interfaces they get really excited but communicating at high speed, consistently well, and without requiring the user to make some compromises is something that will likely require a lot of very good library support to make it happen.
Click to expand...

Yes, that is a huge challenge. I've actually been thinking quite a lot about this recently. For some peripherals, we have pretty good libraries in place. Others, not so much. Even among the really good libraries, there isn't nearly as much API consistency and simplicity as I'd like. So much work is yet to be done....

I know the Arduino folks have some of these same issues on their radar. Today they're going to announce something called "Arduino Connect". I know almost nothing about it, but my guess is it'll be a web-based IDE. Whether it will bring new APIs is a good question. We'll probably know more in a matter of hours!
 
As far as SD interface - trusting Wikipedia showing the right details that only shows 1bit and 4bit - there is a licensed protocol for anything but SPI ... unless I suppose that license comes with the hardware ...

SPI bus mode: Serial Peripheral Interface Bus is primarily used by embedded microcontrollers. This bus type supports only a 3.3-volt interface. This is the only bus type that does not require a host license.
One-bit SD bus mode: Separate command and data channels and a proprietary transfer format.
Four-bit SD bus mode: Uses extra pins plus some reassigned pins. UHS-I and UHS-II requires this bus type.
Click to expand...

PaulStoffregen said:
Yup, that's the datasheet, but it's only the fairly mundane electrical specs. That's why it's only 90 pages.

To really learn about the chip, you want this 2237 page reference manual.
Click to expand...

Funny the ref manual Overview starts on page 73, the table of contents ends on page 72 - almost the length of the datasheet - and then Overview ends on page 92.
 
I'm using SDIO on an ST MCU... no mention of licensing responsibilities for me the end user. I'm using free vendor-supplied DMA drivers and vendor's adaptation of FatFS. Perhaps Freescale has the same.
I recall that the association still holds the MMC interface (not so popular now) as license-protected.

The 1 bit SDIO mode, with DMA, is a good compromise for some MCUs that are pin-count constrained. 24Mbps or more.
 
stevech said:
I'm using SDIO on an ST MCU... no mention of licensing responsibilities for me the end user. I'm using free vendor-supplied DMA drivers and vendor's adaptation of FatFS. Perhaps Freescale has the same.
I recall that the association still holds the MMC interface (not so popular now) as license-protected.

The 1 bit SDIO mode, with DMA, is a good compromise for some MCUs that are pin-count constrained. 24Mbps or more.
Click to expand...

With my "SDIO (4 Bit) in software" - experiments some time ago i was able to transfer a single block between 5-8MB (MegaBytes) per second.
It was only a hand-optimized assembler "bitbang"-loop without dma or other tricks.
Unfortunately, this rate is not archievable in "real world", because the block-adressing still needed up to 1300us with my slowest card(hehe..it was the newest, a sandisk). The fastest was a very old noname .. (850..950 us).

Perhaps with 2 channels dma (one for data, one for clock), more transfer-speed is possible. In the wainting time during the adressing, the raw dma-transfered bits could be "decoded"... maybe someday, when i have way to much time, i try it again.
But hey, having a hardware-device for that is way better.
 
Last edited:
Let me clarify: The FATFS is unmodified - the API for SD IO is a few lines of code I did to mate FATFS to the vendor's SDIO DMA read/write/init and interrupt callbacks for DMA complete.
Very easy to get running. I did 1 bit SDIO to save pins, but now with new PCB artwork and pin mapping, I could go to 4 bit SDIO. Simple change. But I don't really have the need for faster than 1 bit @ 24Mbps as of now.

FATFs has a sector buffer per open file (yuck).
The DMA is based on the card's sector size - which seems to be 512 bytes for all the cards I've encountered - but I see reference to some types with 1KB sectors.

I don't see within FATFS (ChaN) any additional cache, as it assumes low-RAM MCUs, nor any in the driver layer between ChaN and the SDIO driver. Perhaps it's because ChaN assumes the can't be a timer-based flush of write buffers.
 
Last edited:
Paul,
It me again,
I see you are already preparing for the software for the MK66FX1M0 (changing core library).
I don't want ask you any update, but if you feel inclined, you would get a good audience.

I guess it would help some of us (at least it would help me) to learn early about final pin allocations, even if someone will be disappointed.
 
Well, you asked for *any* update. I'm afraid the news at this moment isn't very good. The flash memory controller in this chip is giving me a lot of grief. It's very strange problems. Sometime I'm sometimes getting it stuck in a weird state where parts of the flash memory work, but other parts give bus faults. In one really bizarre test, I can read location 0x3C0 and higher, but if I read location 0x3BC, I get a fault. Very mysterious. The problem is intermittent too.... often things work fine, other times they fail. Very frustrating.

I ordered a few other Freescale chips and soldered them onto more prototypes, so I can try my code on other chips and see how they compare (since I'm pretty much stuck at this point). That was a few days ago. Haven't had time to work with those yet.

You saw I've pushed some preliminary stuff to github. The good news is I've got the USB and bootloader and basic Arduino stuff working.... but only when the flash memory cooperates. I started some work to develop code for the SDHC controller, but the flash memory trouble makes things just too unstable and unreliable to make much progress.

It is getting work, which is part of the reason I disappear from the forum (and email) for 24-36 hours occasionally, then get caught up in 1 long session of answering questions and messages.... but much remains to be done before this can become a viable product!

In somewhat older news, I did a preliminary partial layout with the BGA144 package and a Teensy form factor with 48 exterior pins. It's going to be a 6 layer board, and indeed 6 layers will make the routing work. 4 layer falls only slightly short, with a lot of unpleasant compromises on the power and ground. 6 works easily and allows a nice ground plane on layer 2 and good power routing on layer 5. I put some time into communicating with our PCB vendor and they're able to do 6 layers at a reasonable price, so at least that part of the project is looking really good.

The prototypes I'm working with now are 4 layers, using the huge LQFP144 chip on a big PCB that's anything by "Teensy" size!
 
Also, I should mention the info in the code on github is all subject to change!

Obviously the pin assignments for digital pins 0 to 23 are very solid. Form factor compatibility with the 28 outside pins of Teensy 3.x is a top priority. The stuff on github can give you a pretty good idea of where this is likely headed, but I can and will change it without warning if there's any compelling reason that comes up in testing.

Even in beta testing, things might change.... and yes, there almost certainly will be a beta test period. Like Teensy-LC, we will provide free samples to people who regularly help others on this forum, and to anyone who's published libraries that leverage Teensy 3.x features. But this is not the time to request beta testing (especially not by sending me private email). Just following this thread is enough for now. As with everything we do, it'll be announced here on this forum first.
 
PaulStoffregen said:
....
I know the Arduino folks have some of these same issues on their radar. Today they're going to announce something called "Arduino Connect". I know almost nothing about it, but my guess is it'll be a web-based IDE. Whether it will bring new APIs is a good question. We'll probably know more in a matter of hours!
Click to expand...
Did this announcement ever appear, I couldn't find it on their website.

David
 
No, it seems they didn't announce "Arduino Connect" at this year's NY Maker Faire. Maybe they'll do it at the one in Rome in a few weeks?

So far, all that's known is it'll be some sort of web based dev environment, using the new Go-based (no Java) build tool they've been developing for 1.6.6. A few hints have been dropped that it's meant to allow making IoT projects with relatively little code.

In other news, it seems "Internet Of Things" is finally becomming passé. Now they saying "Connected Devices", but it's still the same wishful hype.
 
PaulStoffregen said:
Well, you asked for *any* update. I'm afraid the news at this moment isn't very good. The flash memory controller in this chip is giving me a lot of grief. It's very strange problems. Sometime I'm sometimes getting it stuck in a weird state where parts of the flash memory work, but other parts give bus faults. In one really bizarre test, I can read location 0x3C0 and higher, but if I read location 0x3BC, I get a fault. Very mysterious. The problem is intermittent too.... often things work fine, other times they fail. Very frustrating.
Click to expand...

You're aware of the fll-problem mentioned in the errata ? just a guess.
 
Last edited:
PaulStoffregen said:
No, it seems they didn't announce "Arduino Connect" at this year's NY Maker Faire. Maybe they'll do it at the one in Rome in a few weeks?

So far, all that's known is it'll be some sort of web based dev environment, using the new Go-based (no Java) build tool they've been developing for 1.6.6.
Click to expand...

So would "Arduino Connect" be built on top of web based IDE they called "Arduino Create", or is it the new name for it? I think you are suggesting the former.

https://blog.arduino.cc/2015/05/05/sneak-peak-arduino-create/
 
The desktop arduino ide was non intuitive (double click and triple click don't work like other programs, no drag and drop of text etc. ) and irritating ( search and replace is hopeless, no intellisense, no right click "where used" etc.) on the browser it's probably going to be worse.

Do really want all my sketches on the cloud for prying eyes?
 
I'm planning to put my product out in the field. It would be very handy if the Teensy ++ 3.1 or 3.2 could opt to load its .hex file from an SD card. That way, I can send my updates on an SD card and instruct my customers to pop out the old card and insert the new one and then power up! Just a suggestion/food for thought to make a great product even better (and really have a leg up on the Arduino camp!!).
 
I have commercial product in the design stages but it will be a low cost retail product.

One of the reasons I came to Teensy was because, while there are lots of add-ons from commercial companies, everything (or everything I've seen) is low cost or what I would call 'reasonable' from a price perspective. uTasker is not only the most expensive product I've seen for this board, but it's way over priced for its purpose. I mean really, hundreds of Dollars just to get a .hex file load off of an SD card?

I have absolutely no problem paying for hardware/software and I've bought lots of both. Companies are entitled to earn some ROI for their time and their products. However, uTasker is on another planet with their commercial pricing for their SD card boot solution. Maybe they assume everyone who is using a Teensy for a commercial product is charging $1,000.00+ for their product.
 
Status
Not open for further replies.
Back
Top