Semaphore.h без RTOS

Чудя се дали мога да използвам семафор и мютекс с Linux OS, програмиран на 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 usec на знак. Сега операционната система Linux е нещо непостоянно за реално време, но ние със сигурност няма да имаме проблеми с детайлност от около 1 милисекунда, ако приемем, че имаме стандартно ядро ​​с 1000 Hz, което е около 11,5 пъти повече - при условие, че сте задали своя планировчик. Освен това - в известен смисъл това е латентността в най-лошия случай - пакетните записи на знаци заедно ще имат почти перфектни латентности от знак към символ, ако приемем, че можете да поддържате изходящия буфер запълнен.

Сега отговорете на този въпрос: какво е допустимо за вашето приложение? В зависимост от отговора ще трябва да обмислите различни неща - от пачовете в реално време за linux - до хибридния Xenomai/RTAI до пълен RTOS като RTEMS. Със сегашното ми разбиране за вашата ситуация, бих казал, че вероятно е достатъчно да използвате 1000 Hz ядро.

Серийните файлови дескриптори на linux могат да бъдат записвани и четени от различни нишки едновременно без проблеми. Можете да разделите тези задачи на различни нишки или да използвате неблокиращ IO в замяна на незначително забавяне, стига обработката ви да е лека - това може да избегне контекстни превключвания и това е добре, защото те са бавни. С други думи, не е необходимо да въвеждате семафори, ако използвате нишки или неблокиращ режим.

И накрая - семафорите са в почти всички операционни системи

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 знака; Виждал съм също хора да имат проблеми с използването на 100hz ядро ​​на серийни устройства, така че не мисля, че това е добра идея за него; смятате, че това е подходящо: stackoverflow.com/ въпроси/13126138/ - person Jason Newton; 09.05.2015