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

Thread: How to determine Teensy 4.0 or MicroMod Teensy in code

  1. #1
    Junior Member
    Join Date
    Sep 2022
    Posts
    8

    How to determine Teensy 4.0 or MicroMod Teensy in code

    Hi,

    I have moved an existing product from Teensy 4.0 to Micromod Teensy. The PCB has one other change that requires a small change to the code logic.

    I'm trying to find a way to determine which microprocessor option is in use, from within the .ino code, so that I don't need to support 2 firmware versions.

    Both boards respond in the same way to the chip check:

    #if defined(__IMXRT1062__)

    Any ideas on how this might be done?

    I've considered using EEPROM to store a "version" int before loading the firmware but I'm not confident in the resilience of this approach. The alternative is the 2 firmware versions

    Thanks.

  2. #2
    Senior Member BriComp's Avatar
    Join Date
    Apr 2014
    Location
    Cheltenham, UK
    Posts
    1,030
    Below is code from FlexIO.h
    Code:
    #if defined(ARDUINO_TEENSY41)
    	static const uint8_t CNT_FLEX_PINS = 22;
    	static const uint8_t CNT_FLEX_IO_OBJECT = 3;
    #elif defined(ARDUINO_TEENSY_MICROMOD)
    	static const uint8_t CNT_FLEX_PINS = 15;
    	static const uint8_t CNT_FLEX_IO_OBJECT = 3;
    #else
    	// T4
    	static const uint8_t CNT_FLEX_PINS = 14;
    	static const uint8_t CNT_FLEX_IO_OBJECT = 3;
    #endif

  3. #3
    Junior Member
    Join Date
    Sep 2022
    Posts
    8
    Thank you @BriComp that worked a treat.

    However, I didn't consider that the bootloader fails when using the same firmware because:

    "YourFirmware.ino.hex" is not compatible with this board.

    Compiled for: "Teensy MicroMod (IMXRT1062)"
    This board is: "Teensy 4.0 (IMXRT1062)"


    Maybe there's no way around this?

  4. #4
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    11,381
    Note: there are a lot of subtle differences between the two boards, like, how many pins, which pins... Which impact lots of other subsystems.
    Also as the memory sizes are different, where EEPROM data is stored will be different as well

  5. #5
    Junior Member
    Join Date
    Sep 2022
    Posts
    8
    When I designed the new PCB, I used the same pin mappings and it also uses a separate EEPROM. Apart from a single necessary tweak, to the LCD init code, the firmware logic is identical.

    I was just trying to save having to support 2 branches of code but it is not a major headache really.

    Thank you both for your input. It was worth me checking.

  6. #6
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    27,391
    Quote Originally Posted by browncauk View Post
    Maybe there's no way around this?
    It reads the .elf file in the same folder to figure out which board was intended. If you want to load a .hex file onto the "wrong" board, just delete the .elf file, or copy the .hex to another location and use File > Open to open it there.

    If you want to build hex+elf files that claim to be for different hardware, find the linker script in the core library and edit line with "_teensy_model_identifier". When you recompile, the files will be written with different info Teensy Loader checks.

  7. #7
    Junior Member
    Join Date
    Sep 2022
    Posts
    8
    That's awesome, Thanks Paul. I will try it out.

  8. #8
    Junior Member
    Join Date
    Sep 2022
    Posts
    8
    Just to close this off, I don't believe what I want to do is possible...

    Removing the .elf file does allow a build for a MicroMod to be loaded on a Teensy 4.0, and they function as expected. However, the code to version check (see below) is based on the model it was compiled for.

    The code below will return true for any model if the firmware was compiled for the MicroMod version. It's a software, not a hardware check.

    Code:
    #if defined(ARDUINO_TEENSY_MICROMOD)
    Therefore, different logic for different models still requires 2 different firmware versions to be compiled.

    What's great, though, is that I can use the logic above and have a single branch of source code that will work on both versions. I just have to compile the same code twice (easy as flicking a switch in VisualMicro) which is much easier than managing multiple branches.

    Thanks to everyone for your assistance.

  9. #9
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    11,381
    Good luck,

    I use the software way to detect as well, it is a lot easier than trying to figure out hardware wise.

    Hardware wise, the only other hack I thought of, is if you somehow make the hardware such that you could determine which.
    Like MMOD has more pins. for example, on MMOD if you tie let's say pin 40 to GND
    And in the code, you do something like pinMode(40, INPUT_PULLUP); and then do a read on it.
    On T4 I would suspect it would read high (as not brought out) (Would need to double check that it is PORT/PIN is unused on T4), and on
    MMDD would read low... But personally would rather compile for the specific boards.

  10. #10
    Senior Member BriComp's Avatar
    Join Date
    Apr 2014
    Location
    Cheltenham, UK
    Posts
    1,030
    Could also check on amount of EEPROM present, if you don't add to the T4.0 board.

Posting Permissions

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