Страница 1 из 1
Репитер GPS на atmega48 - помогите люди добрые.
Добавлено: Сб май 15, 2010 04:17:27
stas00n
Вобщем, надо сделать простенький репитер для дублирования информации с GPS приемника. Проект пока только в голове, хочу реализовать на atmega48 (их у меня мешок) и графическом индикаторе 128х64. Репитить по минимуму надо 4 параметра - координаты, курс, скорость, остальное опционально (потом, если захочется); выглядеть должно как-то так:
С железом проблем нет, пока приедет индикатор, нарисую схему и спаяю. Проблема в моей необразованости в сях - писал программы только на асме для пиков и атмег - уровня "АЦП/арифметика/7-сегментная индикация/кнопки". Чувствую, придется таки изучать этот ужас (Си имеется в виду - я в нем ну полнейший ноль) ибо на асме как-то слабо мне такую задачку решить. Надо "всего-то" выделить из потока данных (NMEA-0183, естественно) то что нужно и отправить на индикатор (на KS0108). Товарищи, посоветуйте что почитать по сям вообще и по моему приложению в частности? И навскидку - скжите хватит ли производительности меги для этого дела?
Re: Репитер GPS на atmega48 - помогите люди добрые.
Добавлено: Сб май 15, 2010 15:20:36
Danko
Производительности меги хватит?
Это принять данные с последовательного порта, слегка обработать и отправить на экран.
Для этого хватит мощности настольного калькулятора, а вот шрифты кушают много памяти и боюсь 4кБ меги48 не хватит.
Я бы начал с меги32. Ну на краняк с меги16.
А когда захочется не только дублировать информацию?
Re: Репитер GPS на atmega48 - помогите люди добрые.
Добавлено: Сб май 15, 2010 21:59:19
stas00n
Danko писал(а):Производительности меги хватит?
Это принять данные с последовательного порта, слегка обработать и отправить на экран.
Для этого хватит мощности настольного калькулятора...
Принять данные действительно несложно, меня смущает "слегка" обработка - надо ведь выделить из ASCII последовательности только то что нужно, а последовательности там довольно разнообразные, боюсь сильно будет пухнуть код, потом еще надо из текста сделать графику, причем довольно быстро - для меня задача нетривиальная пока.
Danko писал(а): а вот шрифты кушают много памяти и боюсь 4кБ меги48 не хватит.
Я немного прикинул - шрифт нужен всего один; отображать надо четыре строки на экранчике 128х64 - пусть будут знакоместа, например, 8х12 пикселей, тогда на один символ надо 12 байт, так? Если не слишком экономить, то 52 латинские буквы, 10 цифирь плюс 6 символов .,:'"° - итого 68*12=816 байт - ощутимая убавка, но не смертельно, думаю. В крайнем случае при нехватке места урезать количество буковов - мне надо от силы 6-10 из 52
Danko писал(а):
А когда захочется не только дублировать информацию?
Ну тогда и поглядим в сторону более мощного железа или какой нибудь "фирменной" приблуды
Сейчас нужен именно простейший дешевейший репитер - чтобы кэп мог сквозь сон одним глазом следить как рулит вахтенный
Re: Репитер GPS на atmega48 - помогите люди добрые.
Добавлено: Сб май 15, 2010 23:14:09
Fasterpast
на 16м пике делают сигнализации, которые читают данные с ЖПС, отправляют их на серв по GPRS через GSM модем, отвечают на смс и даже фоткать могут подключенными камерами с посл.интерфейсом... А атмега в чем-то попроизводительнее 16го пика будет. Тут вопрос скорее в оптимизации когда.
Re: Репитер GPS на atmega48 - помогите люди добрые.
Добавлено: Сб май 15, 2010 23:30:17
stas00n
Fasterpast, в порядке сдержанного флуда - ваш пример - это как если: генеральный директор автозавода водиночку выплавляет руду для металла из которого он строит тысячи машин собственными руками по собственным проектам, потом сам их же и продает, а в свободное время еще и на серфинге катается. Хотя гендир-то он вобщем средненький, есть и покруче.
Это я к тому, что мне известны возможности пика и меги. На выпуклый глаз - вроде с моими задачами должна справиться, спрашиваю тем не менее бо не уверен на все сто.
Re: Репитер GPS на atmega48 - помогите люди добрые.
Добавлено: Сб май 15, 2010 23:32:57
stas00n
По теме - схемку набросал уже, направьте на толковую обучалку как реализовать задуманное в программной части. А то буду всем назло на асме писать
Re: Репитер GPS на atmega48 - помогите люди добрые.
Добавлено: Вс май 16, 2010 10:57:31
Pooher
Ну а в чем проблема с АСМом то? Задача более чем не сложная, никаких проблем не должно возникнуть, надо просто начать, а там дело пойдёт... Не надо бояться!
Re: Репитер GPS на atmega48 - помогите люди добрые.
Добавлено: Вс май 16, 2010 13:11:07
Fasterpast
Ну гендир-супермен - это нечто нетривиальное,а написанный мой пример - это коммерческий продукт, который успешно продаётся и работает
А по теме, вот, например, хороший сайтик:
http://easyelectronics.ru Тут и асм, и С.
Ну и всем известный 123avr.com оттуда тоже можно выдернуть что-то полезное.
Re: Репитер GPS на atmega48 - помогите люди добрые.
Добавлено: Вс май 16, 2010 23:22:43
maglev
Еще напомню, что в при необходимости автор сможет заменить мега48 на 88 или 168 простой перепайкой чипа и повторной заливкой прошивки.
С конкретной задачей мега48 и программа на чем угодно уверенно справятся.
Re: Репитер GPS на atmega48 - помогите люди добрые.
Добавлено: Вт май 18, 2010 22:07:59
stas00n
Спасибо, коллеги, начал писать на асме, в принципе, не очень страшно, дело помаленьку движется. Пока пытаюсь разобрать строку $GPRMC. Посоветуйте вот что: как это лучше сделать - "на лету" по мере приема, или загонять ее целиком в буфер, а потом уже разбирать? Сейчас пытаюсь сделать первым способом - код уже 7% памяти занял, а это только начало, местами уже "штатные" команды BR** не дотягиваются до меток бо алгоритм разбора довольно замудреный - пришлось макросы длинного ветвления дописать.. Вторым способом, вроде должно покомпактней получиться, но придется приличный кусок SRAM'а отчекрыжить под двойной буфер, а SRAM еще наверное пригодится при работе с жк модулем, пока еще слабо представляю как с ним работать придется. Что скажете, коллеги?
Кстати, замечал кто-нибудь, что регистры управления USART'ом не работают с командами IN, OUT, как написано в примерах в даташите, к ним надо обращаться через LDS, STS. Это очепятка в даташите или особенность данной меги?
Re: Репитер GPS на atmega48 - помогите люди добрые.
Добавлено: Ср май 19, 2010 11:14:51
Pavel V.
stas00n, кадр RMC лучше всего принимать и обрабатывать отдельно. Недавно решал похожую задачу, только парсить не надо было. Я сделал так: выделил два буфера размером 80 байт (это ограничение протокола NMEA). Попеременно эти буферы заполняю данными (отсеивая все кадры кроме RMC), символ "$" служит сбросом указателя буфера и сигналом о начале приема нового кадра (а в случае если предыдущий кадр был RMC, то еще и переключение буфера).
Два буфера сделано для того, чтобы контроллер всегда отдавал по запросу только полный кадр (ведь он мог наполовину обновиться, например). И нельзя забывать запрещать прием данных на время отправки.
У тебя все еще проще: делаешь буфер 80 байт, в прерывании пишешь в него RMC кадр, считая "$" сигналом сброса указателя и отсеиваешь все лишнее. После приема полного кадра запрещаешь прием данных и взводишь флаг готовности. Отлавливаешь флаг в основном цикле и делаешь со своим буфером что душе угодно. Потом снова разрешаешь прием.
Могу пример свой выложить, но он на С
Рекомендую начать изучение, так как контроллеров много, а с ассемблером ты получаешь нулевую переносимость кода. Контроллер всегда выбирается под задачу, сегодня это AVR, завтра ARM или MSP430.. А то и какой-нибудь Freescale
И что ты со своим ассеблером будешь делать?
Re: Репитер GPS на atmega48 - помогите люди добрые.
Добавлено: Чт май 20, 2010 12:17:19
stas00n
Pavel V., спасибо за консультацию, у меня такие же мысли были насчет двух буферов, но пока написал разбор "на лету", как бы "покадрово", т.е. по приему "," сохраняю данные из кадра и сбрасываю указатель на начало буфера; вроде работает, даже контрольная сумма сходится. Основная фишка в экономии оперативки - буфер приема всего 10 байт вместо 160, и основной цикл пустой, можно его полностью посвятить работе с дисплеем. Сейчас попробую написать второй вариант с двойным буфером, посмотрю, какой вариант больше понравится, тот и оставлю.
Что до изучения си - согласен, надо когда-то начинать изучать, выложи свой пример, поковыряю
Меня в сях пугает сейчас то, что, во-первых его изучать буду с нуля, а во вторых что работа с железом получается будет от меня скрыта, и что будет с ним происходить на самом деле достоверно неизвестно. С асмом все как на ладони в отладчике, по опыту получается так, что если работает в отладчике, работает и в железе. Перейти с одного асма на другой не трудно - у меня переход с PICa на AVR занял один день в процессе написания программы. Правда, наверное с увеличением количества железок будет возникать некоторая путаница, не знаю. С переносимостью кода - да, беда, да и арифметика на асме, особенно дробная, особенно на 8-битных железках - задачка та еще. Резюме - си изучать буду, только не знаю с какого боку к нему подступиться.
Re: Репитер GPS на atmega48 - помогите люди добрые.
Добавлено: Чт май 20, 2010 12:20:50
Fasterpast
Так никто не мешает посмотреть во что компилятор превратил твой код на С в АСМе, возможно что-то подправить, ну и вставки в АСМе - очень полезная вещь )
Я вот наоборот начал с С, а ща разбираюсь в АСМе...
Re: Репитер GPS на atmega48 - помогите люди добрые.
Добавлено: Чт май 20, 2010 14:54:03
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;
}
}
}