Система реального времени

← →
Igorek © (2004-08-04 12:05) [0]

Выношу на суд несколько дизайнерских решений.

Итак общее описание требований:
1) программа работает с прибором, подключенным к COM порту (не исключено что в будущем прибор будет подключаться по другому)
2) общение происходит по определенному "временному протоколу" - т.е. есть интервалы, между сообщениями, ответами
3) программа также выполняет много второстепенных (по приоритету) задач - парсинг данных, запись в файлы, ведение БД
4) в самую последнюю очередь выполняются собственно оконные задачи - перерисовка, обработка сообщений
5) изначально программа пишется под платформы Win95-XP, но дизайн должен давать возможность легкого портирования под PocketPC 2002
6) программа будет использована в системе из многих настольных и карманных ПК (для каждой платформы будет своя типовая настройка)
7) данные с карманного ПК передаются на настольный ПК
8) программа на настольном ПК должна уметь сконфигурировать программу на карманном ПК (настроить опции замеров на рабочий период) - желательно
9) поскольку временные рамки написания ограничены, то возможно сначала будет однопоточный вариант, но дизайн должен предусмотреть легкий переход на несколько потоков

Теперь что предлагается для реализации:
- если несколько потоков, то напрашивается три п.2,3,4 - потоки №3, 2, 1) - приоритет обратно зависит от номера
- буфер обмена данных между потоками 3 и 2 (третий пишет туда инфу с девайса, а второй по мере сил забирает и обрабатывыает)
- из-за п.5 можно:
1) завести класс Interfacer, который обеспечивает передачу визуальной информации для форм и обработку комманд юзера
2) завести класс OSConnector, куда вынести весь системно-зависимый код (базовый абстрактный класс и наследники для каждого семейства ОС)
3) весь системно независимый код пишется на чистом, стандартном С++ без (или при минимуме стандартных) внешних библиотек
Тогда портирование будет заключаться только в дизайне форм в соотв. IDE, цеплянию к ним Interfacer"a и соотв. OSConnector"a
- из-за п.9 предполагается организовать обмен через минимум callback функций

Теперь вопросы:
1) какие плюсы и минусы приведенных решений?
2) какие методы синхронизации выбрать для многопоточного варианта (освежив в памяти доки я пока остановился на event)?

← →
WondeRu © (2004-08-04 12:19) [1]

9) поскольку временные рамки написания ограничены,

Гы)) мы подобное пишем ужо как 6 лет!)))

← →
REA © (2004-08-04 12:20) [2]

А цель какая всего этого?
Я тоже подобные системы пишу. Лет 8 уже.

← →
Igorek © (2004-08-04 12:34) [3]

Кстати буду признателен за любые ссылки и доки по теме.

> WondeRu © (04.08.04 12:19) [1]
> 9) поскольку временные рамки написания ограничены,
> Гы)) мы подобное пишем ужо как 6 лет!)))

Ну у меня есть не более месяца-двух. По крайней мере на ключевые функции.

> REA © (04.08.04 12:20) [2]
> А цель какая всего этого?
> Я тоже подобные системы пишу. Лет 8 уже.

Цель - получение прибыли от коммерческой деятельности. :-)
Сфера - спутниковая навигация.
Может поделишься опытом, доками? Здесь или по мылу.

← →
KSergey © (2004-08-04 12:47) [4]

И будут плутать путники... И будут крыть матом...
Главное сделать так, чтобы уже точно не выбрались
А то ведь и морду набить могут. Как минимум.

← →
WondeRu © (2004-08-04 13:22) [5]

>И будут плутать путники...
я уже и название придумал: "Моисей" или "Susanin GPS Manager" ;-)

Однопоточным делать не рекомендую сразу! Отображение картинки и работа с БД - в главном потоке, + поток для мониторинга COM-порта (там же парсишь протокол и посылаешь события главному потоку), инициатор общения в таких системах - комп, + поток для работы с сеткой!

5) - спорно, если тока на Java не собираешься писать!

Вижу есдинсвенного врага - время!

← →
Igorek © (2004-08-04 13:34) [6]

> там же парсишь протокол и посылаешь события главному потоку

Т.е. синхронизация просто в пересылке Win сообщений?

> инициатор общения в таких системах - комп, + поток для работы
> с сеткой!

Не понял. Можно пояснить?

> 5) - спорно, если тока на Java не собираешься писать!

Ну Java кроссплатформенная, так что портирование вообще не проблема. Вот только я не спец в Java.

Кстати интересен вопрос, как обеспечивается кроссплатформенность в части существенных различий в системах?

← →
WondeRu © (2004-08-04 13:45) [7]

"инициатор общения в таких системах - комп" - это к потоку СОМ-порта! Комп постоянно шлет пакет устройству "А есть ли у тя событие?", ответ читает "Нету, попозже" или "Да, блин, мы в Греландии!!! Тока почему она не зеленая?" ;-)

>Кстати интересен вопрос, как обеспечивается кроссплатформенность в части существенных различий в системах?
полную кроссплатформенность получить не удасться - в основном переделки подвергаются места работы с железом компа!

← →
WondeRu © (2004-08-04 13:50) [8]

синхронизация просто в пересылке Win сообщений?

тоже вариант, но прощай кроссплатформенность и привет глюки винды с большой очередью сообщений!

Вообще-то разгребыть события нужно в отдельном потоке (аля виндовская очередь событий), который будет хранить очередь событий!

← →
Igorek © (2004-08-04 13:50) [9]

> в основном переделки подвергаются места работы с железом
> компа!

Вот-вот. С этим у меня были проблемы при портировании (я уже пробовал портировать модель). Так что если все равно надо переделывать, то прелесть Java теряется.

← →
REA © (2004-08-04 15:18) [10]

У меня знакомые этим занимались лет 5 назад. Не знаю чем дело кончилось. Мне кажется таких систем уже много наделано.

← →
REA © (2004-08-04 15:18) [11]

← →
WondeRu © (2004-08-04 15:42) [12]

2REA © (04.08.04 15:18) [10]
1C и Галактика - лидеры, а бух. проги до сих пор заказывают и пишут!

Я не против самой разработки, просто подход к серьезным вещам должен быть на мой взгляд более серьезен. Детально проработать предметную область, железо, способы связи и т.п. Потом формировать Т.З. и писать обоснование выбора аппаратных и программных средств.

REA © (04.08.04 15:45) [13]
вот с этим согласен на все 117%
Срок 2 месяца - глупость какая-то! За это время можно только разработки конкурентов изучить!

> REA © (04.08.04 15:45) [13]
> Я не против самой разработки, просто подход к серьезным
> вещам должен быть на мой взгляд более серьезен. Детально
> проработать предметную область, железо, способы связи и
> т.п. Потом формировать Т.З. и писать обоснование выбора
> аппаратных и программных средств.

Согласен. Так вот это все по большей части уже сделано - обозрели конкурентов - фигня (может есть не фигня, но дорогая и не то что нужно), провели исследования, определились с аппаратным обеспечением.

> WondeRu © (04.08.04 15:55) [14]
> Срок 2 месяца - глупость какая-то! За это время можно только
> разработки конкурентов изучить!

Поговорим через два месяца?

>Поговорим через два месяца?
Поговорим, если выполнишь 2 условия:
1. Будем обмывать прогу, так что пивом запасайся щас!
2. Пьянка будет в тайге, дорогу найдем с помощью будущего Susanin GPS Manager"a!

Согласен?

> WondeRu © (04.08.04 16:04) [16]

А че это я пиво должен покупать? Мне дай бог бы за прогу заплатили. Это ты ставишь под сомнение сроки. Вот за два месяца и готовь пиво. :-))
Кроме того прога не предназначена для походов в тайгу, хотя может и так использоваться - там будут точные координаты, время.

Система реального времени Найти похожие ветки