Search in topic

OSD на ATmega1281

В целом идея понятна, примерно так себе и представлял.

Ведь потребуется постоянная фазовая коррекция, а с ней будут пропуски бит…

а это еще зачем ? Фазу чего и относительно чего нужно постоянно корректировать? Пока проблему вижу только в том, как понять среди шума , что пошли данные, не потратив на синхронизацию большую часть строки, так как длина пакета с синхронизацией ограничена по времени ССИ.

К тому же надо еще и сервами успевать шевлить и светодиодами моргать и на хост данные сливать…

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

Фазу чего и относительно чего нужно постоянно корректировать?

Момент чтения бита видеоданных из порта должен по возможности приходиться на середину бита. Именно для этого укладываю спать МК в ожидании прихода первого фронта данных. При этом время неопределенности момента чтения составит 1такт проца, что всего в 4 раза меньше длины бита данных. Естественно из-за несинхронности кварцев, фаза момента чтения будет сдвигаться. На длину строки хватает, оценивал в цифрах…
Не настаиваю, возможно как-то сделать по другому, но пока не представляю практическую структуру такой программы…
Собственно дальше все просто, приходит первый бит, генерируется прерывание, и в нем синхронно читаются данные в буфер:

//-----------------------------------------------------
#pragma savereg-
interrupt [ANA_COMP] void ana_comp_isr(void)
{
#asm
    ST   -Y,R16   ;2t
    ST   -Y,R17   ;2t
    ST   -Y,R18   ;2t
    ST   -Y,R26   ;2t
    ST   -Y,R27   ;2t
    IN   R16,SREG
    ST   -Y,R16
;
    MOV  R26,gVideoBuffPointL      ;1t
    MOV  R27,gVideoBuffPointH      ;1t
    LDI  R16,(BYTES_FROM_STRING-1) ;1t
;
    LDI  R17,5
_wait_n:       ; skeep 5-bits
    DEC  R17
    NOP
    BRNE _wait_n
    NOP
;    SBI  0x12,3 ;PORTD.3=1
_in_ch:
    SBIC 0x8,5 ;ACSR & 0x20
    SBR  R17,0x10
    NOP
    NOP

	SBIC 0x8,5 ;ACSR & 0x20
    SBR  R17,0x20
    NOP
    NOP

	SBIC 0x8,5 ;ACSR & 0x20
    SBR  R17,0x40
    NOP
    NOP

	SBIC 0x8,5 ;ACSR & 0x20
    SBR  R17,0x80
    MOV  R18,R17
    CLR  R17

	SBIC 0x8,5 ;ACSR & 0x20
    SBR  R17,0x1
    ST   X+,R18  ; 2t

	SBIC 0x8,5 ;ACSR & 0x20
    SBR  R17,0x2
    NOP
    NOP

	SBIC 0x8,5 ;ACSR & 0x20
    SBR  R17,0x4
    SUBI R16,1 ;1t
    NOP

	SBIC 0x8,5 ;ACSR & 0x20
    SBR  R17,0x8
    BRSH _in_ch ;2t
;
	LDI  R16,LOW(0) ;ACSR=0x0; //AC_int=disable
	OUT  0x8,R16
	LDI  R16,LOW(1); MCUCR=0x01; //int0=enable, sleep=disable
	OUT  0x35,R16
;    CBI  0x12,3    ;PORTD.3=0
;
    LD   R16,Y+
    OUT  SREG,R16
    LD   R27,Y+
    LD   R26,Y+
    LD   R18,Y+
	LD   R17,Y+
    LD   R16,Y+
#endasm
}
#pragma savereg+
//-----------------------------------------------------

Ну а для особо пытливых - весь проект: GS.rar 😃

Возможно не совсем по теме, но все же интересно, с какой целью в прерывании используется такой извращенный метод сохранения регистров, вместо PUSH и POP обычно применяемых в таких случаях?
Исходник глянул , но будучи написанный на С, (что для меня равносильно китайской грамоте) данный трюк не прояснил.

Честно говоря не разбирался, почему CVAVR использует стек, адресуемый SP, только для хранения адресов возврата из подпрограмм. А для всего остального использует Data Stack, адресуемый Y регистром. Просто принял правила игры. Могу выложить asm, который генерит CVAVR для этого проекта…

Могу выложить asm, который генерит CVAVR для этого проекта…

Спасибо не не надо, разобраться в том что сгенерит компилятор без подробных комментариев, я все равно не смогу. Просто подумалось ,что это не стандартное решение кактойто задачи (стараюсь запоминать такие финты), но раз это просто особенности компилятора и привычки то не стоит заморачиватся.
Меня вот больше интересует, как у вас в телеметрии строится линия горизонта (если конкретней то наклон и вращение), это геометрическое построение или же зарание подготовленные изображения с разными углами?

Спасибо не не надо

Я забыл смайлик поставить… 😃 Хотя в OSD часто пользовался таким приемом, быстренько писал на си, компилил, смотрел что там CV наассемблировал и оптимизировал уже готовый асм-код. Быстрее получается, тем более с асмом меги никакого опыта нет.

это геометрическое построение или же зарание подготовленные изображения с разными углами

Конечно геометрия(считаются координаты) плюс графика(рисуются линии). Самое время-прожорливое,- отрисовка текста, пришлось все на асме оптимизировать…

Спасибо не не надо, разобраться в том что сгенерит компилятор без подробных комментариев, я все равно не смогу.

там код на С в коментах, а потом идёт его перевод на асм.
Например:

;// Прерывание срабатыает, когда таймер досчитывает до значения, записаного в OCR1A.
;interrupt [TIM1_COMPA] void timer1_compa_isr(void)
; 0000 0067 {
_timer1_compa_isr:
ST -Y,R26
ST -Y,R27
ST -Y,R30
ST -Y,R31
IN R30,SREG
ST -Y,R30
; 0000 0068 PORTD INV_B(4);
IN R30,0x12
LDI R26,LOW(16)
EOR R30,R26
OUT 0x12,R30
; 0000 0069
; 0000 006A if(completed_flag == SET) {
LDI R30,LOW(238)
CP R30,R2
BRNE _0x9
; 0000 006B temp = dobavka; // если данные готовы, обновляем значение temp
MOVW R6,R8
; 0000 006C completed_flag = FREE; // помечаем флаг, что данные получены
CLR R2
; 0000 006D }
; 0000 006E
; 0000 006F
; 0000 0070 if((compA + temp) > 0xFFFF ) { // проверяем, не превосходит ли сумма значения таймера с добавкой максимального значения FFFF
_0x9:
MOVW R26,R6
ADD R26,R10
ADC R27,R11
LDI R30,LOW(65535)
LDI R31,HIGH(65535)
CP R30,R26
CPC R31,R27
BRSH _0xA
; 0000 0071 compA = ((compA + temp) - 0xFFFF); // если да, вычисляем значение с учётом переполнения.
MOVW R30,R6
ADD R30,R10
ADC R31,R11
SUBI R30,LOW(65535)
SBCI R31,HIGH(65535)
MOVW R10,R30
; 0000 0072 } else {
RJMP _0xB
_0xA:
; 0000 0073 compA = (compA + temp); // если нет - просто складываем.
__ADDWRR 10,11,6,7
; 0000 0074 }
_0xB:
; 0000 0075 OCR1A = compA; // записываем в таймер новый порог срабатывания.
__OUTWR 10,11,42
; 0000 0076
; 0000 0077 }
LD R30,Y+
OUT SREG,R30
LD R31,Y+
LD R30,Y+
LD R27,Y+
LD R26,Y+
RETI
;
;

Это я в курсе, хотя такую солянку из АСМа, С и машинных кодов крайне тяжело читать не специалисту, так к тому же и проект листинг которого автор предлагал выложить (за исключением кусочка в посте 232) не содержит ни каких комментариев.

Решил проблему радикально.
Собрал себе комп для наземки на базе вот такого:

как сие называется, можно модель?

Самое время-прожорливое,- отрисовка текста, пришлось все на асме оптимизировать…

Если не секрет, в чем состояла оптимизация? т.е что не так делал С компилятор, и к чему вы привели это в асме?

Например, если объявить локальную переменную- указатель, а потом через него заполнять буфер, компилятор тупо модифицирует эту переменную и каждый раз ее копирует в X-регистр для косвенной адресации, даже если этот регистр больше в цикле не используется… Гораздо короче (ну и соответсвенно быстрее) сразу инициализировать X, и его же модифицировать.
Иногда анализ сгенерированного асма, позволяет существенно оптимизировать Си-шный код, переписав его на Си. Например, в нескольких функциях отказавшись в цикле использовать операцию остаток от деления индекса (один символ на Си, а его реализация весьма много кода за собой тянет), заменил его дополнительной переменной, скорость выполнения функции возросла в несколько раз.

LSR R18
OUT VIDPORT,R18 ; 0
NOP

и т.д.

Я с мегами сильно не занимался,
но сам делал циклический сдвиг у ПИКов прямо в порту:)

rlf PORTA,F ;
rlf PORTA,F ;
rlf PORTA,F ;
-----------------------------------------------------
меги могут прямо в порту делать сдвиг 😒???

lsr VIDPORT ;
lsr VIDPORT ;
lsr VIDPORT ;

-----------------------------------------------------

Нет, сдвиг в порту системой команд не предусмотрен.
www.gaw.ru/html.cgi/txt/doc/micros/…/start.htm

У ПИКов то-же недокументированно нигде, а шуршит на всю 😁!!!
Значит будем счупать ручками еёйные ножки😁.

Да avrstud упирается и совсем не хочет понимать

lsr PORT*,

жаль конечно…😦,
пик погибче в этом плане.

Свершилось… 😦 Запалил-таки мегу… Как, наверное, обычно - по глупости и неосторожности… Ну буду оптимистом (а что еще остается…)- нет худа, без добра… Плата после всех изменений и настроек уже и на макетку мало похожа была…
Рискну объявить конкурс на разработку печатки (под ЛУТ). Победителю (и всем участникам!) приз- софт с исходниками…
ЗЫ Млин… так хотел завтра полетать по фпв… Уже практически все настроил и готово было… 😦

…
Рискну объявить конкурс на разработку печатки (под ЛУТ). Победителю (и всем участникам!) приз- софт с исходниками…
ЗЫ Млин… так хотел завтра полетать по фпв… Уже практически все настроил и готово было… 😦

для наземки плату? или под телеметрию?

Аа…, ну конечно… уточню… Речь о OSD-телеметрии, стабилизации, автопилоте… Схема - пост 222. Вопросы в личку или даже может лучше здесь…
ЗЫ Уже заказал проц на элитане. 457р+200р доставка.

к вечеру нарисую.
И чего проц дорогой какой?

Аа…, ну конечно… уточню… Речь о OSD-телеметрии, стабилизации, автопилоте… Схема - пост 222. Вопросы в личку или даже может лучше здесь…
ЗЫ Уже заказал проц на элитане. 457р+200р доставка.

Ну да, ткните носом где платка или гербер.

гербер это кто?
TO msv
платка на 50% готова