Forum Rule: Always post complete source code & details to reproduce any issue!
Page 2 of 5 FirstFirst 1 2 3 4 ... LastLast
Results 26 to 50 of 125

Thread: Suggest next Teensy with Cortex M7

  1. #26
    Senior Member
    Join Date
    Jul 2014
    Posts
    1,635
    Quote Originally Posted by Epyon View Post
    For my uses, I would love to see more RAM and flash and more inter-connectivity options while keeping a small form factor and low price point. Granted the 3.6 (and even 3.2) got pretty much everything covered for me now (although more RAM would always be nice), but I would love to see the onboard Ethernet en SDIO interface working reliably before development attention shifts to the 4.0. I have however no doubt this will be the case .
    Concerning more RAM, there is the possibility of a T3.6++ with SDRAM capability (as added board)
    I was also wondering if someone is coming up with a flexible concept for multi-MCU interconnects? I once tested 3 T3.2 connected with SPI, so it is possible.

  2. #27
    Senior Member brtaylor's Avatar
    Join Date
    Mar 2016
    Location
    Portland, OR
    Posts
    274
    Quote Originally Posted by WMXZ View Post
    Concerning more RAM, there is the possibility of a T3.6++ with SDRAM capability (as added board)
    I was also wondering if someone is coming up with a flexible concept for multi-MCU interconnects? I once tested 3 T3.2 connected with SPI, so it is possible.
    I have a pretty lightweight protocol that I use for connecting Teensys that I can post. I use I2C (i2c_t3) with a 3 MHz clock.

  3. #28
    Senior Member
    Join Date
    Jan 2014
    Posts
    120
    Quote Originally Posted by MichaelMeissner View Post
    It will be interesting to see if you go with a wildly different pin layout or numbering for Teensy 4.0 as opposed to 3.x. You've done an excellent job in maintaining the majority of pin compatibility between the LC, 3.0, 3.1, 3.2, 3.5, and 3.6. But I can imagine it is growing creaky to keep this compatibility.

    If possible, I would suggest having VUSB, AREF, and VBAT on the main rows of pins rather than inside and on the back. Reset and program also, but those are more special purpose, and they can live as interior pins. But if not, that is also fine.
    If pin config changed, would hope that more consideration given for noise. Aref and analog ground need a little more protection from that evil digital stuff. 600MHz is an order of magnitude greater than what we typically use (22MHz or 44MHz for T3.2). Otherwise, logistics of another pin-out would be significant for some.

    But if that what PJRC's adoring fans want, so be it. Will be that cranky old geezer still using my stash of T3.1s and T3.2s while yelling at the rest of you to get off of my lawn (recently used last 2313).

  4. #29
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    17,029
    I believe you really need to be programming in assembly on an 8 bit chip, perhaps even 8051 or HC11, to qualify for old "you kids get off my lawn" geezer status.

  5. #30
    Senior Member
    Join Date
    Jan 2014
    Posts
    120
    Quote Originally Posted by jwatte View Post
    Who is the intended customer for that Teensy? I have a hard time filling up the CPU of the 3.5, although I'm out of I/O (again!) Developing applications that use all that power is significant work.
    Same here. Developing with a T3.5 for a calibration bench, and out of I/O, but much flash remaining. Will probably go with two or three T3.2s.

    Quote Originally Posted by jwatte View Post
    Also, if less analog, and 3V only, and external flash, and 600 MHz is important to me, I can get it today in a Raspberry Pi Zero W, cheaper than a Teensy. Then I can use all that power to run Python or something instead of C, and be back at 8 bit AVR speeds...
    External memory = noise. So would do serious analog on separate board. External memory, no signal conditioning, high clock rate, media controllers, security systems, etc - this is the stuff of an embedded OS. Schedulers ok, but no want OS. Is running an OS a PJRC design intention?

    Freaking amazing what you kids are stuffing into ICs these days.

  6. #31
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    17,029
    Quote Originally Posted by BJB View Post
    Is running an OS a PJRC design intention?
    No, certainly not anything like Linux is planned.

    However, the recent work on Arduino event programming and planned improvements in SD, USB Host, Ethernet and other libraries are meant to bring much more functionality similar to some of what you get from an OS.

    My current plan is to *not* require an RTOS, but to work towards APIs and reentrant design that can be more easily used with an RTOS.

  7. #32
    Senior Member
    Join Date
    Jan 2014
    Posts
    120
    Quote Originally Posted by PaulStoffregen View Post
    I believe you really need to be programming in assembly on an 8 bit chip, perhaps even 8051 or HC11, to qualify for old "you kids get off my lawn" geezer status.
    Actually, it would be "get off of my dirt". My 'museum' drawers have 8080s (curse the 2-phase clock and sequencing of the three power rails) and Z80s from S100 projects. 8051/6502 assembler were easy. Never did anything with the 6811. But M0 and M4 assembly hurts my old brain; so this i.MX RT would probably be a deadly end to my retirement plans. But if you build it, will buy it.

  8. #33
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    17,029
    Even though it's exactly the same instruction set as M4, still kinda strange to think we'll soon be running with a superscaler processor capable of (sometimes) executing 2 instructions per clock, and with branch prediction in the pipeline where (predicted) branches no longer cost a couple extra cycles.

  9. #34
    Senior Member
    Join Date
    Dec 2014
    Posts
    234
    Superscalar is not so bad. When the embedded chips start doing out-of-order memory transactions, I will throw up my hands in resignation :-)

  10. #35
    Senior Member
    Join Date
    Jan 2013
    Location
    San Francisco Bay Area
    Posts
    640
    I think it would be really nice to have a very small teensy (without any header pins) that has a high-density connector to get all the available pins.
    This would make it much easier to create small products that still have the bootloader built-in.

    You could do all your testing on the breadboard-friendly teensy, move to small-to-medium production with the teensy-HD (high-density) version, and then build your own custom teensy for large production volumes.
    Possible?
    Last edited by linuxgeek; 07-12-2017 at 02:53 AM. Reason: for clarification

  11. #36
    Senior Member
    Join Date
    Apr 2013
    Posts
    1,685
    @ Linuxgeek - is there that much gained having a Teensy PCB with a special connector that you have to source and mount to your PCB over rolling the parts directly onto your PCB?

    Not disputing a better method from prototype to product would be great but not sure if special connectors and mounting hardware are they way.

  12. #37
    Senior Member
    Join Date
    Jan 2013
    Location
    San Francisco Bay Area
    Posts
    640
    Doesn't help everyone, but for those that need to keep it small, it would really help.
    And I would think it might not be too complicated for pjrc to dump all (or subset) the connections to the connector.

    If size doesn't matter, then I don't think there's any gain, unless you use it to get connections that are left off the board.

  13. #38
    Senior Member
    Join Date
    Dec 2016
    Location
    Montreal, Canada
    Posts
    2,071
    its not so bad using 4 rows of headers on the 3.5/3.6
    but having access to the busses is what makes us wanting to use that many pins, even though the others are not used

    add some flat FPC cables to open more possibilities, for different setups/custom breakouts

  14. #39
    Senior Member
    Join Date
    Dec 2014
    Posts
    234
    By the way:

    don't for one second imagine I'm going to abandon breadboard compatibility for a high density connector like Intel did with Edison
    I hear you on the Edison fiasco!

    I was thinking of something like the Teensy 3.2 form factor along the top/bottom edge, with "one of each" of all the important ports (and maybe two of some,) and then a HD connector on the back of the board for all the additional goodies.

    Also, regarding 5V being "old tech," that may be true, but I'm currently interfacing with the following 5V devices:
    - SPI RGB LED strips (newer than NeoPixels and WS2801!)
    - Ultrasonic range finders
    - TFT touch display
    - RC PWM receiver with telemetry

    These are all good value-for-money, readily available, not-discontinued parts.

  15. #40
    Senior Member
    Join Date
    Jul 2014
    Location
    New York
    Posts
    1,421
    Not sure if the M7 is going to fit on the normal size teensy 3.2 or 3.6 form factor. I have a OpenMV cam that uses a M7 and its a bit wider and adding support chips, not sure final size. My guess its going to have to be a bit wider and longer. Don't mind a HD connector but would like to see an option where PRJC offers units with the underside pins already soldered on . As for 5v tolerance on the pins. I agree that there are still a lot of robotic sensors that use 5v like the Ultrasonic Range finders, RC PWM, both of which I use. Motor shields are a hit and miss depending on power requirements. I have seen some that can use 3v but most I think (this is just seat of pants) would probably still use 5v. Servo's I believe the signal can be as low a 3.3v. Power would definitely have to be a separate. GPS and my 3dr radio are serial so I would assume that would still work but power, again would have to separate unless there will be 5v out supplied on the new teensy like now.

    These are just some random thoughts.

  16. #41
    Senior Member brtaylor's Avatar
    Join Date
    Mar 2016
    Location
    Portland, OR
    Posts
    274
    Quote Originally Posted by mjs513 View Post
    Not sure if the M7 is going to fit on the normal size teensy 3.2 or 3.6 form factor. I have a OpenMV cam that uses a M7 and its a bit wider and adding support chips, not sure final size. My guess its going to have to be a bit wider and longer. Don't mind a HD connector but would like to see an option where PRJC offers units with the underside pins already soldered on . As for 5v tolerance on the pins. I agree that there are still a lot of robotic sensors that use 5v like the Ultrasonic Range finders, RC PWM, both of which I use. Motor shields are a hit and miss depending on power requirements. I have seen some that can use 3v but most I think (this is just seat of pants) would probably still use 5v. Servo's I believe the signal can be as low a 3.3v. Power would definitely have to be a separate. GPS and my 3dr radio are serial so I would assume that would still work but power, again would have to separate unless there will be 5v out supplied on the new teensy like now.

    These are just some random thoughts.
    Let me just confirm from years of experience at the University of Minnesota UAV Labs, that the RC PWM signal can be 3.3V. Also, many GPS receivers and radio modems can use 3.3V TTL with a 5V source (i.e. a 5V power source and a 3.3V TX and RX signal). Many RC receivers operate this way as well, they use a 5V power source, but send 3.3V PWM and SBUS signals.

    So far, since the Teensy 3.6 has been released, I haven't run into any issues being limited to 3.3V signal voltages. But I am careful to check before connecting devices.

  17. #42
    Senior Member
    Join Date
    Jul 2014
    Location
    New York
    Posts
    1,421
    Thanks for the info Brian. Don't have much experience with 3.3v systems. Always made me nervous, getting less nervous now.

  18. #43
    Senior Member Epyon's Avatar
    Join Date
    Apr 2013
    Location
    Belgium
    Posts
    442
    Quote Originally Posted by brtaylor View Post
    Let me just confirm from years of experience at the University of Minnesota UAV Labs, that the RC PWM signal can be 3.3V. Also, many GPS receivers and radio modems can use 3.3V TTL with a 5V source (i.e. a 5V power source and a 3.3V TX and RX signal). Many RC receivers operate this way as well, they use a 5V power source, but send 3.3V PWM and SBUS signals.
    My years of experience at the Ghent University Electrical Energy Lab have left me a bit more worried though . Most 5V TTL parts I use (serial transceivers, LCDs, power ICs etc) are of course happy to receive input at 3.3V, but output signals at their VCC level. This could easily destroy a non 5V-tolerant MCU. Nothing some resistors or a level shifter can't solve, but the engineer must keep an eye out for signal levels. Luckily nowadays most TTL parts are drop-in replaceable with a 3.3V version. LCD's, especially the cheaper ones, in my experience tend to stay at 5V but luckily only require one-way communication in most cases.

  19. #44
    Member dauntless89's Avatar
    Join Date
    Jun 2017
    Location
    Deer Park, WA
    Posts
    37
    Quote Originally Posted by PaulStoffregen View Post
    For starters, the analog features will be less than we have now.
    Are you at liberty to elaborate on this point a little? Perhaps even just a comment on whether it's primarily less capabilities with the ADCs or PWM. Thanks.

  20. #45
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    17,029
    Quote Originally Posted by dauntless89 View Post
    Are you at liberty to elaborate on this point a little?
    Nope, sorry, anything that's not on NXP's public website is covered by NDA. They will publish all the info (unlike certain Chinese chips...) but probably not until the chips are actually for regular sale.

    But just from looking at the "fact sheet", you can see there's no DAC and the ADC is only claimed to be 12 bits.
    Last edited by PaulStoffregen; 07-24-2017 at 10:21 PM.

  21. #46
    Member dauntless89's Avatar
    Join Date
    Jun 2017
    Location
    Deer Park, WA
    Posts
    37
    Understood. Thanks.

  22. #47
    Senior Member
    Join Date
    Jul 2014
    Posts
    138
    Quote Originally Posted by PaulStoffregen View Post
    But just from looking at the "fact sheet", you can see there's no DAC and the ADC is only claimed to be 12 bits.
    I think this makes sense given the noise problem & the target market, and would say that alongside the release of a Cortex M7 it would make sense for the community (or Paul, time permitting) to release a small reference board in the same form factor as the Teensy (perhaps piggybacking the DIO pins with DIO pins set to high impedance) with an ADC/DAC/Reference (2 channels of each with a multiplexer on the ADC to 8-16 pins) with decent software support.

    I'm excited to think about this being released in a few years but I am in the fortunate position that the Teensy 3.6 has just enough horsepower for my most demanding projects.

  23. #48
    Junior Member elfarolab's Avatar
    Join Date
    Dec 2015
    Location
    Italy
    Posts
    13
    Hello all,

    I would like to add few thoughts to this interesting thread:

    not so many are aware of the application differences between a realtime hardware and a Linux OS board with a scheduler, my job is electronic engineer, independent contractor and almost all my new customers, they usually come with the request to implement every kind of products you can imagine with the Raspberry PI and Linux, even for robots, controllers, UAV, all applications typical of the realtime world. This attitude is largely influenced by hackers/makers community, which I support of course, but not beyond the scope of exploration, testing ideas and laboratory to earn knowledge, industrial products requires appropriate design.

    Even if exists a Linux kernel version with a pseudo realtime scheduler, its proper applications are still limited to video/medias processing, VOIP, audio processing, applications typical of a shared OS environment as desktop or industrial appliances. Deep learning or OpenCV are software applications for an high level OS for instance.
    Realtime MCUs are designed for other kind of applications where deterministic interruptions are crucial, GPIO events or timed functions needs to get executed at precise moments, examples are self balancing robots or UAV controllers such as the Pixhawk. Recently BleagleBone came out with a Blue version specific for robotics, the Linux OS is running on the ARM cortex-A8 core but all the realtime stuff get executed inside 2 integrated PRU 32-bit realtime microcontrollers specific for those kind of applications, there is no way to achieve the execution of realtime tasks inside an OS running on a Raspberry PI for instance.

    So different applications require different hardware architectures.
    The Teensy 4.0 aims to improve and expand the design possibilities in the realtime world, maybe with a realtime OS such as NUTTX or FREERTOS, there are many more..

    These days I am designing a device with RTK+PPK GPS capabilities based on Teensy 3.6, it needs to have a maximum acceptable latency in order of the ms, added with other heavy processing of the readings from sensors.
    The future Teensy 4.0 will be useful in my case, because one day I need to add an integrated crypto hardware accelerator in order to support encrypted datastream in realtime and at the same time, to integrate all the features of an UAV controller.

    I feel we are just at the beginning with these high performances realtime MCUs, there are plenty of real world applications for the next Teensy 4.0, applications that finally can be implemented with just a single MCU, so I am happy to hear about this new version.

    Best luck Paul!
    Last edited by elfarolab; 08-09-2017 at 07:00 PM.

  24. #49
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    17,029
    Quote Originally Posted by elfarolab View Post
    one day I need to add an integrated crypto hardware accelerator in order to support encrypted datastream in realtime and at the same time, to integrate all the features of an UAV controller.
    Teensy 3.5 & 3.6 already have a crypto accelerator.

    Here's the port of Freescale's sample code:

    https://github.com/PaulStoffregen/CryptoAccel

  25. #50
    Junior Member elfarolab's Avatar
    Join Date
    Dec 2015
    Location
    Italy
    Posts
    13
    I already have an application for it. Cool!

    Thanks Paul

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •