Comments 6
С DMA приемом данных не все прокатит (актуален при высокой скорости приема NMEA по UART).
Автоматы, состояния, сдвиги - тоже сравнивал ID как числа, но обходился без этого.
По парсеру RMC: я просто делал массив указателей на подстроки (замена запятых на NULL), а потом обрабатывал нужные подстроки по индексам.
А как насчет того, чтобы идентификатор сообщениях хранить не в виде строки, а в виде 24-битного числа? И даже не только хранить, а искать, сравнивать.
А какая процессору разница сравнивает он числа или буквы? А если 8-ми битный то и копить символы не надо, если пришёл первый не совпавший с ожидаемой строкой сразу бросаем парсить и ждём $.
А какая процессору разница сравнивает он числа или буквы?
Разница будет хорошо заметна на 32 или 16 битном проце при сравнии с несколькоми вариантами.
С 8-ми битным процом вариант сравнивать 24-бит числа заведомо проигрышный по сравнению с вариантом сравнили поступивший байт, не совпало - выход. В чём разница для 16 или 32 битного, накопили 3 байта (зачем если первый уже не совпадает, ну да ладно) и сравнили с 0x524D43 или с (uint32_t)(('R'<<16) | ('M'<<8) | 'C') ? Второй вариант в тексте нагляднее, вот и вся разница.
Ну одним RMC не всегда ограничено, при необходимости там может быть потребность и других ид пакетов, различающихся лишь по последней букве или предпоследней букве. Можно конечно для минимизации проверок сделать дерево последовательных проверок по байтам, но наглядность кода будет плохая (при наличии возможности сравнить сразу всю строчку).
и
enum{S_RMC = ('R'<<16) | ('M'<<8) | 'C'};
еще нагляднее.
Хорошо парсим NMEA0183