Forum Rule: Always post complete source code & details to reproduce any issue!
Page 10 of 10 FirstFirst ... 8 9 10
Results 226 to 236 of 236

Thread: Future Teensy features & pinout

  1. #226
    Junior Member
    Join Date
    Aug 2020
    Posts
    3
    I'm wondering if there is a io xbar per core and pins assigned to each core or if there is a system-wide xbar which means pins can be assigned to either core. I'd love to know the details, but given the NDA, knowing that Paul has these details would already be nice.

  2. #227
    Senior Member
    Join Date
    Jul 2020
    Posts
    173
    I can see where you're going with that.

    One application that seems immediately obvious to me is CNC/3D printer controllers. One core speaks G-code, handles low-level I/O, generates steps, reads encoders (if any are used), etc., while the other runs a fancy GUI. That is basically the same thing as using OctoPrint on a RPi to control a simpler 3D printer controller, and I did that for years. Point being, there will be use cases where the two cores are running code that's so different, and which necessarily has such loose coupling, that it wouldn't matter whether they communicated through shared memory or some kind of IPC mechanism.

    If they understand the same opcodes, but have different FPUs, then putting code that can run on either core in the same binary could require the use of macros that say "this code can use 64-bit floats" or "this code can't use 64-bit floats." In this case, I think the architecture dictates the use cases to a fair extent, and it would be simpler to require distinct programs that talk over an IPC mechanism.

    This new device has a PXP (pixel pipeline, a simple GPU that does scaling, rotation, and blending) that looks the same as the one in the current T4.x chips. A library that talks to that hardware would be useful.

  3. #228
    I find useful that one core is for handling the Ethernet (you have at least 3 of them) and the other core for the application.

  4. #229
    Senior Member
    Join Date
    May 2015
    Location
    USA
    Posts
    631
    As MCUs do more and more, their timing predictability (and probably code reliability) has been declining. Interrupts, DMA, cache misses, heap use, preemptive threads, etc. So I like the idea of a second processor to return to simple "doing nothing else" loops.

  5. #230
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    12,340
    Quote Originally Posted by jonr View Post
    As MCUs do more and more, their timing predictability (and probably code reliability) has been declining. Interrupts, DMA, cache misses, heap use, preemptive threads, etc. So I like the idea of a second processor to return to simple "doing nothing else" loops.
    Indeed - seems one big benefit is having a data collector/displayer busily doing those tasks fitfully as needed, and allowing the other processor keep heads down processing ready data and generating output/results.

    The UNAV on a T_3.6 managed - but doing the data processing could take some time where it was 'offline' for some ms interrupting gathering new GPS or 9DOF data. When it came to sending out the data for viewing a second Teensy pulling the output over @tonton81's created SPI Transfer to send to the PC for display and not slow processing.

    Makes one wonder about USB output if both cores participate - maybe a good use for DUAL USB.

    With both of these cores exceeding or quadrupling the T_3.6 processing speed the UNAV work would go much better in that case. Other use cases will present themselves - but for that and similar workflow it looks like a big win.

  6. #231
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    22,649
    Quote Originally Posted by jonr View Post
    So I like the idea of a second processor to return to simple "doing nothing else" loops.
    But if it's sharing anything with the other core, waiting on semphores or mutexes or other thread synchronization would need to be one of those "nothing else" variable timing things needing to be done.

  7. #232
    Senior Member
    Join Date
    May 2015
    Location
    USA
    Posts
    631
    For me, a common use would be one core doing input and calculations and a second core handling high speed asynchronous output. They share a single, atomic ram variable but there is no synchronization. What does that leave for variable timing - a wait state/cache miss for access to the variable?

  8. #233
    Junior Member
    Join Date
    Aug 2020
    Posts
    9
    I would like to have better debugging capabilities, e.g. JTAG or SWD

    Michael

  9. #234
    We have the T4's smart peripherals to handle extremely low-level details. In my robotics-centric world I see the M4 as a highly programmable mid-level controller, well positioned to offload processing details from the M7. There's so many other uses for these asymmetric processor pairs!

    In terms of Paul's hardware, I'm currently hoping for T4.0 pin compatibility. Or maybe a .2" widening with two rows down each side; the inner rows being usable for stand-alone T4.0 compatibility and the outer rows available for expanded use. I'd love to drop one of these into my existing T4.0 board; I can handle the extra width on the board. Layout for Paul is going to be tough!

    I'm ready to put in an order now!

  10. #235
    Senior Member
    Join Date
    Jul 2020
    Posts
    173
    This post points out that some people are going to other platforms because the T4.x doesn't expose some pins that are useful to driving an LCD, also rendering the MCU's built-in graphics capabilities moot. I think others have said it earlier in the thread, but some solder pads on the bottom surface could solve this.

    I like the extra row idea, but some of us are using fixtures to hold the boards in place, and if the form factor is changed we need new fixtures. If the device is compact, the enclosure itself might have to be redone.

    I think a poll would be a good way to find out some numbers on whether people want solder pads or more rows.

  11. #236
    Senior Member
    Join Date
    May 2018
    Posts
    176
    I really appreciated the idea to solder extra ram and flash devices at the bottom of the T4.1. May be same can be done to extend pins via an smd connector?

Posting Permissions

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