Future Teensy features & pinout

[mlewus]

Also, a straight C SDK with Makefiles. In addition make an easy to use C library for all the peripherals such as GPIO, I2C, SPI, UART, I2S, interrupt handling, sleep modes, filesystem, Bluetooth etc. Something akin to the RP Pico SDK.

Most, if not all of this, is available already. NXP supports its iMX.RT chips with the MCUExpresso package which includes a SDK that is based on the Arm CMSIS. They also offer FreeRTOS, iwIP, FATfs, and other middleware stacks.

NXP provides example projects for gcc and cmake. If you prefer an IDE you can use eclipse or PlatformIO, or (paid) Keil or IAR.

Info here:
https://www.nxp.com/design/software/...MCUXpresso-SDK

[PaulStoffregen]

If there's any way to integrate an FPGA that would be neat. Other Arduino units like the MKR Vidor 4000 do this.

Yes of course there are ways, but they all end with a high retail price similar to Arduino Vidor.

Another cool thing about the Vidor 4000 is it has a PCI-E edge connector, so you can use the thing as a PC add-in card.

I believe you meant mPCIe (Mini PCI-E), which is physically quite different from regular PCI-E slots.

How common is mPCIe on today's computers? All the info I can find looks like M.2 has won over the market, much like how all PCs today have USB and almost none come with Firewire ports. With M.2, it seems most user-accessible sockets use M key, with B key being a distant second. It seems A & E key are only common for Wifi cards, and only on certain machines (where using an E or A slot peripheral would require giving up your Wifi hardware, and opening the machine in ways not commonly done by end users).

My main question is how viable is use of Vidor in the sockets actually present on most PCs?

Or hypothetically speaking, if a Teensy were made with M.2 form factor following PCI-SIG's NGFF standard (eg, not Sparkfun's MicroMod pinout), which key/slot should be used and how realistic would that be to actually use with most of today's PCs?

Both features together would enable a sweet Teensy-based sound card with on-board processing...if only it had the DACs!

Now I'm really confused! How would DACs fit into mPCIe or M.2 usage model? I see M.2 B-key has a definition for audio, but a few quick searches don't turn up any products (but it seems BMW makes a car named "M2" which can come with a sweet sound system).

I just don't have a clear idea of how many people (or almost anyone really) would use this with their PCs. Please explain? Or can you show me cases were people have really used Arduino Vidor this way?

[bigpilot]

A "straight C SDK" is definitely not the direction PJRC will go. But I do want to move to using makefiles.

I have no comments on breakpoint debug at this time....

Good to hear. But if not Makefiles, what other options are there? Your own JSON project files?

[ecurtz]

It might be too much of a compromise to make sense, but it seems possible to do a form factor that includes both the through hole breadboard headers on the sides and the MicroMod M.2 connector on one end.

[blackketter]

One way to expand the number of pins available would be to provide double-density castellations along the edge. The Alorium Evo M51 does this. Every 0.1" spaced through-hole pin is brought out to a castellation at the edge. Between each of those connections is another pin, for net spacing 0.05". This provides roughly twice the pin count and makes the board surface mountable.



More details on this board here: https://aloriumtech.com/evom51-quickstart/

So, for folks who need 0.1" spacing for breadboards, you've got the regular through-hole pins. If you need more pins or surface mountability, use the edge connections.

Also, with a jig, it's possible solder 0.05" pins along the edge to make it socket-able.

[Frank B]

Thats a nice idea.

[u_cap]

Well, this is also a discussion of pinout & form factor for the next Teensy.

Well, I know it is a niche, but I'd really like to get all 16 QUAD timers on 16 pins ...

[blackketter]

I just don't have a clear idea of how many people (or almost anyone really) would use this with their PCs. Please explain? Or can you show me cases were people have really used Arduino Vidor this way?

My interest in M.2 was as a cheap, higher density connector and not for mPCIe connectivity. For the Vidor it kind of makes sense given the FPGA on board. The applications that make sense to me for a Teensy with mPCIe would not be to use Teensy as a PC peripheral, but for the Teensy to be the PCI host.

Generally, though I think that a Teensy with either a mPCIe or MicroMod connector would be a solution looking for a problem.

[bigpilot]

Good to hear. But if not Makefiles, what other options are there? Your own JSON project files?

I totally misread Paul's answer.

But if not a C SDK what then? Arduino would be a mistake IMHO. Teensy is for tinkerers who are fluent in C and comfortable with manipulating registers and such.

[mlewus]

I totally misread Paul's answer.

But if not a C SDK what then? Arduino would be a mistake IMHO. Teensy is for tinkerers who are fluent in C and comfortable with manipulating registers and such.

Arduino as an IDE is, I agree, terrible. But Arduino as a framework can be very useful to throw together simple projects. And there's nothing in it that prevents you from twiddling registers if you want. I find PlatformIO plus the Arduino framework to be an agreeable pair as it enables library management per project and debugging, and a far superior editor.

Arduino has dropped the beta of 2.0 which is an Eclipse based IDE with a better editor and built-in support for debugging. I haven't tried it yet but it might be another acceptable solution

If I could add one software feature to the new Teensy it would be a UF2 bootloader, so you can just drop code on a virtual drive.

[bigpilot]

Teensy is going to lose out eventually if debug capability isn't provided at some point.

RP Pico has debug capability. It runs the debugger one core and the application on the second core. Haven't seen it yet in action.

I would, at this point,only choose Teensy if I needed some special capability (such as I2S) for my project. For most other use cases I'd pick RP Pico.

[Frank B]

Mlewus you could do that now. Add it as "second stage bootloader" (just a program-part that writes your program to flash..)

[Frank B]

Well, Paul said, no breakpoints. Not sure why - I know the bootloader jumps in on breakpoints - but dont know why the chip cant be disabled - but i can live with it seeing the speed. But then, it really need to have enough other functionality. (Pins)
I agree: no debug and then the current teensy pincount only is not enough. It has more ram too, so a dedicated display connection would be a nice thing. In addition to the outer double rows, and SD slot of course
I promised not to speak about a RTOS-thing again, so...

Edit:
I wonder what the state re: hardfaults, etc is. We have a nice way to detect nullpointers, stack overflows etc (and I#m working on a way to detect more accesses to unassigned addresses), and it is even activated, but pretty useless as the Teensy jumps into an endloess loop only, without notifying the user. I proposed a way to print some info then and stopped development, because Pauls seems to have something else in mind which is totally ok and probably better - I wonder about the time plan..? It's all together a bit much for a single person!!

Perhaps it would be better to wait a year with the 1176, and add the other features first and plan a good way how to use the 2nd core (if it really must be without rtos - but that would be nice fo T4, too) and *something* that helps with debug´, without breakpoints..
(not to mention the other often read wishes like WiFi or bluetooth...... and more documentation)

[ecurtz]

Generally, though I think that a Teensy with either a mPCIe or MicroMod connector would be a solution looking for a problem.

Low volume commercial products.

[mlewus]

Well, Paul said, no breakpoints. Not sure why - I know the bootloader jumps in on breakpoints - but dont know why the chip cant be disabled - but i can live with it seeing the speed. But then, it really need to have enough other functionality. (Pins)
I agree: no debug and then the current teensy pincount only is not enough. It has more ram too, so a dedicated display connection would be a nice thing. In addition the the outer double rows, and SD slot of course
I promised not to speak about a RTOS-thing again, so...

@Frank B, thanks for the tip about the UF2 bootloader.

I re-read Paul's response about no breakpoints. If you read the OP's question it sounds like he was asking for USB based breakpoint capability, like you get with some of the SAMD boards. Providing for JTAG requires virtually no effort on Paul's part other than bringing out a few pins from under the BGA that can otherwise be used as general IO. I've been banging this drum for a while but I have not read a direct response from Paul as to whether he's willing to support JTAG or not, or if not, why not.

I understand and support the need to protect the Teensy's IP, but I think he can do that and still make debugging available.

It would be great to get a straight answer on this. JTAG or similar debugging is available on most SAMD, PIC32, STM32, and RP2040 boards, as well as other NXP based boards. It greatly reduces the time and effort required to get a complex application out the door. Leaving it out will IMO reduce demand for the new Teensy board.

[Frank B]

Leaving it out will IMO reduce demand for the new Teensy board.

The question is, how much. If one wants high speed, he buys the Teensy without that. If he wants ease of development, and does not need extreme speed you're probably right.

[PaulStoffregen]

I've been banging this drum for a while but I have not read a direct response from Paul as to whether he's willing to support JTAG or not, or if not, why not.

I still have no comment at this time, same as I said on msg #392.

But I definitely do hear. You can set the drum down for a little while if it's getting heavy.

[Frank B]

Espressif said that they are not married to the current chip, and would not have much of a problem switching architectures.
I wonder what will happen when they switch to ARM? On the other hand, there is no point of having a high-end chip for their business segment. But who knows

[mlewus]

I still have no comment at this time, same as I said on msg #392.

But I definitely do hear. You can set the drum down for a little while if it's getting heavy.

Message received! Thanks for all you do for the community.

[kdharbert]

Sorry if this is uneducated (or already possible) but could the Teesny hardware SPI be configured to clock in\out multiple data lines at a time? Teensy 4.x is good about exposing entire ports...does that make it any easier to something like this? It would be crazy sweet to clock in\out entire bytes each cycle.

[mlewus]

Sorry if this is uneducated (or already possible) but could the Teesny hardware SPI be configured to clock in\out multiple data lines at a time? Teensy 4.x is good about exposing entire ports...does that make it any easier to something like this? It would be crazy sweet to clock in\out entire bytes each cycle.

The RT106x natively supports quad SPI, and the 117x supports both quad and octal SPI. These simultaneously clock multiple data lines. The optional external memory (PSRAM / FLASH) on the Teensy 4.1 is interfaced via QSPI so that port is accessible, you would just need to define another chip select.

[KurtE]

The RT106x natively supports quad SPI, and the 117x supports both quad and octal SPI. These simultaneously clock multiple data lines. The optional external memory (PSRAM / FLASH) on the Teensy 4.1 is interfaced via QSPI so that port is accessible, you would just need to define another chip select.

Quick note: the PSRAMS and the like use a different SPI system than your normal SPI, like when you use SPI.transfer();

That is the PSRAM as well as the Flash memory use the FlexSPI controller (chapter 27) where as our normal SPI uses the LPSPI subsystem - Chapter 48.
And I believe that there is only two valid Chip selects for that channel:

48	EMC_24	SEMC_CAS	FLEXPWM1_PWMB00	LPUART5_RX	ENET_TX_EN	GPT1_CAPTURE1	GPIO4_IO24			FLEXSPI2_A_SS0_B	
49	EMC_27	SEMC_CKE	FLEXPWM1_PWMA02	LPUART5_RTS_B	LPSPI1_SCK	FLEXIO1_FLEXIO13	GPIO4_IO27			FLEXSPI2_A_DATA01	
50	EMC_28	SEMC_WE	FLEXPWM1_PWMB02	LPUART5_CTS_B	LPSPI1_SDO	FLEXIO1_FLEXIO14	GPIO4_IO28			FLEXSPI2_A_DATA02	
51	EMC_22	SEMC_BA1	FLEXPWM3_PWMB03	LPI2C3_SCL	ENET_TDATA00	QTIMER2_TIMER3	GPIO4_IO22			FLEXSPI2_A_SS1_B of	
52	EMC_26	SEMC_CLK	FLEXPWM1_PWMB01	LPUART6_RX	ENET_RX_ER	FLEXIO1_FLEXIO12	GPIO4_IO26			FLEXSPI2_A_DATA00	
53	EMC_25	SEMC_RAS	FLEXPWM1_PWMA01	LPUART6_TX	ENET_TX_CLK	ENET_REF_CLK	GPIO4_IO25			FLEXSPI2_A_SCLK	
54	EMC_29	SEMC_CS0	FLEXPWM3_PWMA00	LPUART6_RTS_B	LPSPI1_SDI	FLEXIO1_FLEXIO15	GPIO4_IO29			FLEXSPI2_A_DATA03

Note LPSPI also supports dual and quad spi as well, but I am not sure if there are any of the SPI ports that we have enough of their data pins defined to allow for Quad SPI.
The closest is the main SPI object which is LPSPI4 And we do have PCS0, 1, 2 defined, but not 3 which would be the data 3 pin.

[Frank B]

I'd like to see a SD slot with switch to be able to detect card removals.
And if there ever will be an update of the existing models: For these, please, too.

A 2nd LED. (Edit: Or, a way to control the red bootloader LED)

Then, a reset pin.

Software:
- Saving project properties, defines
- Rebuild all option.
- Reset board option
- Serial monitor with debug messages channel ( 2nd window?)
- vt100

[Zenbob]

A 2nd LED. (Edit: Or, a way to control the red bootloader LED)

There are some tiny RGB LEDs out there now that could make for a nice 2nd LED.
http://www.newstar-ledstrip.com/products-195.html

[thebigg]

I'd like to see a SD slot with switch to be able to detect card removals.
And if there ever will be an update of the existing models: For these, please, too.

+1 / upvote / agree