Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 4 of 4

Thread: Teensy 4.0 and C++

  1. #1
    Junior Member JupiterMoll's Avatar
    Join Date
    Nov 2019
    Location
    Berlin
    Posts
    12

    Teensy 4.0 and C++

    Hi,
    I working right now on a wearable project using Teensy 4.0 with the Audio-Shield, W2182B and some sensor...
    The Project has some complexity using dynamic rewiring audio connection, create light animation, that are in sync with the sound and
    so on... .
    My question is what features of C++ can we use with the fastest microncontroller of wolrd : Teensy 4.0 with the Power 600Mhz and 1 Mb Ram that where not possible with slower microcontrollers without impact on code size or on speed.
    1.) Interfaces -Pure Virtual Functions
    2.) Smart Pointers
    3.) Dynammic Allocation...etc.

    I hope you got the point...

  2. #2
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,504
    These have on all computers impact on codesize and speed. Even on your PC
    If you don't care you can use them.

  3. #3
    Senior Member JarkkoL's Avatar
    Join Date
    Jul 2013
    Posts
    112
    You shouldn't use smart pointers in any environment

  4. #4
    Member
    Join Date
    Jan 2020
    Location
    Port Elizabeth
    Posts
    46
    Quote Originally Posted by JupiterMoll View Post
    Hi,

    My question is what features of C++ can we use with the fastest microncontroller of wolrd : Teensy 4.0 with the Power 600Mhz and 1 Mb Ram that where not possible with slower microcontrollers without impact on code size or on speed.

    I hope you got the point...
    Advanced coding practices always have a cost, as Frank has said. The real issue is whether this cost is significant in your environment. The answer is to instrument your code and measure the impact for yourself. Measure, measure and measure again.

    My own big project tries to do a lot in the main loop, but some things must not be delayed. And so I instrumented my program to see how long things are taking. My instrumentation was very simple but, I think, quite effective. In the main loop I put a loop counter which was incremented on every traversal. An interrupt is triggered at half second intervals(by the PPS from a GPS). This ISR reports the number of loop traversal in the half second and then it resets the loop counter to zero.

    I now tested different approaches and measured their effect by counting the loop traversals per half second. This was a real eye opener for me and I redesigned my code accordingly.

Posting Permissions

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