Compile without (u)int64 and with 16-bit (u)int, solving rokath/trice#607 and rokath/trice#608

[THQ-WIFA]

See #607 and #608.

Note that I have not been able to do tests on other compilers:

• I have tried to fix the big-endian MCU files, but actually, I only used little-endian.
• I have not tested the effects on actual 64-bit architectures
• I have not tested each and every combination.
• On my old compiler with 16-bit int I have successfully tested (with double-buffer, custom DMA-UART transfer, tcobs, default 16bit parameter width):
  • Trice of 16-bit, 32-bit values
  • Trices without timestamps, with 16-bit timestamps, with 32-bit timestamps
  • Trice of a 32-bit float

[THQ-WIFA]

Regarding the automated checks:

• Link Check failed: I did not add or change any link. I have no idea where to find the correct link for the G0B1 example.
• Shell formatting check failed: I did not change any shell scripts. I have no idea how to fix the failure; I don't even understand the test output.

[THQ-WIFA]

Update regarding #607, and added #610.
(Sorry - I have mentioned #507 in a commit, but I meant to mention #607, of course.)

[rokath]

Hello THQ-WIFA, thank you very much for your contribution — I really appreciate the effort you put into this.

Before I can merge it, could you please revert the changes from (((uint_fast32_t)(TRICE_CYCLE) << 16) back to ((TRICE_CYCLE) << 16) in the places where this was modified?

Additionally, I would suggest the following adjustments instead:

• Change #define TRICE_CYCLE 0xC0 to #define TRICE_CYCLE ((uint_fast32_t)0xC0)
• Update uint8_t TriceCycle = 0xc0; (including its declaration) to uint_fast32_t TriceCycle = 0xc0;

I believe this approach keeps the intent clearer and maintains consistency.

No need to worry about the link check or formatting issues for now.

Thanks again for your contribution!

[THQ-WIFA]

Hello @rokath, I have implemented the change in THQ-WIFA/trice@7e3e9a2, mostly as proposed:

• Removed the explicit uint_fast32_t cast from all occurrences where TRICE_CYCLE was shifted
• Made TRICE_CYCLE / TriceCycle a native uint_fast32_t with and without TRICE_CYCLE_COUNTER == 1
• Added 1-byte masking (TriceCycle++ & 0xFF), to keep the 1-byte value range 0..255.

I have tested that with TRICE_CYCLE_COUNTER == 1, and I have received >256 trices without issues.

[rokath]

ok