Any Chance of a Teensy ++ 3.1?

Status
Not open for further replies.
Also, is perfect sync possible with RMII interface? Or does anyone care about a fraction of a microsecond latency?

I've done a fair amount of 1588 stuff in my day job but I'm not an implementation expert so this answer isn't authoritative:

The 1588 protocol, in combination with hardware timestamping, will account for the 'fraction of a microsecond' latency as it becomes part of the end-to-end delay calculation (i.e. it's between the master & slave hardware timestamping engines). What is far more important to perfect sync is the consistency, i.e. a fraction of a microsecond with very small variation.

Looking into the K66 implementation, it seems that the 1588 timing block will be clocked with 125MHz, giving a 8ns increment on the ns timestamp which is excellent.
 
Does the 1588 clock need to have a period that's an integer number of nanoseconds? There's a note about that in Freescale's reference manual.

If so, probably the only option will be the 50 MHz RMII clock.
 
Does the 1588 clock need to have a period that's an integer number of nanoseconds? There's a note about that in Freescale's reference manual.

If so, probably the only option will be the 50 MHz RMII clock.

I saw that too (page 130). Looking at Figure 6-7, it seems that we've got a few sources to choose from.

1588 Timestamp clock sources: Core/System Clock, MCGFLLCLK, MCGPLLCLK, IRC48MCLK, USB1PFDCLK, OSCERCLK, ENET_1588_CLKIN
1588 Timestamp clock restrictions: <180MHz, must be integer number of nanoseconds, so realistically; 125MHz, 100MHz, 62.5MHz, 50MHz, 25MHz, 10MHz

RMII clock sources: EXTAL, ENET_1588_CLKIN
RMII clock restrictions: =50MHz.

After looking at the clock distribution chapter and searching for 'EXTAL' in the whole reference manual, I don't really understand what they mean by 'EXTAL'. This seems to suggest that you'll need to use a 50MHz crystal on this Teensy... but that seems unlikely.

I've no idea where you're going to get this RMII clock from, but I suspect the case with the 1588 Timestamp clock is that we'll have to have a caveat that the 1588 mode means the Teensy has to run at a specific clock rate that yields a Core/System Clock in the 125/100/62.5/50/25/10 MHz range.
 
At this point, I'd like to share with you the tough decision making.... prioritizing which of the extra pins to make available.

I believe 10 of these will route to the outside edge. The ones marked "?" are likely candidates. Perhaps 6 to 14 more may route to bottom-side pads or a location to solder a connector. Maybe....
I would like to repeat my previous vote for through-hole access of all I2S signals (pitch not important)
 
1588 Timestamp clock restrictions: <180MHz, must be integer number of nanoseconds, so realistically; 125MHz, 100MHz, 62.5MHz, 50MHz, 25MHz, 10MHz

I'm afraid none of those are likely to be feasible.

According to section 6.7.8, the 1588 can use 4 possible clocks. The 2nd one can be one of 4 sources, but Teensyduino always needs to configure SIM_SOPT2 for the PLL clock (MCGPLLCLK). The other three SIM_SOPT2 options are wrong frequencies anyway.

The first "Core/System Clock" must be an integer divide of the PLL. Except at slow frequencies (where the Ethernet MAC can't work anyway, due to insufficient DMA bandwidth), the PLL and system clock are the same.

The PLL can only generate frequencies that are ((16/M)*N)/2, where 16 is from the crystal, M is either 1 or 8, and N is an integer between 16 to 47. However, there are also electrical limits, where M can only be 1 or 2 for this chip, and the final output must be between 90 to 180 MHz.

OSCERCLK is 16 MHz, directly from the crystal oscillator.

The only realistic option is probably going to be the ENET_1588_CLKIN pin.


I've no idea where you're going to get this RMII clock from

Modern Ethernet PHY chips take a 25 MHz crystal and output a 50 MHz reference clock for RMII mode. That clock will connect to the ENET_1588_CLKIN, for both the RMII and 1588 timers. The two PHY chips I've been considering, Micrel KSZ8091RNB and Microchip LAN8720A, both have this feature.

Unfortunately, it seems 50 MHz is the best that will be possible for the 1588 clock, to meet the integer nanoseconds requirement, while working within the requirements needed for USB and the limitations of the PLL.
 
At this point, I'd like to share with you the tough decision making.... prioritizing which of the extra pins to make available.

Here's the list of not-yet-allocated pins, with their peripheral functions. Duplicate functions of already-allocated pins are lowercase, but still might be useful as alternates. Of course, the uppercase ones are functionality that will be unavailable if not brought to an accessible pin.

Not knowing what is already being brought out, here is what I'd like to see at a minimum (based upon the K66 specs):

- Two SPI busses
- Two I2C busses
- 1 CAN bus
- 4 UART, with at leat one having RTS/CTS available
- 1 I2S
- 2 DAC
- 8 analog (spead across the ADCs and comparators)
- SDHC
- Ethernet
- 4 PWM
- 4 touch
- JTAG

I'm probably forgetting something, but that's what I can't think of off the top of my head.

Also, please include the RTC crystal.

A final thought, consider something a bit more radical in the form factor that might make it possible to keep the size down but bring out the maximum number of connectors. Something like instead of through hole pins, use a high density connector, then sell various breakout boards for people that want through hole connections. That way, you can buy the base module and select an appropriate breakout module based upon the number/type of pins you want access to. Plus, it would make the ++ more appealing to just integrate into a design, via the high density connector, vs. designing a new board using PJRC purchased MK54 chips. Maybe something like this: http://www.mouser.com/ds/2/185/ed_DF40_20140305-337786.pdf
 
+1 for JTAG. Actually, a quick survey around here gives +5.

Maybe, 4 PWMs aren't sufficient for the drones and robotics folks, they might complain. I also find a second I2C far more important than a second SPI, given that today we have working libraries for DMA on SPI and SPI transactions.
 
I want my UART'S and i want them now, i also want a UART5

LPUART0 is effectively UART5.

Freescale calls it LPUART because it has different clocking, which can't support faster or high-res baud rates, but can (with special software support) run from asynchronous clocks in low power modes, and even use asynchronous DMA while the processor is in sleep mode.

However, Teensyduino will support it as "Serial6" with normal Serial6.begin(baud). When run from normal clocks, it's just another UART, though it won't support the higher and special baud rates with the accuracy the other 5 normal ones can (same as all the serial ports on Teensy-LC). The special asynchronous features are well beyond the Arduino environment.
 
Last edited:
Not knowing what is already being brought out....

Everything not mentioned in message #296 is either brought out to pins, or has a dedicated connection (and so, can't be brought out to pins without conflict), or will be handled specially (JTAG), or is a feature that won't be supported at all (pretty much flexbus/sdram). The lowercase stuff is brought out too.

So SPI0, SPI, I2C0, I2C1, I2C2, UART0, UART1, UART2, CAN0, all I2S pins execept I2S_RXD1, both DACs, several analog, pwm, touch are all brought out to the already-assigned pins on the breadboard-friendly edges. The RMII (but not MII) ethernet pins have all been assigned.

Things on not brought out so far: SPI2, CAN1, I2C3, UART3, UART4, LPUART0, FTM2[0-1] and FTM3[4-7] (6 of 20 PWM), 2 touch pins, 13 analog pins (of 25), 2 of the IEEE1588 timers (of 4) and a couple other seldom-used features.

Many of those 57 pins will not make it to the outside edges. Probably only 10 will. 10 of those 57 is enough to get many but not all the features. Another group will likely make their way to bottom-side pads or a pads to add connector of some sort.
 
Another thing that currently isn't brought out are all 16 pins of any port. Like Teensy 3.1, two of the ports have all 8 pins.

Getting all 16 of one port (on the outside edges) would mean giving up at least a few pretty important peripherals. Ports C and D are the viable candidates. If you look over the list, you'll see PTC8 to PTC15 and also PTD8 to PTD15 are on the list of unassigned pins. Either of those groups of 8, plus 2 more pins, are the 10 that make it to the outside edges... you can look over the rest of the list to see what those choices would mean excluding.
 
I'm all for as many UARTs as possible. I kinda like PTC8 - PTC15, gives UART3 and UART4 in addition to the 16 on C. Also leaves just enough room to bring out that low power UART as well.
 
Judging from the comments in this conversation , everyone has serious intentions for the teensy ++, and are probably already designing their own PCB's and dont really need compatibility with arduino . I like jbliesener's idea of a high density connector , i think we need a break from the traditional classic pin pitch inherited from arduino and radio control connectors. i think a separate optional header board should be sold with classic pin pitch for those who need it, serious users just buy a connecting cable and solder to their own boards. This approach can also start a bit of innovation as people design and sell different breakout boards in different formats.

I dont think it really matters what breakout connector is used, as long as a cable and opposing connector is readily available, and has some equivalent connector in the Fritzing library (and other PCB design libraries) then it makes it so much easier to integrate to our equipment on the other end.

the current pin pitch is 0.1in (2.54mm). I think it is overkill, we dont need such big pins.
I would choose something between 2mm and 0.5mm pitch. we have just felt the pain of a 12 pin 0.5mm pitch smd connector. its a pain to design for, and a pain to solder. the smaller the pitch the bigger the bitch.

the attached photo shows the classic pitch and the 0.5mm pitch for comparison.

pins.jpg
 
Last edited:
re post, above

There could be 0.1in headers for backwards compatiblity.
Add a high-density connector for things like
- 8 or 16 bit wide ports for address or data
- 4 bit SDIO
- more UART, SPI, I2C, ports

the 0.1in headers are inefficient and fading away on competing designs.
 
Ok, since everyone wishlists here -
here ist mine

- SDHC on board
- Two SPI busses (a must)
- one UART having RTS/CTS
- RTC Crystal, optional
- 8-Bit ports

On the software-side: USB-Mass-Storage support, SDHC support
Std pinheaders, no special connectors. The SMD-Pads are good!

Edit: I forgot to mention the second LED :rolleyes:
 
Last edited:
Judging from the comments in this conversation , everyone has serious intentions for the teensy ++, and are probably already designing their own PCB's and dont really need compatibility with arduino .

I would draw a modified conclusion:

In order to develop further the Teensy community (i.e. supporting PJRC's business), I would accept the new T3.x model to be mostly pin compatible with T3.1, maybe changing some less used pins with other pins that may open new applications.

All others of us that have special needs, should also have special skills (or money) to implement these needs, including custom T3.x boards.
All, what we need is the availability of the new Bootloader from PJRC.

Of curse, if there is space for am additional high-density connector, then it would help the use of new T3.x for non-standard application.
 
The only realistic option is probably going to be the ENET_1588_CLKIN pin.

Thank you for taking the time to explain this, I have gained another bit of knowledge!
All my thoughts over the different 1588 clock frequencies was purely hypothetical, in practical reality; 50MHz is plenty and the idea that this remains fixed across any CPU frequency is very appealing.

I'll continue to slowly learn about the 1588 subsystem so I can hopefully contribute to the software next year.
 
@WMXZ: I understood/assumed the 3.1 footprint portion was unchanged. An inch is added to get 20 new pins.

I liked the high density connector possibilities to provide more pins and perhaps reduce the length increase.

I would choose something between 2mm and 0.5mm pitch. we have just felt the pain of a 12 pin 0.5mm pitch smd connector. its a pain to design for, and a pain to solder. the smaller the pitch the bigger the bitch.

Reading this led to : 1.27mm pins/headers/cables are common (unlike 1mm)

If a portion of the new board had these - while not breadboard compatible - it would be more usable than under pads. It could go on one edge of the added length (or half on each end), leaving 10 new .1" pins and twenty 0.05" pins on the other, or maybe as a through hole addition instead of underpads for a user (?) addon medium density connector as line of 20 or a double row of 9.

tx.05b.png
image shown for scale only, image scale is simulated :)

EDIT> That second image was not to be there - I took the extra minute to make it a better simulation and both stuck
 
Last edited:
@jasper: The idea of the high density connector came from defragster, I don't deserve those credits...

In message 235, Paul has indicated that he doesn't like the idea too much. However, seeing defragster's latest layouts, I can't deny that I find it somehow appealing. I'd just maintain the 0.1" pitch on _all_ edge pins for breadboard compatibility and mechanical stability. While I think that the upper one of his two layouts preserves compatibility with the current form factor and pin locations, I realize the difficulty (challenge?) to route all new signals between the vertical row of holes.

AFAIK, SDHC is subject to royalty payments to the SD association. Does anybody know how much it is and what are their terms?
 
the 0.1in headers are inefficient and fading away on competing designs.

Really Steve? Which ones? Intel Edison and Tinyduino using high density connectors, Xbee using 2mm, and Electric Imp using SD card format are the only ones that come to mind.

Arduino, Raspberry Pi, Beaglebone, many Arduino clones, Particle (formerly Spark), Digispark, Adafruit, Sparkfun, Seeed Studios, and now most major semiconductor companies (using the Arduino shield form factor, but without any Arduino software support), and tons of no-name Chinese clones... all provide their I/O pins on 0.1 inch spacing.

Recently Arduino LLC trimmed their product line, eliminating Leonardo, but they kept the breadboard format Arduino Micro. Likewise, the most original thing Arduino Srl appears to have made so far is Yun Mini, basically repackaging Yun in breadboard format. Likewise, Particle (formerly Spark) just released Photon, in a breadboard format, and they're partnering with Digistump on more breadboard-format boards. Adafruit has also very recently released several new dev boards, almost all in breadboard format, except a few round wearable format. These very recent design choices from the most prominent companies in this market all seem to point to breadboard format becoming the new norm, perhaps displacing Arduino shield format?

But when you combine the breadboard format boards like Teensy with the many Arduino shield format boards, and Raspberry Pi using a 40 pin header, and Beaglebone and others like that much-hyped $9 SBC using a pair of dual-row sockets, I believe it's pretty safe to conclude nearly everyone is providing I/O on 0.1 inch pitch pads.

If 0.1 inch I/O really is "fading away", I'm just not seeing it. Maybe you could point to the products you're seeing taking over this market with higher density I/O?
 
Personally, I am torn as I am often known when I build a breakout board to end up cramming as much stuff as I can possibly add as I maybe I will need it some day, which sometimes makes the boards a pain to build...

so my 2 cents worth:

So personally from maybe a page back, I always want as many uarts as I can get. I personally don't use too much I2C, but do a few experiments with them (lidar lite). SPI - two would be great, with maybe one dedicated to things like SD cards and the other to things like display... I am a junky for IO pins, but honestly there are very few times I have come close to running out of them on the 3.1...

On form factor: I personally liked your idea earlier on, which was thinking of the products like a family of products. With LC at bottom end, new one at high end and 3.1 in the middle. Where maybe one could design a board that you could plug in any of these, where the 3.1++ would simply extend another inch or so... Sort of like Arduino vs Mega...

But if you deviate from this with different connectors or pin spacing, I hope you still take the hobbyist into an account.

That is for example with Edison, I personally am not great with soldering really small pin spacing like the hirose (sp) connectors, so I would have to rely on someone else to make a breakout board. So now I have two boards to buy. Also you just added the extra expense of these connectors. Note: I am not putting down the Edison. There are parts of them I like, but their support of them can be a bit frustrating...

Personally I am not against somewhat smaller pin spacing. Example I have built XBees into some boards with the 2mm, but they can make it harder to design boards as typically I don't like my etches and spacing's to be that tight, so typically can not run etch between pins.

As for other boards that use different pin spacings? Currently I am using a couple of the Odroid XU3-lites (maybe soon will try newer XU4 http://ameridroid.com/products/odroid-xu4). They use I believe 2mm connectors (with 1.8v logic). So to experiment with their signals, I needed to purchase some jumper cables (adafruit) that had the 2mm female to 2.54... to jumper to breadboard to try things out (through level shifters...). They also understand that issue, so they recently released a level shifter board (http://ameridroid.com/products/xu4-shifter-shield) that both allows the user to choose 3.3v or 5v, plus brought out the signals out to a .1" spacing connector that is compatible with RPI (as well as their Odroid C1). As to allow some of the RPI shields (like display) to plug in...

So again personally I think you should at least for the exterior pins keep to the .1" spacing hopefully as compatible as possible with 3.1. As for the interior pins, by definition these don't plug into breadboard, so could be different spacing. However if you choose a different spacing hopefully it wont be too small (2mm?).

But again that is just my 2 cents.
 
There seems to be only 1 clear consensus in this conversation. When the question is which pins to prioritize, the answer is approaches to make more/all pins available!

For now, I'm going to try to bring all 20 PWM, all touch sense, both DAC, both CAN, ethernet mac, full I2S, 19 (of 25) analog, 5 (of 6) serial, 2 (of 3) SPI and 3 (of 4) I2C to the outside pins. The 6th serial, 3rd SPI and 4th I2C might be available on bottom-side pads or a DIY connector. About 30 digital pins with no unique peripheral functions probably won't come out at all.

I'm exploring some special ideas for the JTAG pins....

Of course, this could all change, especially if the board turns out to be impossible to route with only 6 layers.

I will be reading this thread, even if I don't answer everything. Please understand Teensy3++ will be a breadboard format board, likely 48 pins, where the left-side tries to be as compatible as possible with the 28 outside pins of Teensy 3.1 and Teensy LC. Alternate form factors or abandoning Teensy 3.1 compatibility are not up for discussion. A high density connector is unlikely, but not totally out of the question.
 
Just flapping my gums in the wind:

How about omitting through holes on the right side, and replacing it with edge pads instead? You'd get twice the number of outputs on that side in the same space, same pitch, and there's probably lots of suitable 0.1" pitch two-sided card edge connectors for those who want to use one.

For breadboarding, one would probably need to solder a flat ribbon cable to the side -- maybe reuse an old IDE cable?. Using a double-row angled pin headers (inner row soldered to the edge pads on the bottom side, outer row to the edge pads on the top side of the board) is probably too fragile for repeated insertion.

A hedgehog would also work for me. You know, instead of pins or pads or through holes, short ribbon cables soldered to the sides. You could obviously retain backwards compatibility in the pinout (on both sides), while providing lots more pins. It might also be a way for easier integration into larger projects, maybe.
 
Last edited:
There seems to be only 1 clear consensus in this conversation. When the question is which pins to prioritize, the answer is approaches to make more/all pins available!

For now, I'm going to try to bring all 20 PWM, all touch sense, both DAC, both CAN, ethernet mac, full I2S, 19 (of 25) analog, 5 (of 6) serial, 2 (of 3) SPI and 3 (of 4) I2C to the outside pins. The 6th serial, 3rd SPI and 4th I2C might be available on bottom-side pads or a DIY connector. About 30 digital pins with no unique peripheral functions probably won't come out at all.

I'm exploring some special ideas for the JTAG pins....

Of course, this could all change, especially if the board turns out to be impossible to route with only 6 layers.

I will be reading this thread, even if I don't answer everything. Please understand Teensy3++ will be a breadboard format board, likely 48 pins, where the left-side tries to be as compatible as possible with the 28 outside pins of Teensy 3.1 and Teensy LC. Alternate form factors or abandoning Teensy 3.1 compatibility are not up for discussion. A high density connector is unlikely, but not totally out of the question.

Ironically enough on my Egocart motor controller im not using pins 2-13 on my Teensy 3.1, but those are the only free pins I have left now since I needed all the rest for measuring voltages/current/inputs. I avoided eating those pins up in case I want to add on later I have access to UARTs and SPI, I would have done the same for the I2C but I needed the analogs.

The more pins we have access to the more possibilities we have access to, if we are limited by a small number of peripherals we will be limited to what we can do with the Teensy 3++. Sure you can add IO extenders but those cost time and not all projects have room for time spent polling external peripherals.

Im sure you will have to make hard choices to get as much as possible onto such a small package.
 
Status
Not open for further replies.
Back
Top