Репитер GPS на atmega48 - помогите люди добрые.

stas00n

Вобщем, надо сделать простенький репитер для дублирования информации с GPS приемника. Проект пока только в голове, хочу реализовать на atmega48 (их у меня мешок) и графическом индикаторе 128х64. Репитить по минимуму надо 4 параметра - координаты, курс, скорость, остальное опционально (потом, если захочется); выглядеть должно как-то так:

С железом проблем нет, пока приедет индикатор, нарисую схему и спаяю. Проблема в моей необразованости в сях - писал программы только на асме для пиков и атмег - уровня "АЦП/арифметика/7-сегментная индикация/кнопки". Чувствую, придется таки изучать этот ужас (Си имеется в виду - я в нем ну полнейший ноль) ибо на асме как-то слабо мне такую задачку решить. Надо "всего-то" выделить из потока данных (NMEA-0183, естественно) то что нужно и отправить на индикатор (на KS0108). Товарищи, посоветуйте что почитать по сям вообще и по моему приложению в частности? И навскидку - скжите хватит ли производительности меги для этого дела?

Реклама

Danko

Производительности меги хватит?

Это принять данные с последовательного порта, слегка обработать и отправить на экран.

Для этого хватит мощности настольного калькулятора, а вот шрифты кушают много памяти и боюсь 4кБ меги48 не хватит.

Я бы начал с меги32. Ну на краняк с меги16.

А когда захочется не только дублировать информацию?

Реклама

stas00n

Danko писал(а):Производительности меги хватит?

Это принять данные с последовательного порта, слегка обработать и отправить на экран.

Для этого хватит мощности настольного калькулятора...

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

Danko писал(а): а вот шрифты кушают много памяти и боюсь 4кБ меги48 не хватит.

Я немного прикинул - шрифт нужен всего один; отображать надо четыре строки на экранчике 128х64 - пусть будут знакоместа, например, 8х12 пикселей, тогда на один символ надо 12 байт, так? Если не слишком экономить, то 52 латинские буквы, 10 цифирь плюс 6 символов .,:'"° - итого 68*12=816 байт - ощутимая убавка, но не смертельно, думаю. В крайнем случае при нехватке места урезать количество буковов - мне надо от силы 6-10 из 52

Danko писал(а):
А когда захочется не только дублировать информацию?

Ну тогда и поглядим в сторону более мощного железа или какой нибудь "фирменной" приблуды

Сейчас нужен именно простейший дешевейший репитер - чтобы кэп мог сквозь сон одним глазом следить как рулит вахтенный

Fasterpast

на 16м пике делают сигнализации, которые читают данные с ЖПС, отправляют их на серв по GPRS через GSM модем, отвечают на смс и даже фоткать могут подключенными камерами с посл.интерфейсом... А атмега в чем-то попроизводительнее 16го пика будет. Тут вопрос скорее в оптимизации когда.

Реклама

stas00n

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

Это я к тому, что мне известны возможности пика и меги. На выпуклый глаз - вроде с моими задачами должна справиться, спрашиваю тем не менее бо не уверен на все сто.

Реклама

stas00n

По теме - схемку набросал уже, направьте на толковую обучалку как реализовать задуманное в программной части. А то буду всем назло на асме писать

Реклама

Pooher

Ну а в чем проблема с АСМом то? Задача более чем не сложная, никаких проблем не должно возникнуть, надо просто начать, а там дело пойдёт... Не надо бояться!

Fasterpast

Ну гендир-супермен - это нечто нетривиальное,а написанный мой пример - это коммерческий продукт, который успешно продаётся и работает

А по теме, вот, например, хороший сайтик: http://easyelectronics.ru Тут и асм, и С.
Ну и всем известный 123avr.com оттуда тоже можно выдернуть что-то полезное.

maglev

Еще напомню, что в при необходимости автор сможет заменить мега48 на 88 или 168 простой перепайкой чипа и повторной заливкой прошивки.
С конкретной задачей мега48 и программа на чем угодно уверенно справятся.

stas00n

Спасибо, коллеги, начал писать на асме, в принципе, не очень страшно, дело помаленьку движется. Пока пытаюсь разобрать строку $GPRMC. Посоветуйте вот что: как это лучше сделать - "на лету" по мере приема, или загонять ее целиком в буфер, а потом уже разбирать? Сейчас пытаюсь сделать первым способом - код уже 7% памяти занял, а это только начало, местами уже "штатные" команды BR** не дотягиваются до меток бо алгоритм разбора довольно замудреный - пришлось макросы длинного ветвления дописать.. Вторым способом, вроде должно покомпактней получиться, но придется приличный кусок SRAM'а отчекрыжить под двойной буфер, а SRAM еще наверное пригодится при работе с жк модулем, пока еще слабо представляю как с ним работать придется. Что скажете, коллеги?
Кстати, замечал кто-нибудь, что регистры управления USART'ом не работают с командами IN, OUT, как написано в примерах в даташите, к ним надо обращаться через LDS, STS. Это очепятка в даташите или особенность данной меги?

Pavel V.

stas00n, кадр RMC лучше всего принимать и обрабатывать отдельно. Недавно решал похожую задачу, только парсить не надо было. Я сделал так: выделил два буфера размером 80 байт (это ограничение протокола NMEA). Попеременно эти буферы заполняю данными (отсеивая все кадры кроме RMC), символ "$" служит сбросом указателя буфера и сигналом о начале приема нового кадра (а в случае если предыдущий кадр был RMC, то еще и переключение буфера).

Два буфера сделано для того, чтобы контроллер всегда отдавал по запросу только полный кадр (ведь он мог наполовину обновиться, например). И нельзя забывать запрещать прием данных на время отправки.

У тебя все еще проще: делаешь буфер 80 байт, в прерывании пишешь в него RMC кадр, считая "$" сигналом сброса указателя и отсеиваешь все лишнее. После приема полного кадра запрещаешь прием данных и взводишь флаг готовности. Отлавливаешь флаг в основном цикле и делаешь со своим буфером что душе угодно. Потом снова разрешаешь прием.

Могу пример свой выложить, но он на С

Рекомендую начать изучение, так как контроллеров много, а с ассемблером ты получаешь нулевую переносимость кода. Контроллер всегда выбирается под задачу, сегодня это AVR, завтра ARM или MSP430.. А то и какой-нибудь Freescale

И что ты со своим ассеблером будешь делать?

stas00n

Pavel V., спасибо за консультацию, у меня такие же мысли были насчет двух буферов, но пока написал разбор "на лету", как бы "покадрово", т.е. по приему "," сохраняю данные из кадра и сбрасываю указатель на начало буфера; вроде работает, даже контрольная сумма сходится. Основная фишка в экономии оперативки - буфер приема всего 10 байт вместо 160, и основной цикл пустой, можно его полностью посвятить работе с дисплеем. Сейчас попробую написать второй вариант с двойным буфером, посмотрю, какой вариант больше понравится, тот и оставлю.
Что до изучения си - согласен, надо когда-то начинать изучать, выложи свой пример, поковыряю

Меня в сях пугает сейчас то, что, во-первых его изучать буду с нуля, а во вторых что работа с железом получается будет от меня скрыта, и что будет с ним происходить на самом деле достоверно неизвестно. С асмом все как на ладони в отладчике, по опыту получается так, что если работает в отладчике, работает и в железе. Перейти с одного асма на другой не трудно - у меня переход с PICa на AVR занял один день в процессе написания программы. Правда, наверное с увеличением количества железок будет возникать некоторая путаница, не знаю. С переносимостью кода - да, беда, да и арифметика на асме, особенно дробная, особенно на 8-битных железках - задачка та еще. Резюме - си изучать буду, только не знаю с какого боку к нему подступиться.

Fasterpast

Так никто не мешает посмотреть во что компилятор превратил твой код на С в АСМе, возможно что-то подправить, ну и вставки в АСМе - очень полезная вещь )
Я вот наоборот начал с С, а ща разбираюсь в АСМе...

Pavel V.

Fasterpast прав, всегда можно посмотреть листинг для понимания того, что натворил компилятор, в критичных местах можно использовать ассемблерные вставки. Основной аргумент приверженцев чистого АСМа - то, что код получается более оптимальный и компактный. Оптимизировать программу можно до бесконечности, но это тупиковое направление. На данный момент выигрывает не тот, кто смог уместить свою программу в минимальные ресурсы, а тот, кто быстрее вывел ее на рынок опередив конкурентов. У буржуев это называется Time To Market.

Вот мой код обработки данных NMEA.

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

#define NMEA_LEN	80

uint8_t NMEA_Buffer[2][NMEA_LEN];
uint8_t NMEA_ActiveBuffer = 0;
volatile uint8_t NMEA_Head = 0;
volatile uint8_t NMEA_FrameRead = 0;
volatile uint8_t NMEA_Block = 0;

#pragma vector=USCIAB1RX_VECTOR
__interrupt void USCI1RX_ISR(void) {
	uint8_t data_byte = UCA1RXBUF;

	if(NMEA_Block)
		return;

	/* Start of Frame */
	if(data_byte == '$') {
		NMEA_Head = 0;
		if(NMEA_FrameRead)
			if(NMEA_ActiveBuffer == 0)
				NMEA_ActiveBuffer = 1;
			else
				NMEA_ActiveBuffer = 0;

		if(NMEA_Head < NMEA_LEN) {
			NMEA_Buffer[NMEA_ActiveBuffer][NMEA_Head] = data_byte;
			NMEA_Head++;
			NMEA_FrameRead = 1;
			return;
		}
	}
	
	/* Start Read Frame */
	if(NMEA_FrameRead) {
		switch(NMEA_Head) {
			case 3: {
				if(data_byte != 'R') {
					NMEA_FrameRead = 0;
					return;
				}
				break;
			}
			case 4: {
				if(data_byte != 'M') {
					NMEA_FrameRead = 0;
					return;
				}
				break;
			}
			case 5: {
				if(data_byte != 'C') {
					NMEA_FrameRead = 0;
					return;
				}
				break;
			}
		}
	}
	if(NMEA_FrameRead) {
		if(NMEA_Head < NMEA_LEN) {
			NMEA_Buffer[NMEA_ActiveBuffer][NMEA_Head] = data_byte;
			NMEA_Head++;
			return;
		}
	}
}