Простой GPS-регистратор в формате Ozi

[TripleKill]

Пока не помер плеер, пользовался им как навигатором. Однако аккум быстро иссякал, записать полный трек не получалось.
Теперь возникла идея сделать небольшую коробочку, в которой будут располагаться GPS-приёмник, МК, флэшка и экран от какой-нибудь нокии. Для начала мне думается достаточным наличие буквально нескольких кнопок: старт записи трека, пауза записи, останов, и постановка путевой точки в текущей позиции. Но можно, конечно, и расширить. Треки и всё прочее пишутся на флэш в формате, читаемом OziExplorer. Вернувшись из похода домой, можно легко перенести на ББ точки и треки. Устройство по идее много есть не должно, экран вообще можно гасить при ненадобности.

Мне эта затея кажется интересной, но, может, какие-то подводные камни существуют? Хочется услышать мнение о такой поделке со стороны.

Спасибо.

[luxin]

То есть Вы хотите разработать схему устройства?

[Tolmi]

А зачем GPS-логгеру экран? Если на нем будет карта, то это уже не логгер, а навигатор. А написать даже простенькую навигационную программу - это будет геморрой ещё тот.
По поводу схем и идей - лучше писать сразу в NMEA и не обрабатывать. Пусть он и гораздо больше в размерах, зато не надо будет ничего вычислять - считывается всё из UART GPS приёмника в буфер до его заполнения, потом дописывается в файл на карточку. А уж потом на компе NMEA можно преобразовать во что угодно.
И так в цикле, пока не не нажата кнопка "остановить запись". При нажатии кнопки "начать запись" открывается пустой файл и туда начинается запись с UART.
В таком случае схема будет очень простой - от МК требуется только обрабатывать UART, общаться с накопителем по SPI, поддерживать запись файлов на накопитель, и уметь обрабатывать пару-тройку кнопок, т.е. в пределах обычных примеров, которых в инете тысячи. И программа будет тоже достаточно простой.
Хотя, если ещё делать ввод POI, всё равно придётся вычислять и писать координаты. Но можно начать хотя бы с этого, а потом переписать программу под запись POI.

PS из опыта - POI лучше записывать с голосовым описанием, правда при этом сильно возрастут потребности в размере карточки. Потому что любой другой ввод, а особенно экранные клавиатуры, в полевых условиях весьма неудобны.

[Satyr]

Делал, только несколько бОльшее



собсно и трекер,и одновременно трек на стандартной карте OZI рисовал.

[TripleKill]

В том-то и фишка, что не навигатор, а логгер. Экран чисто для вывода простой инфы: время, координаты, статус записи. Потому и предлагаю взять простой, от nokia 3310 или типа того.
Хотя можно и вообще светодиодами обойтись. Никаких навигационных программ не предусматривается.
Писать необработанные данные NMEA - как-то не то. Всё равно на компе придётся соображать программу по переформатированию этих данных. Почему бы контроллеру это не делать на ходу?
Может, я некорректно выразился, но говоря про путевые точки я имел в виду именно их (waypoints), а не POI. Я не задумывал какое-то описание к ним. Просто отметки на карте, возможно с простановкой времени и даты. Выше уже было сказано про потребности, и если делать какой-то ввод текста, то потребности так же возрастут, а вот удобств не прибавится. Если пытаться заталкивать прибор в корпус от телефона, то клавиатура очень уж неудобная.

В продолжение темы вопрос. У меня есть gps-мышка GlobalSat BU-353 с USB-разъёмом. На него ведь выведен обычный UART?

[Satyr]

Писать необработанные данные NMEA - как-то не то. Всё равно на компе придётся соображать программу по переформатированию этих данных. Почему бы контроллеру это не делать на ходу?

Таких просто логгеров и так туча. Чего бы не взять готовый китайский ? По затраченным средствам, времени, габаритам и весу всеравно к китайпрому не приблизишься.
А контроллеру 'делать на ходу' - только бесполезная трата энергии у мобильного устройства.

В продолжение темы вопрос. У меня есть gps-мышка GlobalSat BU-353 с USB-разъёмом. На него ведь выведен обычный UART?

Какие предпосылки, чтобы на УСБ разьем был ЮАРТ выведен ? На УСБ, очевидно, выведен УСБ.

Как раз BU-353 и использовал. УСБ там сделан на PL2303. Драйвер для него буквально за час пишется.

[Tolmi]

А контроллеру 'делать на ходу' - только бесполезная трата энергии у мобильного устройства.

А если учесть, что нужно будет ещё и работать с плавающей арифметикой в МК, то всё совсем становится унылым.И в плане затрат энергии тоже. Впрочем, берём ARM11, и ...

[Satyr]

А если учесть, что нужно будет ещё и работать с плавающей арифметикой в МК, то всё совсем становится унылым.И в плане затрат энергии тоже. Впрочем, берём ARM11, и ...

Целый 1 раз в секунда работать с плавающей арифметикой Без АРМ11 тут никак. Вот только с чего надежды, что кушает он меньше МК ?

[TripleKill]

Не догоняю, зачем там плавающая арифметика. Приёмник же выдаёт координаты, и вроде в файлах ози тоже пишутся координаты, просто с обвесом.

[Tolmi]

Целый 1 раз в секунда работать с плавающей арифметикой Без АРМ11 тут никак. Вот только с чего надежды, что кушает он меньше МК ?

ARM11 - тоже семейство микроконтроллеров. Вообще это был сарказм. Я имел в виду, что мы же не знаем, что ТС понимает под аббревиатурой "МК"

Не догоняю, зачем там плавающая арифметика. Приёмник же выдаёт координаты, и вроде в файлах ози тоже пишутся координаты

Они там в разном формате. "градусминуты.дробь минут" в NMEA и "градус.дробь градуса" в Ozi
Впрочем, как мне кажется, я несколько преувеличил сложность преобразований шестидисятиричных дробей. Но от плавающей арифметики всё равно не уйти.

PS Я просто когда-то писал конвертор NMEA в Ozi .plt

[TripleKill]

Какие предпосылки, чтобы на УСБ разьем был ЮАРТ выведен?

Просто на диске с этой мышкой в комплекте драйвер виртуального COM. Вот и подумал...

[Satyr]

Просто на диске с этой мышкой в комплекте драйвер виртуального COM. Вот и подумал...

Не обманули - ВИРТУАЛЬНЫЙ есть -)))

[Satyr]

ARM11 - тоже семейство микроконтроллеров.

Это семейство ядер.
Среди них есть только одно, что напоминает МК, но реализаций в силиконе именно этого ядра вобще не видел.

[TripleKill]

Не сочтите за некропостинг, просто идея засела, вот в продолжение темы.
Взял модуль GL8088s, настроил приём через UART на STM32VLDiscovery.
Возник вопрос об организации обработки сообщений. Блок сообщений приходит каждую секунду, однако этот блок непрерывен, и камень не успеет обработать сообщение до прихода другого, т.к. в текущем варианте под буфер выделен char[80], всего один, и он затирается. Скажите, единственный ли вариант - сделать много char[], или можно придумать что-то получше?
Спасибо.

[Satyr]

Чего ???
Это обрабатывать и мегогерцного 8битнрого хватит

[TripleKill]

Стало быть, я неэффективно использую процессорное время.
Т.е. даже 8-битный успеет перевести формат NMEA в Ozi в промежуток между двумя символами? Скорость 115200.
И ещё, подскажите, пожалуйста, кусок кода STM для прерывания по приходу данных в UART.

[Satyr]

Кусок кода - в примерах к библиотеке на сайте производителя
для трека достаточно только сообщение одного типа декодировать.

[Tolmi]

Кусок кода - в примерах к библиотеке на сайте производителя
для трека достаточно только сообщение одного типа декодировать.

Да хоть все, там нечего делать. Два буфера, рабочий и для приёма, Приняли строку до конца, определили тип, отдали процедуре, которая его будет обрабатывать. При этом swap'нули буфера. Даже при коротком сообщении в 10 символов пройдет 86 микросекунд на то, чтобы извлечь из него полезную информацию, если она нужна. ( и это наверняка будет строка с признаком недостоверных данных) В типичной строке $GPRMC будет 70-80 символов, это минимум 500 микросекунд на то, чтобы её разобрать.

[TripleKill]

Никак не могу понять, отчего проблема возникает.

Код: Выделить всё

void USART1_IRQHandler(void) {

 if (USART_GetITStatus(USART1, USART_IT_RXNE)) {
 USART_ClearITPendingBit(USART1, USART_IT_RXNE); }
 
if (USART1->DR!='\r' && USART1->DR!='\n') {s1[counter]=USART1->DR; counter++;} else {s1[counter]=0x00; if (USART1->DR=='\n') 
{
counter=0; 
	
strcpy(s2,s1);	
sscanf (s2,"$%[^,]",s3); 
		if (strcmp(s3,"GPRMC")==0) {
			if (s2[18]=='A') {STM32vldiscovery_LEDOn(LED3);} else {STM32vldiscovery_LEDOff(LED3);};
			scopy(s2,s4,7,2);
			hr=atoi(s4)+utcplus;
			scopy(s2,s4,9,2);
			mn=atoi(s4);
			scopy(s2,s4,11,2);
			sc=atoi(s4);
			sprintf(b, "%2.2d.%2.2d.%2.2d", hr, mn, sc);
			scopy(s2,s4,20,8);
			d=strtod(s4, NULL);
			
			
		};	
	
};
																																							   	};
 
	 
};

Код: Выделить всё

 void scopy(char *in, char *out, short start, short len) {
	 short m1;
	 for (m1=start;m1<start+len;m1++) {out[m1-start]=in[m1];};
	 out[m1+1]=0x00;
	 
 };

В переменной b, которая должна содержать время вида ЧЧ.ММ.СС вылезает чушь.
Если убрать из обработчика прерывания строчки scopy(s2,s4,20,8); d=strtod(s4, NULL);, то всё нормально.
Также, если поменять переменную для копирования в этих строках (scopy(s2,s5,20,8); d=strtod(s5, NULL);), то тоже нормально, но я не хочу делать лишние, их и так уже 4 (s1 - переписываемый буфер, обновляется побайтно; s2 - полностью принятая строка для обработки, меняется с каждым полным сообщением; s3 - идентификатор сообщения; s4 - временная).
По идее, строка обрабатывается только при наличии конца сообщения, и только если оно GPRMC. Данные других строк не могут попасть. Потом, переменную b я не трогаю после печати в неё знаков, но это значит, что изначально печатаемые данные неверны. Откуда ж они берутся? Или это я чего-то в scopy() намутил с указателями? Она просто копирует кусок строки в другую, и завершает нулём.
Спасибо.

[Satyr]

не надо в прерывание основную логику программы совать!
клади только в буфер, ставь флаги и тп. Обрабатывай в основном цикле.

Да и вобще, нафига прерывания по каждой букве. DMAж есть