Forum Rule: Always post complete source code & details to reproduce any issue!
Page 5 of 5 FirstFirst ... 3 4 5
Results 101 to 114 of 114

Thread: Future Teensy features & pinout

  1. #101
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    3,448
    I had signed up with NXP in order to get the 1062 datasheet before Paul made it available on PJRC.COM. I just got mail that NXP's buyout of Marvell is nearly complete (evidently it will be complete on December 6th). Now, this was originally announced in May, but I didn't see it then.

    I'm sure Paul can't comment at the moment due to NDAs and such, but I can imagine some Teensy users would like it if there was a variant of the 1170 that included wifi and bluetooth that Marvell might provide.

  2. #102
    Senior Member
    Join Date
    Apr 2019
    Posts
    156
    this board has a great layout as a development board - you could get lots of new users involved in Teensy if we had something like this

    https://i.ebayimg.com/images/g/4YQAA...Ts/s-l1600.jpgClick image for larger version. 

Name:	s-l1600.jpg 
Views:	48 
Size:	153.8 KB 
ID:	18343

  3. #103
    Junior Member
    Join Date
    Dec 2012
    Posts
    18
    I think NXP has benchmarks using different types QSPI, HyperRAM, HyperFlash for code and data. For code, I think it would be better to use HyperFlash over QSPI, with a 1Ghz processor, the more bandwidth the better. Yes, there is ITCM and internal RAM, but why waste the RAM when HyperFlash is about 2.5x faster?

  4. #104
    Junior Member
    Join Date
    Dec 2019
    Posts
    2
    Hi Paul - just wanted to chime in with another +1 for JTAG debugging support. There's amazing work being done on alternative IDEs (specifically PlatformIO for VS Code), but these come with a requirement for a proper JTAG debugger. Would love to see this capability made available in a future Teensy.

  5. #105
    My thoughts on features for the future Teensy

    1. Pinout exposed such that an Ethernet Shield can be added to the Teensy (Teensy would NOT have the RJ45 jack on it, just necessary pins)
    2. If I am reading the internet correctly, there is support for multi-threading: put multi-threading on the teensy.
    3. The capability to program the Teensy without Arduino IDE, but on the command line. An example use case would be to use GCC 9.x.x and then import the necessary libraries.

    First thing:

    I know that Ethernet appears to be a niche issue since we all probably have Raspis anyways, but there is a business case for the functionality.

    The Raspi has a long boot sequence that requires a password. There is also a GUI process that slows things down (I know there are ways to turn off the GUI service).
    The Teensy 4 has a super high clock speed that allows for real-time CAN bus whereas other small linux computers have only a few more Mhz more.

    (Given that my focus is more in the robotics area)

    I know that there are some control systems that use ethernet to communicate (like a full-fledged desktop) to send sensor data. Sensors like Sick laser scanners or Cognex cameras use Gigabit ethernet for real-time visual processing.
    The use case I would want is a gigabit link with a Teensy 4 so that I can then expose a sensor like an IMU to the network.
    A real-time ethernet gyro cost multiple thousands of dollars and is far too expensive for hobbyists.
    A simple 15 or 20 dollar shield to give the Teensy networking functionality would allow for more real-time control of robots at orders of magnitude less costly parts.

    Then, the sensor could be integrated into the new ROS2 framework with DDS (I know, a yuuuuge stretch: I can dream still).

    This hardware configuration would allow for any non-robotic system to be converted to semi-autonomous or fully autonomous with little effort.


    Second thing:

    I find that I am holding up sensor reading processes in the data publishing process.
    In my desktop software, I use multi-threading to separate human or sensor input from the computer operation functionality.
    This functionality would further speed up software, even without faster clock speeds.
    In fact, for my use cases (maybe not for everyone), a 600 Mhz clock is way more than necessary when multi-threading is available.
    The separate threads would also both need access to the pinout hardware, not just a separate software thread.


    Third thing:

    This functionality may already be there, I just don't see any official support.
    I have heard both support and negation to the claim that you can program without the Arduino IDE, but I can't figure out which is true.
    Some clarity would be great.


    A few more side notes:

    I also want the newest Teensy to be in a T3.6 form factor. It would be great if the Teensy lineup followed some expected pinouts beforehand.
    This would make getting shields to fit across board models easier.


    Thanks guys

  6. #106
    Senior Member
    Join Date
    Feb 2015
    Posts
    136
    Just my two cents: point 2 can be accomplished with an RTOS, point 3 is a toolchain thing. There are many, many ways to skin both of those cats, but it would be best to make a dedicated thread and ask for help.

  7. #107
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    21,065
    This thread is about a farther future product using the not-yet-released 1170 chip.

    Most of the things you've mentioned exist now, or will come sooner with a 1062-based board in the Teensy 3.6 form factor.


    Quote Originally Posted by thatrobotman View Post
    1. Pinout exposed such that an Ethernet Shield can be added to the Teensy (Teensy would NOT have the RJ45 jack on it, just necessary pins)
    This will be coming, using the TI DP83825I Ethernet PHY chip and 6 pins for the connection to the magnetics & RJ45 connector.


    2. If I am reading the internet correctly, there is support for multi-threading: put multi-threading on the teensy.
    3. The capability to program the Teensy without Arduino IDE, but on the command line. An example use case would be to use GCC 9.x.x and then import the necessary libraries.
    Limited support for threading already exists, using the TeensyThreads library. However, many Arduino libraries are not fully reentrant or designed to be safe to access from more than 1 thread. Teensy is only a small part of the huge Arduino ecosystem, so that situation is unlikely to change anytime soon.

    The sample makefile for Teensy 4.0 was recently updated. Other people have published makefiles too. There is a command line only Teensy Loader, if you don't wish to use the GUI one. You certainly can do everything only from the command line if you really want.

    Eventually Teensyduino will migrate to a newer gcc toolchain. But that's not going to happen while so much other stuff is in rapid development. I believe Frank or Manitou did some benchmarking with the newest (at the time) toolchains during the Teensy 4.0 beta test and saw the coremark benchmark was slightly slower than we have now. So we're probably going to keep things stable on the older version we use today, until gcc performance improves on newer versions.

    Of course, there's no reason why you can't try using a newer toolchain. Many things do work. Obviously they were able to get coremark to run, and enough of the USB stack to see the results. But with newer toolchains usually bring lots of minor breakage and annoyance. So far they seem to come with a slight hit in performance of optimizations. Maybe you *really* want some specific newer C++ dialect feature? Other than that, don't assume newer is always better.

  8. #108
    Senior Member
    Join Date
    May 2015
    Location
    San Francisco
    Posts
    209
    Quote Originally Posted by thatrobotman View Post
    3. The capability to program the Teensy without Arduino IDE, but on the command line. An example use case would be to use GCC 9.x.x and then import the necessary libraries.
    Platformio provides a terrific command line build environment for all the Teensies and hundreds of other boards. It also works with VisualStudio, if that's your preference.

    Highly recommended.

    https://platformio.org

  9. #109
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,794
    For teensy 4.{something} with 1170:

    The ESP guys are using a function named "xTaskCreatePinnedToCore()" to assign a task to a specific core. I like this idea.
    It will be interesting to know how the 1170 handles the memory, espcially the stack for both cores.
    The easiest, for users, would just be something like loopCore1() for the 2nd core..

  10. #110
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    10,310
    Quote Originally Posted by Frank B View Post
    For teensy 4.{something} with 1170:

    The ESP guys are using a function named "xTaskCreatePinnedToCore()" to assign a task to a specific core. I like this idea.
    It will be interesting to know how the 1170 handles the memory, espcially the stack for both cores.
    The easiest, for users, would just be something like loopCore1() for the 2nd core..
    Very interesting to see how it resolves. With twin CPU's one each of M4 and M7 core type and speed - versus two equivalent same speed cores like ESP32 where they built with a version of RTOS to hide under Arduino it can more directly support that having a task pinned or float between them with shared memory pool. On 1170 the two cores have IIRC unique memory areas and a defined overlap area? It seemed like it would take building of two HEX files and tasks would be programmed and dedicated to one core or the other?

    As far as command line building - at least on Windows - FrankB resolved a command line batch file usable from 'editor of choice' that can execute a batch file from the current file folder. It fully builds just like the IDE from same tools and sources - using TyCommander for Upload and SerMon. I tweaked that to allow building the command file for a given teensy and boards settings as github.com/Defragster/Tset. A common TSET batch file prompts and creates a local batch file that runs from a DOS box, Windows file explorer, or editor of choice ( tested and used on SublimeText ). AFAIK that 'batch file' should be adaptable to Linux script - but not made or seen any effort to do that.

  11. #111
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    21,065
    Quote Originally Posted by Frank B View Post
    It will be interesting to know how the 1170 handles the memory
    Today with with 1062 we get 512K is TCM for M7 and the remaining 512K is accessed by slower AXI bus.

    Soon with 1170, we'll get the same 512K as TCM for M7, and 256K as TCM for M4, and the remaining 1280K on AXI bus for both of them to use. The M7 side appears to be pretty much the same as we have now in Teensy 4.0, but with 1280K of OCRAM2 instead of only 512K, and of course 1 GHz clock.

    The M4 situation with RAM is pretty similar to Teensy 3.6, except at 400 MHz. All of the 256K ram in Teensy 3.6 is TCM. The ram in Teensy 3.6 at 20000000 and above can be considered DTCM, and the ram at 1FFFFFFF and below can be considered ITCM. The M4 core uses 2 buses which map into those RAM banks. M4 has no separate bus for other stuff, so the situation isn't quite analogous to M7 with 3 buses.

    On Teensy 3.6, we currently have an 8K cache for code, and there's no cache for data (and we don't have any other memory which could use such a cache). On 1170 we'll get a 16K cache for non-TCM code and 16K cache for non-TCM data, which is the 1280K of RAM shared between to M4 and M7. Historically we've never worried about caching on M4 because all memory was TCM or peripherals. But 1170 will bring 1280K of memory shared, with caching to manage on both sides.

    On the 1280K shared RAM, it's not clear to me if it's all created equal. Looks like it may be in 3 independent banks, which is a good thing if you want to have both cores access the memory by their DMA controllers. Two banks of 512K may be intended for the M7 and the remaining smaller 256K bank may be intended for the M4. It's still not clear to me whether these RAM banks will truly support concurrent access. Seems like they should, but that might also be just wishful thinking on my part. The available info (even the stuff under NDA) isn't all that clear...

    Every indication I'm seeing so far says the M7 core probably can not access the M4's 256K TCM, and the M4 probably can not access the M7's 512K TCM. So if you use only the M7, you get 1792K RAM, and if you use only the M4 you get 1536K.

    Looks like there might also be some other small chunks of RAM, sort of like how we get an extra chunk of RAM in Teensy 3.6 for the FlexNVM and chunks of RAM in the CAN controllers on Teensy 4.0. But even if the early info weren't under NDA, it's so obviously a copy & paste job from other NXP chips that I would would wait until we have the real hardware to check.

    But the main info is clear. M7 gets 512K TCM, same as we have now on Teensy 4.0, the M4 gets 256K TCM similar to what we have now on Teensy 3.6, and the remaining 1280K will be a big pool of somewhat slower memory shared between to 2 cores. Both have caching for that 1280K, so cache management functions will be needed on both sides.

  12. #112
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,794
    So both cores have each their own DMA and don't share it.
    The Block diagram shows they have their own FPU, too. Are they the same, or is there a technical difference I.e. can both calculate double values?
    (I guess periphals like GPIO are shared?)

  13. #113
    Probably parroting a few comments on here, but the larger form factor would be nice, larger flash along with flex spi flash would be amazing I think and really bring the T4.1 into its own for audio projects. Specifically being able to reliably store more wavetables and accessing them at high speeds for the purposes of creating a wavetable style synthesizer like Serum would be amazing. I would buy at least two immediately

  14. #114
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    10,310
    Quote Originally Posted by Frank B View Post
    So both cores have each their own DMA and don't share it.
    The Block diagram shows they have their own FPU, too. Are they the same, or is there a technical difference I.e. can both calculate double values?
    (I guess periphals like GPIO are shared?)
    Frank - assuming the public details are limited to the NXP link on p#1. There is the same single DOCUMENTATION on that link that was there with minor added details to the main page. Looking there the two cores are unique - each with an FPU so like two "Teensy's" on one board. It isn't made clear on the FPU precision of each MCU M4/M7 in re-reading. Also the pin count jumps nearly 100 pins - no details provided on linked NXP page - but the idea seemed to be that the 1170 portion would be like the 1062 with it's pins and functions and the added pins were perhaps mostly tied to the added 400 MHz M4 core? So it looks like two non-symmetric MCU's in one package each with full unique feature sets - but as Paul notes they overlap with memory access to what will be slower RAM if like on the 1062 where that non-TCM RAM runs at F_CPU/4. Didn't see an indication if they have any other direct connection bus.
    Last edited by defragster; Yesterday at 07:39 PM. Reason: copy link

Posting Permissions

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