Future Teensy features & pinout
- Thread starter PaulStoffregen
- Start date
@PaulStoffregen, I was interested in the multi-core / RTOS features in the MiMXRT117x SDK as it might apply to the new Teensy. I reviewed the 1170 data sheet and reference manual but they had little-to-no info on programming other than memory and register maps. It does not appear that NXP has released a public RT1170 SDK or programming guide, the latest one on their website was the RT1164 SDK. I have not developed for NXP before, perhaps I missed something on their website. Do you have access to a programming manual / SDK for the RT1170, and are you allowed to share? Thanks!
There reference manual is here :https://www.nxp.com/docs/en/reference-manual/IMXRT1170RM.pdf
The SDK should be part of the MCUXPRESSO, I think. It's downloadable @ NXP, too. There are some more documents, too. It might be needed to create an account.
I don't think Paul will support an RTOS.
The SDK should be part of the MCUXPRESSO, I think. It's downloadable @ NXP, too. There are some more documents, too. It might be needed to create an account.
I don't think Paul will support an RTOS.
DavidWH1968
Active member
I think NXP has only just released a proper SDK for the RT117x family. The beta testers have been using the RT1160 SDK and limited RT1170 documentation, and it's only partially compatible with the 1170. (Register addresses must be remapped for peripherals, peripheral instance counts are changed, and new peripherals are not defined at all.)
I've got no idea why everyone is so worried about how to work with 2 processors in this chip. It will be a learning curve for those that haven't done multi-core programming before, but shouldn't be very difficult once the concepts NXP has implemented are understood. (Definitely easier than learning something like the USB specification!) An RTOS will make it easier, but it shouldn't be that difficult to implement in a bare-metal firmware.
Anyhow, I'm hoping that the LCD interface, the 32-bit SDRAM, and octal-SPI interfaces will be put to use in this new Teensy board. It will make for a real power house board that will make for some seriously innovative products based on it!
I've got no idea why everyone is so worried about how to work with 2 processors in this chip. It will be a learning curve for those that haven't done multi-core programming before, but shouldn't be very difficult once the concepts NXP has implemented are understood. (Definitely easier than learning something like the USB specification!) An RTOS will make it easier, but it shouldn't be that difficult to implement in a bare-metal firmware.
Anyhow, I'm hoping that the LCD interface, the 32-bit SDRAM, and octal-SPI interfaces will be put to use in this new Teensy board. It will make for a real power house board that will make for some seriously innovative products based on it!
It would be interesting to see a Teensy variant with more pins exposed (e.g. a teensy 5.2?) The NXP chips have so many capabilities limited by the smol formfactor of the Teensy.
While good for 99% of usecases, I'd for instance accept a larger teensy (a chonky?) to get access to, for instance, the lcd interface (especially if we get more RAM! drool...). Maybe even finally an exposed JTAG that we could use to debug code for eventual use on the smaller formfactor boards? Would be neat.
While good for 99% of usecases, I'd for instance accept a larger teensy (a chonky?) to get access to, for instance, the lcd interface (especially if we get more RAM! drool...). Maybe even finally an exposed JTAG that we could use to debug code for eventual use on the smaller formfactor boards? Would be neat.
defragster
Senior Member+
The T_4.1 package is : LFBGA196 and 12 x 12 mm, 0.8 mm pitch, ball matrix
The 1170 package is : LFBGA289 and 14 mm x 14 mm, 0.8 mm pitch
There was a note IIRC the board would have to be bigger just to hold the MCU.
The 1170 package is : LFBGA289 and 14 mm x 14 mm, 0.8 mm pitch
There was a note IIRC the board would have to be bigger just to hold the MCU.
I agree. The teensy without JTAG makes development of software with any level of complexity far more difficult than it needs to be due to lack of debug capability. JTAG requires only a few pads for an unpopulated SMT connector or pogo pins, so there need be no cost impact. If you lack sufficient real estate to route to a JTAG connector, at least bring out the TCK, TMS, TDI and TDO signals from under the chip. Even if they don’t end up in the same location on the PCB we can hack something together post assembly.
DavidWH1968
Active member
Agreed! The JTAG debug pins will be necessary for debugging more complex firmware/software. (And with the RT1176 many will be adding more functionality/complexity to projects implemented on the board. As indicated, only the minimum of JTAG is truly needed, and will be very useful even if they are scattered from one end of the board to the other.
I liked the idea one poster had to add one or two extra rows on each long side of the board. Even one extra row of pins on either side of the board could easily allow routing the 32bit SDRAM interface out to pins for access. (The 200MHz SDRAM interface in the chip is VERY alluring!). The only issue I see with routing out the pins for SDRAM is the need for length matching of the traces could eat up a fair amount of real estate and complicate the routing of some other signals.
As far as the LCD interface goes, some SMT pads for a 40 or 50 pin FFC connector would indeed be great and allow us to truly utilize the GPU to make outstanding user interfaces. (I recall that the datasheet indicated 1366x768 max resolution and 32bit color with alpha blending in hardware!)
I liked the idea one poster had to add one or two extra rows on each long side of the board. Even one extra row of pins on either side of the board could easily allow routing the 32bit SDRAM interface out to pins for access. (The 200MHz SDRAM interface in the chip is VERY alluring!). The only issue I see with routing out the pins for SDRAM is the need for length matching of the traces could eat up a fair amount of real estate and complicate the routing of some other signals.
As far as the LCD interface goes, some SMT pads for a 40 or 50 pin FFC connector would indeed be great and allow us to truly utilize the GPU to make outstanding user interfaces. (I recall that the datasheet indicated 1366x768 max resolution and 32bit color with alpha blending in hardware!)
Some people just like eating more than cinnamon toast crunch
The dual core nature of the new MCU means we can rather easily offload software emulation of various protocols like UART/SPI/etc on the other (GPIO) pins if we need to, without adversely affecting other code. The more heavy duty (or ones we can't reliably emulate) ones like LCD/SDRAM/JTAG would be more useful exposed (that for some, we could even potentially just use as additional gpio if we needed, maybe?)
I haven't been this excited about the prospects of a board in awhile, this is going to be very exciting and my current project which makes a UI with a RA8875... I'd do anything to replace that slow thing, lol. (I could also be less lazy and rewrite the Adafruit driver, but... I'm too lazy
)DavidWH1968
Active member
Frank B:
I fully agree with you about the real need for 8 serial ports. If one were to be developing a multi-port serial hub for a project it's quite unlikely that an MCU as powerful as this is going to be either needed or used. A Teensy 3.6 or 3.5 would be more appropriate. But if a project such as an HMI display controller were being developed, then 1, maybe 2, serial ports might be used, and the attraction to this level of MCU would be for the speed in processing complex graphics commands.
I mentioned the memory pin-out specifically because working with the narrow data bus like the PSRAM on the T4.1 is very crippling for the MCU since it spends a large portion of it's time waiting 8 SPI bus cycles for a single word from RAM, and even an 16 bit parallel SDRAM bus would be more than 5 times faster, while a 32 bit data bus would yield a >10 times improvement for extended RAM access.
The RT1176 has been specifically designed with near laptop level display technologies in mind, so I personally believe that the SDRAM and LCD functionalities are virtually a must.
I fully agree with you about the real need for 8 serial ports. If one were to be developing a multi-port serial hub for a project it's quite unlikely that an MCU as powerful as this is going to be either needed or used. A Teensy 3.6 or 3.5 would be more appropriate. But if a project such as an HMI display controller were being developed, then 1, maybe 2, serial ports might be used, and the attraction to this level of MCU would be for the speed in processing complex graphics commands.
I mentioned the memory pin-out specifically because working with the narrow data bus like the PSRAM on the T4.1 is very crippling for the MCU since it spends a large portion of it's time waiting 8 SPI bus cycles for a single word from RAM, and even an 16 bit parallel SDRAM bus would be more than 5 times faster, while a 32 bit data bus would yield a >10 times improvement for extended RAM access.
The RT1176 has been specifically designed with near laptop level display technologies in mind, so I personally believe that the SDRAM and LCD functionalities are virtually a must.
Need 8 ports? pretty uncommon. But need 12-16 more GPIO pins? Way more likely. And LCD pins? Hell yes. I'd love to see a Teensy 4.0 format with 2 rows of pins on either side. Put the less needed functions on the outside pins. Probably won't happen because of the commitment to being breadboard friendly.
And, +1K to a debug connector.
And, +1K to a debug connector.
DavidWH1968
Active member
MeBoop: I second your opinion of the RA8875/6/7! Any GPU that is so slow that you can actually watch the screen update is terrible! The GPU in the 1176 promises to bring REAL graphics functionality to the world of the MCU! I would certainly be a shame to not have that available.
DavidWH1968
Active member
No one ever said you have to put the second row of pins facing the same direction as the first row, or that it had to be a row of pins for that matter. Just put the pins one the board with on row facing up, and the other row facing down and it is again breadboard friendly.
Freescale app note AN4507 discusses the various options for securing Kinetis flash. Teensy uses an external chip for the bootloader, it might be possible to lock that IP from JTAG access while allowing access to user flash & ram. @PaulStoffregen can you comment on this?
DavidWH1968
Active member
Yes, the TRNG will enable that.
I ended up having to create a driver to use my PC to render for testing because the RA was just so slow lmao (and it doesn't even support scissor rects? ew!)
While not unlikely, I feel the requirements to get NXP on your side do enough to prevent clones; and the level of support provided by Paul will keep me a customer of the Teensy over anyone who may clone it. Hell, do a gofundme/kickstarter/whatever to secure/guarantee a level of future capital to soften the blow of a potential clone. I know Adafruit is planning on doing a freescale board and I'd be willing to bet they'll be including a JTAG port, so I'd hate to have to move from the Teensy because of the lack of hardware debugging.
While not unlikely, I feel the requirements to get NXP on your side do enough to prevent clones; and the level of support provided by Paul will keep me a customer of the Teensy over anyone who may clone it. Hell, do a gofundme/kickstarter/whatever to secure/guarantee a level of future capital to soften the blow of a potential clone. I know Adafruit is planning on doing a freescale board and I'd be willing to bet they'll be including a JTAG port, so I'd hate to have to move from the Teensy because of the lack of hardware debugging.
Dont know if that has changed lately but in the past their libraries had horrible bad code...
I once saw a graphic driver and other libs and i decided not to spend time with this ... ok that was a few years ago.
The code isn't horrible, it's just clearly pumped out quickly. I've turned it (their RA8875 lib) into a gruesome abomination of what theirs originally is, and then shoved an abstraction layer on top of that so I can use it on my PC (because my cats are assholes and shattered the resistive touch layer and I didn't want to wait for a new screen to arrive)
With a dedicated LCD interface, we could do so many cool things that would otherwise take cycles away updating the screen with other chips, such as embedding FreeType (this one holds a lot of excitement with me rn) or using stb_truetype without having to worry with how slow blitting to another FB or uploading RGB pixels over SPI can be.
I'll probably get an ILI display (like the one PJRC has in their store), but the reduced resolution kinda stinks and makes it harder to do the silliness I want to.
Well! Reading the recent posts woke me up a bit! Real estate is not a serious problem for me (famous last words), so I could use a separate, earlier generation Teensy (or even a Teensy 4.0) as a slave to offload mundane stuff, and just have the new Teensy tell the slave what to do using one of the various available interfaces.
I always need more processing power, though!
I always need more processing power, though!
DavidWH1968
Active member
As far as their libraries go they are what most any other manufacturer provided libraries are: Turned out quickly and not optimized. I've run into this with virtually all supplier related libraries. If you need serious performance you need to rewrite all (or almost all) of the most critical and frequently called functions.
I've done this with the SSD1963 LCDC and gotten the solid color fill up from about 25Mpps to 125.5M pps, and my bitmap/multiple color fill rate up to 35Mpps using a 16 bit interface with RGB565 color.
I approach every project with the idea in mind about the most critical parts, and I resolve myself to rewrite those critical interfaces myself, sometimes using assembly, but mostly using optimized C code. I find that if I do anything less I end up with something mediocre. (Although I create the initial implementation as something mediocre, then optimize.) It sometimes adds significant time to the development process, but normally the added time is fairly moderate. (Some time reading datasheets is very helpful, and staying with one manufacturer is even more helpful.)
PS: If you can deal with a very timing critical LCD controller I think the SSD1963 would be a better choice than an ILI. I've had better luck with wringing out very high performance fill rates, and the instructions sets are very similar.
I've done this with the SSD1963 LCDC and gotten the solid color fill up from about 25Mpps to 125.5M pps, and my bitmap/multiple color fill rate up to 35Mpps using a 16 bit interface with RGB565 color.
I approach every project with the idea in mind about the most critical parts, and I resolve myself to rewrite those critical interfaces myself, sometimes using assembly, but mostly using optimized C code. I find that if I do anything less I end up with something mediocre. (Although I create the initial implementation as something mediocre, then optimize.) It sometimes adds significant time to the development process, but normally the added time is fairly moderate. (Some time reading datasheets is very helpful, and staying with one manufacturer is even more helpful.)
PS: If you can deal with a very timing critical LCD controller I think the SSD1963 would be a better choice than an ILI. I've had better luck with wringing out very high performance fill rates, and the instructions sets are very similar.
Hmm, buydisplay has a preassembled 1963 7".. I may give that a go, thanks for the suggestion. As my application is just a GUI, I don't really see it pertinent to have super fast update rates, but I'm always down to play with more displays (esp. since my cat mostly murdered mine)
DavidWH1968
Active member
My current application is similar. A display accelerator for a retro-style computer. It's actually fast enough for a 2msec screen clear at 800x480x16bits. Also fast enough for a basic 3d library to be used. The RT1176 will improve the application significantly, allowing the CPU to mostly only focus on the 3d math when needed. (3d for a gui environment.)
But I think we are getting off topic here.
But I think we are getting off topic here.
We're just drooling at the prospects of the new Teensy haha, I'm super excited