Комментарии 5
А я бы все же реализовывал эту штуку через поллинг. Причем многократный. Заводим прерывание периодом эдак в 1 мс, ловим надежный фронт (была лог.1, а последние 2-3 тика лог.0), считаем оставшиеся 18 тиков вслепую, затем 13 тиков считываем значение на входе, после возвращаемся к первому состоянию. Смотрим что насчитали за 13 тиков. Если 6 или меньше — был 0. Если 7 или больше — была 1. На конечных автоматах такая штука делается элементарно и читается достаточно легко. Впихнуть 3 таких автомата в обработчик — тоже несложно и толстым он не станет, зато помехоустойчивость будет сильно лучше варианта с ловлей значения в одной точке через capture/compare.
1. спасибо за коммент, благодаря ему заметил ошибку: длинна битов была указана в мс, хотя реально — мкс. Исправил.
2. В связи с этим: поллинг на таких временах уест все процессорное время, если его вообще хватит. Сейчас раскочегаренный на 72 МГц STM при приеме пакетов окло 20..30% времени находится в прерывании. Да, прерывание сложноватое, но поллинг каждую мкс со входом-выходом, плюс расчеты, плюс параллельный анализ, т.к. надо ж и ACK-и (аж от три за заголовок, плюс на каждый байт данных) выдать, когда нужно… в общем, думаю, не хватит времени.
3. Насчет надежности — не думаю, что это лучше. Шум на шине (имхо) лучше воспринимать, как ошибку, а не пытаться вытряхнуть из него «что-то»: контроль целостности весьма примитивный, и словить что-нибудь ненужное слишком легко. Используя capture я получу битый пакет, не отдам ACK или дождусь следующего широковещательного, но это лучше, чем принять откровенную чушь. Т.е. при capture я увижу, что в процессе приема на шине были импульсные помехи. И это важно.
ЗЫ: в физическом мире, кстати, я уже принимаю пакеты в андроид-приложение с шины. Там прилично повторяющихся пакетов, которые выглядят подозрительно «реверсабельными». Сейчас надо дописать на досуге еще одну Activity, чтобы те пакеты, которые уже можно классифицировать, отображать там, и не засорять лог. И покататься-понаблюдать. Если есть желание, опыт и время — могу сбросить лог. Потому как в реверсе я не сильно опытен (пока) :)
2. В связи с этим: поллинг на таких временах уест все процессорное время, если его вообще хватит. Сейчас раскочегаренный на 72 МГц STM при приеме пакетов окло 20..30% времени находится в прерывании. Да, прерывание сложноватое, но поллинг каждую мкс со входом-выходом, плюс расчеты, плюс параллельный анализ, т.к. надо ж и ACK-и (аж от три за заголовок, плюс на каждый байт данных) выдать, когда нужно… в общем, думаю, не хватит времени.
3. Насчет надежности — не думаю, что это лучше. Шум на шине (имхо) лучше воспринимать, как ошибку, а не пытаться вытряхнуть из него «что-то»: контроль целостности весьма примитивный, и словить что-нибудь ненужное слишком легко. Используя capture я получу битый пакет, не отдам ACK или дождусь следующего широковещательного, но это лучше, чем принять откровенную чушь. Т.е. при capture я увижу, что в процессе приема на шине были импульсные помехи. И это важно.
ЗЫ: в физическом мире, кстати, я уже принимаю пакеты в андроид-приложение с шины. Там прилично повторяющихся пакетов, которые выглядят подозрительно «реверсабельными». Сейчас надо дописать на досуге еще одну Activity, чтобы те пакеты, которые уже можно классифицировать, отображать там, и не засорять лог. И покататься-понаблюдать. Если есть желание, опыт и время — могу сбросить лог. Потому как в реверсе я не сильно опытен (пока) :)
По традиции, раз в два года, продолжение будет? ))
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Медиасистема для Toyota Prius (часть 2)