Всем очередной раз привет, сижу плотно изучаю линукс, прочел уже половину замечательной книги Роберта Лава, многое встало на свои места в моей голове. Но сейчас мучает один стратегический вопрос, как лучше структурировать программу? Задача следующая, необходимо осуществлять обмен данными с АЦП или DSP (SPI или UART), производить логические и математические действия с данными, выводить на экран итоги, также еще будет крутиться обработчик внешних событий и мониторинг состояния, плюс в дальнейшем еще что-нибудь добавится. Так вот, с одной стороны все это можно реализовать в виде отдельных процессов, с разделением приоритетов, но возникает вопрос грамотной организации передачи данных между процессами, с другой стороны есть QT и С++, со своим мощным инструментарием (мной пока плохо изучен). И второй вопрос, что лучше использовать системные вызовы linux или функции предоставляемые QT и С++, например ввод-вывод, таймера и др. Как вы организуете свои программы, которые выполняют много различных действий, хочется услышать как положительный опыт так и отрицательный.

:) или тут все только ногами дрыгают и на этом все заканчивается?

нет, тут все dsp на уартах гоняют

:) поржал, хороший прикол, dsp я stm32 обозвал, она будет удаленная, время опроса небольшое, не критично...

Начни изучать потоки, для разделения труда. Конечно трудно по началу будет особенно синхронизация, но оно того стоит.
Для грамотной организации передачи данных между процессами, а лучше потоками(расходов меньше) нужно использовать методы синхронизации. Предмет достаточно сложный. А это требует от программиста определенной степени внимательности.
Для упрощения и чтобы потом не путаться при отладке записывай в файл все что делает программа.
К примеру я написал подпрограмму которая выводит все нужные сообщения в консоль и в файл по выбору. 8 уровней сообщений )) При каждом повышении уровня, сообщения все подробней и подробнее....
Используй assert() функцию. очень полезная.
Для подчти полного понимания как все устроено, лучше использовать язык Си. А С++ потом ))) Удачи

мне кажется, что зачастую от поток можно отказаться и не потерять качества программы. надо стараться разделять системный и прикладной уровни.
в вашем случае уже есть есть драйвера нужных вам устройств (tty и spidev), т.е. вы будете писать прикладную программу, читающую и пишущую в файлы устройств, и в этой прикладной программе вам в 99% случаев придется реагировать на события, и вы будете выбирать как это делать - либо, создавая консольную программу, вы будете использовать poll()/select() напрямую, либо в более высокоуровневой среде (qt + Creator) вы будете пользоваться обертками над вышеназванными функциями.
В результате вы создаете набор слабозависящих друг от друга фунций (классов) и радуетесь жизни.
Я бы скромно посоветовал сразу изучать Qt.
Хотя я после 4 месяцев плотного знакомства слегка разочарован - это все из-за Delphi-подобных RAD, в Qt у меня на интерфейс ушло ГОРАЗДО больше времени, но все же библиотека очень мощная, особенно концепция сигналов/слотов.
Удачи.

Спасибо, что поддержали тему!
Xaba, я сейчас пошел именно по этому пути, создаю демона, он создает несколько процессов, они синхрятся и взаимойдействуют по средствам именованных каналов FIFO, данные о работе пишу в лог-файл.
Но когда я начал создавать GUI интерфейс, то меня сильно подкупили высокоуровневые плюшки, о которых пишет titan83, после чего и возник вопрос, как будет правильней…

bobsan, как говорят в миксфайте: "Старомодный бокс здесь не прокатит - сейчас принято комбинировать".
Никто не мешает свободно совмещать. У меня например свой драйвер устройства выдает информацию в файл устройства, а приложение Qt мониторит изменения этого файла и по событиям реагирует.

Я, конечно, еще малоопытный пользователь ядра, но я пока увидел лишь одно место, где без блокировок ну никак не обойтись - в драйвере, если он управляет более чем одним экземпляром устройства, тогда без разделения времени доступа к общим структурам не сделать стабильный драйвер. А в остальных местах (в qt, например) процессы не так актуальны.
Вообще, прикладное программирование в qt, конечно, намного удобнее, чем в библиотечном си - почти все, что надо типового уже есть.