1) я и long где нужно на 8-битниках использую. здесь int в возврате просто практически всегда длиннее u8. и "стандартный" прототип getchar такой. и экономить на спичках нужно не там, где можно шаблонами размахивать. http://cpp.com.ru/shildt_spr_po_c/13/getchar.html
2) и 8, и 16 и 32. камменты atomic предупреждают, что для 8 бит нужно предпринять меры. 3) такие есть стандартные в CMSIS. так писал пример, чтобы было понятно, что эти типы нужны с указанием длины. я не требую, чтобы Вы так писали:). ещё не нравится использовать size_t для индексов, хотя кое-где считается хорошим тоном. 4) не только закомментировал, но и вписал вызов getchar. Rx_Frame_Transport гребёт этим getchar из FIFO (сравнительно небольшого размера) и лучше, если она сможет выгрести всё из него за один вызов. При break найдёт один байт и выпадет до следующего вызова. Кстати тут и момент рассинхронизации налицо - засечка --> ts = CPU_Time(); делается не в момент прихода последнего байта, а в момент вычитывания его из FIFO, т.е. с задержкой на время до вызова Rx_Frame_Transport
2) и 8, и 16 и 32. камменты atomic предупреждают, что для 8 бит нужно предпринять меры. 3) такие есть стандартные в CMSIS. так писал пример, чтобы было понятно, что эти типы нужны с указанием длины. я не требую, чтобы Вы так писали:). ещё не нравится использовать size_t для индексов, хотя кое-где считается хорошим тоном. 4) не только закомментировал, но и вписал вызов getchar. Rx_Frame_Transport гребёт этим getchar из FIFO (сравнительно небольшого размера) и лучше, если она сможет выгрести всё из него за один вызов. При break найдёт один байт и выпадет до следующего вызова. Кстати тут и момент рассинхронизации налицо - засечка --> ts = CPU_Time(); делается не в момент прихода последнего байта, а в момент вычитывания его из FIFO, т.е. с задержкой на время до вызова Rx_Frame_Transport