Semaphore.h без RTOS

Мне интересно, могу ли я использовать семафор и мьютекс с ОС Linux, запрограммированной на C++, с API semaphore.h.

Я еще не нахожусь на этапе разработки/написания кода, но цель состоит в том, чтобы иметь показания на приемнике, который отправляет асинхронные двоичные данные со скоростью 115 200 бод. Затем эти данные должны быть переданы в модем как можно быстрее.

Я думал об использовании, возможно, RTOS, но я ничего не знаю о загрузчиках и о том, как получить Linux или любую другую ОС на чипе или во встроенной среде.

Можно ли было бы написать эти функции чтения и записи в отдельном потоке, соединенном между собой сигналами и каналами, с добавлением семафоров?

Семафоры могут потребоваться, когда мне нужно отформатировать полученные данные в другом формате, проанализировать только необходимые строки или изменить их математически. Перед их отправкой.

Можно ли получить преимущества семафоров при использовании не-RTOS? Я видел, как они применялись только в сотрудничестве с RTOS.


c++ linux rtos
person iBeyondPower    schedule 08.05.2015    source источник
comment
Непонятно, как в вашей реализации нужны сигналы, конвейеры и семафоры; или даже почему он должен быть многопоточным, чтобы обеспечить достаточную буферизацию, но если вы хотите позже перенести свой код POSIX в RTOS, вам лучше всего использовать механизмы, которые существуют в обоих.   -  person Clifford    schedule 08.05.2015

Ответы (2)


arrow_upward
0
arrow_downward

семафоры POSIX не менее важны для синхронизации в многопоточном Linux. приложений, чем семафоры RTOS во встроенном приложении.

person Clifford    schedule 08.05.2015

arrow_upward
0
arrow_downward

Подумайте о том, что означает 115200 как скорость передачи данных — это 11520 символов (при условии 8N1) в секунду или около 86,8 мкс на символ. Теперь ОС Linux непостоянна в реальном времени, но у нас наверняка не будет проблем с точностью около 1 миллисекунды, если предположить, что у нас есть штатное ядро ​​​​1000 Гц, что примерно в 11,5 раз больше, если вы настроите свой планировщик. Кроме того, в каком-то смысле это наихудшая задержка, пакетная запись символов вместе будет иметь почти идеальную задержку между символами, при условии, что вы можете поддерживать исходящий буфер заполненным.

Теперь ответьте на вопрос: что допустимо для вашего приложения? В зависимости от ответа вам придется рассмотреть разные вещи — от патчей реального времени для Linux — до гибридных Xenomai/RTAI и полноценной RTOS, такой как RTEMS. С моим нынешним пониманием вашей ситуации я бы сказал, что, вероятно, достаточно использовать ядро ​​с частотой 1000 Гц.

Дескрипторы последовательных файлов linux могут быть записаны и прочитаны в разных потоках одновременно без каких-либо проблем. Вы можете разделить эти задачи на разные потоки или использовать неблокирующий ввод-вывод в обмен на незначительную задержку, если ваша обработка невелика — это может избежать переключения контекста, и это хорошо, потому что они медленные. Другими словами, вам не нужно вводить семафоры при использовании потоков или неблокирующего режима.

И, наконец, семафоры есть практически во всех ОС.

person Jason Newton    schedule 08.05.2015
comment
Опубликуйте свой первый абзац в качестве комментария - он не относится к ответу. - person Clifford; 08.05.2015
comment
Проблема с потоковой передачей данных на частоте 115200 обычно не так велика, как вы предполагаете; степень детализации системных часов не имеет значения, последовательный UART с DMA или аппаратным буфером FIFO будет представлять гораздо меньшую нагрузку на ЦП и может обслуживаться приложением со значительно более низкой скоростью. - person Clifford; 08.05.2015
comment
@Clifford полный буфер может быть недопустимой задержкой для его приложения, а буферы UART повсюду - от 8 до 64 символов; Я также видел, как у людей возникают проблемы с использованием ядра 100 Гц на последовательных устройствах, поэтому я не думаю, что это хорошая идея для него; вы считаете это актуальным: stackoverflow.com/ вопросы/13126138/ - person Jason Newton; 09.05.2015