Изменение режима работы

[_mashka]

А вам как хорошо поставить, с ТЗ, ЮМЛ диаграммами, описаниями интерфейсов...
Прошу прощения, что лезу в бутылку, но разговор тут начался, как не обидно, с ВАУ, а потом по ходу сводился (переводя на неофициальный язык) в русло "да проще так работать!".
Тем не менее, задача звучит именно так, как звучит. Предположим, некое приложение нуждается а неких данных, причем в силу специфики приложения данные поступают с разных устройств, и в силу специфики же приложения возникает неодходимость менять протокол работы приемника по ходу работы... Плюс оно должно быть "дуркоустойчивым", то есть уметь определять источник и протокол работы данных и адаптироваться к нему с минимальных вмешательством оператора. Поскольку протокол работы может сохраняться в ЕЕPROM, то после старта протокол работы может быть как бинарным, так и НМЕА...

все же я против...

[columb]

>А вам как хорошо поставить, с ТЗ, ЮМЛ диаграммами, описаниями интерфейсов...
В Вашем случае причина ожидающего Вас с Гарминами фиаско скорее всего кроется в недобросовестном выполнении работ этапа ТЗ

При добросовестном "обосновании принципиальной возможности решения поставленной задачи" не может выглядеть в виде посылки, не имеющей причинно-следсвенной связи:
>Если это реализовано на уровне hardware (SiRF), то и Гармин может переключаться (из NMEA в SiRF binary).
Откуда, пардон, следует, что Гармин и роялтек построены на одном "hardware"?
А еще ведь бывают Магелланы, Тримблы и всякая почти стандартная в узких кругах экзотика типа аштеков.

Следующий момент - надежность. Откуда известно, как пусть даже только сирфовые приемники ведут себя при переключении протокола?

Вот поэтому я и написал о плохо поставленой задаче.

Вы все еще против?
:)

[_mashka]

Я все еще против....
Я не говорила о свое уверенности в том, что все переключится, как надо.
Я, зная о возможности такого переключения для приемников ряда производителей, думала, что быстрее получу ответ на мой вопрос относительно гарминовских приемников на форуме, где много людей, которые работают с ними постоянно. Вопрос задавался одновременно с изучением документации и консультацией с производителями. Извините, в данном случае данная ветвь получения информации оказалась медленнее.
Давайте, не будем сейчас о надежности и прочем. Я же не выкладывала всерьез все подробности сюда. Могу вас только успокоить . Если бы вопросы устойчивости, раасширяемости и т.д. НЕ прорабатывались - вопрос вообще бы НЕ завис...
А насчет флеймения - так соррьки, у меня некоторая временная разница, для менято был не "глубокий ночь", а "ранняя вечер" :) :) :)


все же я против...

[kg_vista]

> ты ж вроде книжку на эту тему написал...

Не, тема совсем другая...

[kg_vista]

Я совершенно согласен с Колумбом. По крайней мере, задача звучит как-то искуственно... Конечным пользователям не нужны протоколы, протоколы - это лишь средства достижения их потребностей. Хорошо разработанные системы обычно пляшут от реальных юз-кейсов; поэтому они оказываются хорошо ориентированными на реальных пользователей и на их реальные потребности. А искуственно поставленные задачи порождают софт, годящийся разве что для искуственных пользователей .

Я понимаю, если задача ставится например так: "считывать координаты (время, точки, треки - по вкусу) с таких-то видов приемников". Допустим, при этом ставится цель не только охватить максимальное число приемников, но и вводится констрейнт не грузить пользователя излишними деталями (вам шашечки или ехать?). То есть программа должна просто выдавать нужные конечному пользователю данные, а вот как - это ее проблемы. То, какие при этом используются протоколы - пользователю знать по возможности необязательно (конечно, до тех пор, пока программа может всё сделать автоматически).

Вот тогда и может возникнуть ПОДзадача переключения в нужный протокол, если текущий не обеспечивает решения поставленной СВЕРХзадачи. А просто так переключать протоколы как самоцель пользователю ИМХО вряд ли надо.

Так что предлагаю сначала выяснить, в чем состоит "сверхзадача" - и от этого исходить: что делать с протоколами Гармин.

Если сверхзадача - именно то, что я предположил выше, то конкретно в случае с Гармином:
- SiRF все равно не поддерживается, так стоит ли его здесь обсуждать?
- некоторые модели поддерживают только NMEA, причем возможно управлять, какого типа информация присылается. Здесь требуется просто переключить в нужный режим и принимать необходимые пользователю данные. Переключаться в "другой протокол" просто некуда
- другие модели поддерживают куций и "неуправляемый" NMEA плюс проприетарный Garmin protocol. Переключаться между ними невозможно, да ИМХО и не нужно, если необходимые данные в любом случае доставляются, хотя и в разной форме.

[kg_vista]

> А вам как хорошо поставить, с ТЗ, ЮМЛ диаграммами, описаниями интерфейсов...

Как архитектор архитектору: начинать надо с requirements & use-cases, то есть с выяснения, что реально надо потребителям. Диаграммы и описания интерфейсов - полезное, но вторичное.

> Предположим, некое приложение нуждается а неких данных,

Вау!!! Вот отсюда и надо исходить!

> и в силу специфики же приложения возникает неодходимость менять протокол работы приемника по ходу работы...

Я бы сказал, в силу специфики ПРОТОКОЛОВ. Приложение-то одно и то же, а вот протоколов много, и все специфичные. И очень часто все они выдают нужные приложению данные, только в разной форме. Так что не надо переключать непереключаемое, а надо брать данные в том виде, в каком приходят.

> Плюс оно должно быть "дуркоустойчивым", то есть уметь определять источник и протокол работы данных и адаптироваться к нему с минимальных вмешательством оператора. Поскольку протокол работы может сохраняться в ЕЕPROM, то после старта протокол работы может быть как бинарным, так и НМЕА...

Именно так и работает MapSource, когда считывает координаты из GPS. Почему бы не взять с него пример? Просто потому, что "все же я против..."?

[_mashka]

> А вам как хорошо поставить, с ТЗ, ЮМЛ диаграммами, описаниями интерфейсов...

> Как архитектор архитектору: начинать надо с requirements & use-cases, то есть
> с выяснения, что реально надо потребителям. Диаграммы и описания интерфейсов -
> полезное, но вторичное.
Как маляр-маляру, давайте, не будем обсуждать теорию и практику проектирования.
Для меня use-cases, в конце концов, становятся лишь одним из разделов SAD. Наиболее ясно визуализируемыми с помощью, как вы определили, "вторичных" диаграмм.


> Предположим, некое приложение нуждается а неких данных,
> Вау!!! Вот отсюда и надо исходить!
> и в силу специфики же приложения возникает неодходимость менять протокол работы приемника по ходу работы...

> Я бы сказал, в силу специфики ПРОТОКОЛОВ. Приложение-то одно и то же, а вот > > протоколов много, и все специфичные. И очень часто все они выдают нужные
> приложению данные, только в разной форме. Так что не надо переключать
> непереключаемое, а надо брать данные в том виде, в каком приходят.
Мне кажется, вы представляете себе некоторую одну возможную сторону, не подозревая о наличии других....



> Именно так и работает MapSource, когда считывает координаты из GPS. Почему бы
> не взять с него пример? Просто потому, что "все же я против..."?

Нет, это бесконечный разговор....
Ведь у вас нет никаких сведений где, зачем и посему я работаю.... Давайте-таки, не будем давать советов, кроме как по протоколу. Хорошо?



все же я против...

[kg_vista]

ПОСТАВЛЕННАЯ ЗАДАЧА НЕ РАЗРЕШИМА - в том виде как она поставлена, конкретно для Гармина. Засим бессмысленное обсуждение бессмысленной задачи предлагается прекратить.

[Kirill Limping]

>Причем ни через NMEA, ни через Garmin, невозможно получить информацию об уровне
>сигналов со спутников.
Есть же программы для КПК, которые показывают информацию о спутниках а-ля экран Гармина. У меня КПК с подключенным eMap, помнится, показывал текущие спутники с уровнем сигнала.

_______
Kir-Lim

[luzerka]

запускаю программу, открываю порт, идут нмеа данные. далее
Посылаю так
serialPort1.WriteLine("$PSRF100,0,9600,8,1,0*0C");
затем закрываю порт. открываю программу снова и опять нмеа данные...
Что не так?