Форум: "Потрепаться";
Текущий архив: 2004.08.22;
Скачать: [xml.tar.bz2];
ВнизСистема реального времени Найти похожие ветки
← →
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]У меня знакомые этим занимались лет 5 назад. Не знаю чем дело кончилось. Мне кажется таких систем уже много наделано.
← →
WondeRu © (2004-08-04 15:42) [12]2REA © (04.08.04 15:18) [10]
1C и Галактика - лидеры, а бух. проги до сих пор заказывают и пишут!
← →
REA © (2004-08-04 15:45) [13]Я не против самой разработки, просто подход к серьезным вещам должен быть на мой взгляд более серьезен. Детально проработать предметную область, железо, способы связи и т.п. Потом формировать Т.З. и писать обоснование выбора аппаратных и программных средств.
← →
WondeRu © (2004-08-04 15:55) [14]REA © (04.08.04 15:45) [13]
вот с этим согласен на все 117%
Срок 2 месяца - глупость какая-то! За это время можно только разработки конкурентов изучить!
← →
Igorek © (2004-08-04 15:58) [15]
> REA © (04.08.04 15:45) [13]
> Я не против самой разработки, просто подход к серьезным
> вещам должен быть на мой взгляд более серьезен. Детально
> проработать предметную область, железо, способы связи и
> т.п. Потом формировать Т.З. и писать обоснование выбора
> аппаратных и программных средств.
Согласен. Так вот это все по большей части уже сделано - обозрели конкурентов - фигня (может есть не фигня, но дорогая и не то что нужно), провели исследования, определились с аппаратным обеспечением.
> WondeRu © (04.08.04 15:55) [14]
> Срок 2 месяца - глупость какая-то! За это время можно только
> разработки конкурентов изучить!
Поговорим через два месяца?
← →
WondeRu © (2004-08-04 16:04) [16]>Поговорим через два месяца?
Поговорим, если выполнишь 2 условия:
1. Будем обмывать прогу, так что пивом запасайся щас!
2. Пьянка будет в тайге, дорогу найдем с помощью будущего Susanin GPS Manager"a!
Согласен?
← →
Igorek © (2004-08-04 17:40) [17]
> WondeRu © (04.08.04 16:04) [16]
А че это я пиво должен покупать? Мне дай бог бы за прогу заплатили. Это ты ставишь под сомнение сроки. Вот за два месяца и готовь пиво. :-))
Кроме того прога не предназначена для походов в тайгу, хотя может и так использоваться - там будут точные координаты, время.
Страницы: 1 вся ветка
Форум: "Потрепаться";
Текущий архив: 2004.08.22;
Скачать: [xml.tar.bz2];
Память: 0.5 MB
Время: 0.027 c