Ник:
Пароль:

Контакты

E-mail: info@starterkit.ru
тел.: +7 922 680-21-73
тел.: +7 922 680-21-74
Телеграм: t.me/starterkit_ru

Способы оплаты

User Info


Добро пожаловать,
Guest

Регистрация или входРегистрация или вход
Потеряли пароль?Потеряли пароль?

Ник:
Пароль:

ПользователейПользователей:3
Поисковых ботовПоисковых ботов:3
ГостейГостей:1

ОбновитьПодробнееВсегоВсего:7
Форум » starterkit.ru » Embedded Linux
Структурирование программы
bobsan
Добавлено 02.12.2013 15:34
0
Сообщение: 1
bobsan
0

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

Пункты: 1196
Регистрация: 14.11.2012
:) или тут все только ногами дрыгают и на этом все заканчивается?
Спуститься к концу Подняться к началу
Персональная информация
sasamy
Добавлено 03.12.2013 17:07 Сообщение: 3
sasamy
4.71

Пункты: 83777
Регистрация: 14.08.2009
нет, тут все dsp на уартах гоняют
Спуститься к концу Подняться к началу
Персональная информация
bobsan
Добавлено 03.12.2013 17:57 Сообщение: 4
bobsan
0

Пункты: 1196
Регистрация: 14.11.2012
:) поржал, хороший прикол, dsp я stm32 обозвал, она будет удаленная, время опроса небольшое, не критично...
Спуститься к концу Подняться к началу
Персональная информация
xaba
Добавлено 10.12.2013 10:50 Редактировалось 10.12.2013 10:51 Сообщение: 5
xaba
4

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

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

Пункты: 1196
Регистрация: 14.11.2012
Спасибо, что поддержали тему!
Xaba, я сейчас пошел именно по этому пути, создаю демона, он создает несколько процессов, они синхрятся и взаимойдействуют по средствам именованных каналов FIFO, данные о работе пишу в лог-файл.
Но когда я начал создавать GUI интерфейс, то меня сильно подкупили высокоуровневые плюшки, о которых пишет titan83, после чего и возник вопрос, как будет правильней…
Спуститься к концу Подняться к началу
Персональная информация
titan83
Добавлено 11.12.2013 07:47 Сообщение: 8
titan83
3

Пункты: 3141
Регистрация: 16.12.2012
bobsan, как говорят в миксфайте: "Старомодный бокс здесь не прокатит - сейчас принято комбинировать".
Никто не мешает свободно совмещать. У меня например свой драйвер устройства выдает информацию в файл устройства, а приложение Qt мониторит изменения этого файла и по событиям реагирует.
Спуститься к концу Подняться к началу
Персональная информация
titan83
Добавлено 11.12.2013 08:00 Сообщение: 9
titan83
3

Пункты: 3141
Регистрация: 16.12.2012
Я, конечно, еще малоопытный пользователь ядра, но я пока увидел лишь одно место, где без блокировок ну никак не обойтись - в драйвере, если он управляет более чем одним экземпляром устройства, тогда без разделения времени доступа к общим структурам не сделать стабильный драйвер. А в остальных местах (в qt, например) процессы не так актуальны.
Вообще, прикладное программирование в qt, конечно, намного удобнее, чем в библиотечном си - почти все, что надо типового уже есть.
Спуститься к концу Подняться к началу
Персональная информация
Форум » starterkit.ru » Embedded Linux