Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Потрепаться";
Текущий архив: 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
3-1090740667
buka
2004-07-25 11:31
2004.08.22
Как узнать содержимое поля ADOTable?


3-1090920985
ONIK
2004-07-27 13:36
2004.08.22
Help!!! Динамическое создание БД ??????


3-1091192861
NEWS
2004-07-30 17:07
2004.08.22
TADOQUERY как определить ошибку.


1-1092058858
ПЛОВ
2004-08-09 17:40
2004.08.22
Вопрос по чтению строк из текстовых файлов


14-1091341736
ИМХО
2004-08-01 10:28
2004.08.22
Программирование мелодий siemens C62





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский