How to determine Teensy 4.0 or MicroMod Teensy in code

[browncauk]

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.

[BriComp]

Below is code from FlexIO.h

#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

[browncauk]

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?

[KurtE]

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

[browncauk]

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.

[PaulStoffregen]

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.

[browncauk]

That's awesome, Thanks Paul. I will try it out.

[browncauk]

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.

#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.

[KurtE]

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.

[BriComp]

Could also check on amount of EEPROM present, if you don't add to the T4.0 board.