Pingvin писал(а):
Цитата:
Баг был непростой, и связан с data race между прерыванием UART и основным циклом обработчика событий.
Можно подоходчивей?
"Data race" или "гонка данных" - это когда два или более потока пытаются работать с одними и теми же данными одновременно, и получается не очень) Даже если нет ОС, в любой момент может сработать прерывание, и прервать текущий поток. Вплоть до того, что если у вас в основном потоке написано counter++, и в прерывании counter++, то результат может быть как +2, так и +1, а в сложных случаях и +0.
У меня в редких случаях приемный буфер сбрасывался вместе с ещё не прочитанными полезными данными. Там была проблема с таймаутами. Есть дешевое решение - запрещать прерывания в критичных местах. Но лучше стараться обходиться конструкциями, в которых блокировки не требуются. Поскольку у меня код для работы с шиной выполнен в виде библиотеки, которая не должна зависеть от железа, не хотелось пользоваться такими низкоуровневыми вещами, как запрет прерываний. Так и получилось, сейчас все работает нормально.
Pingvin писал(а):
Ситуация интересней, когда два попадания от разных игроков, и первый пакет прилетел чуть раньше - на 0,01 с, к примеру.
Честно было бы отдать "предпочтение" тому выстрелу, который раньше прилетел.
Но как решить задачу "какой раньше" при таком режиме опроса (последовательном)?
Пакет выстрела MilesTag2 занимает от 0,019 до 0,028 с. Если стреляют из одной стороны, в большинстве случаев ни один датчик не примет ничего хорошего из-за наложения сигналов, это куда большая проблема. А если выстрелы разнесены больше, чем на 0,03 - все отработает как надо.