Search in topic

Самодельный передатчик (часть 2)

договориться о протоколе обмена ВЧ модуля и проца пульта.

Ну думаю, для совместимости надо протокол обмена тот же что и у FR-SKY использовать. Чтобы можно было и в турниджи и в самодельном передатчике хоть те, хоть те модули использовать. Ну а по поводу УАРТа - в Самодельном передатчике он если мне не изменяет память - свободен, в отличии от турниджи, где тумблеры переносить надо.

делаем программатор для хмеги из ft232

avrasp умеет хмеги шить. Надо только (при необходимости) обновить прошивку и согласовать уровни парой резисторов (хмега от 5 вольт сдохнет).

можно и фрискин, его расширить надо. например, регулировка мощности, номер модели для modelmatch.
у меня СОМпортовый avr910 программатор =) он не умеет хмегу.

Сделай на меге8 аврасп. Можно выкинуть все детали, кроме кварца, двух кондеров к нему и двух стабилитронов на линии усб. Ну и делитель на резюках нужен будет чтоб на хмегу 5 вольт не подавать. Я по собственной лени лет 7 назад сделал такой (правда с прошивкой 910) из шнура усб и меги в дипе. Тупо ногами меги обжал шнур, напаял навесным кварц и пару диодов (чтоб питание понизить), замотал сверху изолентой. Делал как временное решение, досих пор живет. 😃

чтото почитал я про эти модули - гм… ощущение что еще сыровато все это… 😦

перенести выключатели в турниге не проблема… был бы толк…

чтото почитал я про эти модули - гм… ощущение что еще сыровато все это… 😦

А что сыровато то? Железо 100 лет отлажено на спектрумах, мультиплексах и т.д. Апельсины ничего не изобретали, кроме выходного усилителя мощности. Его как я понял с флайская срисовали, который тоже вроде года 3 как работает.

А софт, так Серега с протоколом разобрался и тестят эту ревизию протокола уже по всему миру в альтернативных прошивках Дево6,8,10… Ну да, наверно сыроват, но тут любой свеженаписанный софт сыроват будет. Дык оттестим, отдебажим. Хотя, по протоколу пока замечаний от пользователей не видно.

Честно не понимаю, чего все в оранжевый модуль уперлись, Валкеровский гораздо дешевле и ненужо трахаться с Иксмегой.

у валькиного апгрейдного модуля (мы же про него говорим? который для переделки не телеметрийных в телеметрийные) торчит наружу голый SPI. который несколько сложнее прикрутить к основной тяжелой программе. опять же жесткий реалтайм накладывает повышенные требования. а наладить обмен по УАРТу можно достаточно просто.

Есть в нете и под СД и пот фрискайметрию-на других сайтах-но делится не хотят

но делится не хотят

есть один нюанс. отвлеченно, я портировал одну программу под одну железку, мне тоже не хотели помогать. я дал ссылки на свои проекты, показал что я умею и чего достиг. после этого открыли доступ “в свои” и скрытые ветки форума. в конце концов, прицепить SD карту - элементарно, натянуть на нее FAT (пусть не ходить дальше корневого каталога) тоже пара пустяков. elm-chan.org посмотрите в разделе FAT библиотеки.

голый SPI. который несколько сложнее прикрутить к основной тяжелой программе

Кто мешает воткнуть еще один процессор, как собственно в оранже и сделано, только нечто более понятное, чем XMega?

хмега, PSoC, ARM, пофигу. просто есть готовый ВЧ блок, который вставляется в готовую турнигу. зачем изобретать лишние сущности.

Есть в нете и под СД и пот фрискайметрию-на других сайтах-но делится не хотят

А просить то пробовали? 😃
СД - посути епромка SPI только большая и с фат-ом. Фрискайметрия - делаешь буфер под строку, принимаешь в него уарт. Разбираешь этот буфер на куски, выдергиваешь телеметрию да на экран. Подсмотреть работу с уарт - тут кто-то выкладывал вариант для сбрасывания моделей на комп, можно в той же 9х, можно просто примеры в том же кодевижине.
Не хтоят делиться - весьма относительное понятие. Возможно просто люди сделалидля себя, их устраивает, как-то работает, но гарантий что заработает у других попусту нет. Ну к примеру с той же СД - валялась карта на 32мгб, сделали на ней. Сейчас такую хрен найдешь, а для большей - надо всю библиотеку фат переписывать. И смысл это выкладывать? Повторябельность низкая, а копипастеры потом вопросами засыпят “почему у мну не работает”. Саппорт - вобще отдельная тема. Из за его отсутвия 90% проектов умирает. Человек сделал для себя, потратил время, силы. Подарил другим, а вместо благодарности - притензии. Я вот не люблю делиться по такой причине: программист я так себе, что-то в угоду своей ограниченности могу сделать не логичным или не оптимальным или… Некоторые слезно исходники в личке вымогают, а потом там же поносят о том, что где-то комментариев мало, где-то через задницу написано и вобще они обязательно перепишут все как надо, т.к. мой код не потребный… Потом пропадают. Раздавал свой порт этого проекта на турниджи всем желающим. Желающих получить исходники оказалось всего 5 человек, из них никто в то что было ничего своего не добавил, не исправил и не выложил. И смысл был выкладывать? Из 5 двое спасибо сказали, трое помоев налили.

Ну и шкурный вопрос… Вы на других сайтах чем-нибудь поделились? Я не говорю про результаты, хотябы востребованные идеи… Самодельный передатчик с дисплеем на и2с я показал первый раз тут 6 лет назад, и только года через 3 иглб3 кажется спросил что за дисплей и как его поставить. Я описал подключение и инициализацию в двух словах и человек сам за сутки сделал, не доставая вопросами и не клянча исходники.

Алексей, “самодельный передатчик” в том виде как он написан сейчас - путь в тупик…
поэтому в нем что либо дописывать особого смысла нет…
а попробовав его переписать - уже получим другой проект 😃

опять таки большой вопрос - а нужен ли новый проект под это железо ? - большинству достаточно того функционала что уже есть, а остальные уже перепрыгнули на 9ex

кстати из вашего проекта под турнигу я брал драйвер дисплея… и он еще долго трудился в составе VCoder’a, только спустя где то год я его частично переписал в плане инициализации, и полностью в плане графических примитивов…

так что выкладывание исходников в любом виде всегда полезно для кого то…
ну а кто не может без поноса - тот пусть идет нах… и нечего о нем даже задумываться…

опять таки большой вопрос - а нужен ли новый проект под это железо ? - большинству достаточно того функционала что уже есть, а остальные уже перепрыгнули на 9ex

Под это железо ИМХО не нужно уже ничего. На этом железе и этом проекте останутся исключительно почитатели паяльника и именно этого проекта. Функционала действительно на 99% достаточно, добавить телеметрию для фрскаев, возможно переписать модуль оранджа - не шибко трудно и кому это надо - думаю сделает обязательно. У мну фрская нет и я этим заниматься не планирую. Кол-во каналов увеличивается не особо проблемно. Модули по уарту - тоже кстати уже года 4 как в этом проекте работают у некоторых. Только распространения особенного не получали ввиду редкости модулей.
За что я люблю этот проект (в любой реинкарнации) - за то что в нем работают мои идеи. 😃 Он ужастно простой, жудко логичный и лично у меня не возникает проблем ни с настройкой моделей, ни с дополнением фунционала. И я его ни на что не променяю.
Переписать заново - действительно проще написать и сделать новый. От моих модификаций - исходная печатная плата уже превратилась в макетку с кучей перерезанных дорожек и напаянных перемычек. Скорее всего я просто выкину плату и воткну в аппу когда-нибудь просто макетку с дип-40 процом (либо 644, либо 1284, в зависимости от необходимых ресурсов. Кстати последний проц - самый интересный из атмег! 😃 Гляньте сколько у него РАМ!) Возможно эта модификация - расширит рамки проекта людьми, стесняющимися поверхностного монтажа, ЛУТ и прочей магии. Но идеология ГУИ останется таже! Наглядно и просто. И никакие инструкции не нужны и понятно все.
Но всем, кто интересуется проектом именно чтобы летать - я рекомендую турниджи+ер9 как бютжетный вариант или бренды. Многие надеются съэкономить - это ошибка. Экономнее турниджи - не будет. Делать железо самому - уже посути абсурд (если это не хобби).

кстати из вашего проекта под турнигу я брал драйвер дисплея… и он еще долго трудился в составе VCoder’a,

Приятно, но вся графика (да и весь проект по сути) это этот “самодельный передатчик” от МСВ с легкими корректировками под другое железо. Приятно, что время было потрачено не зря и кому-то это пригодилось. Из постоянно летающих на том, что получилось у меня - знаю только 2 человек. Собственно, по-этому и забросил. ЕР9х фунциональнее хоть и чуть сложнее в плане понимания. За-то уже “общепризнана”. На твоем кодере много народу летает??? Статистика есть?

я летал на фокус/мсв пиленном под турнигу. экран применял свой 128х64. два года летал. потом сделал на 3310 экране, полгода летал. продал парнишке за бесценок, он несколько полетов успел до снега. ждет сезона.

На твоем кодере много народу летает??? Статистика есть?

по моей статистике около 7 человек… ну еще я 😃)

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

драйвер дисплея мсв неудачен в плане быстродействия, все таки попиксельно буквы рисовать это жесть 😃))

вот вывод символа с попиксельными координатами lcd_X, lcd_Y
это для турниги, но в принципе поставьте свое разрешение экрана по горизонтали\вертикали и пойдет для любого другого…
буфер на дисп выкидывать обычным образом…

void LCD_char(unsigned char ch, unsigned char mode) { // Вывод символа
const unsigned char *fontpointer;

if (ch<127) { // знакогенератор латиницы
fontpointer=NewFontLAT; ch=ch-32; }
else { // знакогенератор русских букв
fontpointer=NewFontRUS; ch=ch-192;}

if (mode==2) mode=lcd_blink; // если нужно отображать в режиме мерцания - то берем значение инверсии из lcd_blink

unsigned char lcd_YP=7- (lcd_Y & 0x07); // битовая позиция символа в байте
unsigned char lcd_YC=(lcd_Y & 0xF8)/8; // байтовая позиция символа на экране

for (unsigned char x=0; x<6; x++) {

unsigned char temp=pgm_read_byte(fontpointer+ch*6+x);

if (mode!=0) {
temp=255-temp;
if (lcd_Y>0) LCD_pixel(lcd_X, lcd_Y-1, 1); // если печать в режиме инверсии - сверху отчертим линию
}

temp&=0x7F;

lcd_buff[lcd_YC*128+lcd_X]=lcd_buff[lcd_YC*128+lcd_X] + (temp<<(7-lcd_YP)); // печать верхней части символа

if (lcd_YP<7) lcd_buff[(lcd_YC+1)*128+lcd_X]=lcd_buff[(lcd_YC+1)*128+lcd_X] + (temp>>(lcd_YP+1)); // печать нижней части символа

lcd_X++;
if (lcd_X>126) return;
}
}

далее, насколько я помню раньше в драйвере была ошибка в рисовании линий…
я долго правил, в итоге плюнул и написал по алгоритму Брезенхейма, в самокодере было чтото похожее, но при некоторых значениях координат работало не правильно…

void LCD_line(unsigned char x1, unsigned char y1, unsigned char x2, unsigned char y2, char mode) { // процедура рисования линии
signed char dx, dy, sx, sy;
unsigned char x, y, mdx, mdy, l;

dx=x2-x1; dy=y2-y1;

if (dx>=0) { mdx=dx; sx=1; } else { mdx=x1-x2; sx=-1; }
if (dy>=0) { mdy=dy; sy=1; } else { mdy=y1-y2; sy=-1; }

x=x1; y=y1;

if (mdx>=mdy) {
l=mdx;
while (l>0) {
if (dy>0) { y=y1+mdy*(x-x1)/mdx; }
else { y=y1-mdy*(x-x1)/mdx; }
LCD_pixel(x,y,mode);
x=x+sx;
l–;
}
} else {
l=mdy;
while (l>0) {
if (dy>0) { x=x1+((mdx*(y-y1))/mdy); }
else { x=x1+((mdx*(y1-y))/mdy); }
LCD_pixel(x,y,mode);
y=y+sy;
l–;
}
}
}

дальше несколькими подпрограммами добавляется печать токенов - это когда один байт указывает на строку которую нужно напечатать, наверное для самокодера не самое нужное (в меге 128 дофига места), но для турниги уже актуально
вызывать LCD_str - она уже сама разбирает что нужно напечатать и в каком порядке вызвать…

void LCD_token(unsigned char tknum, unsigned char mode) { // печать токена по номеру
char *tokenpointer;

tokenpointer=(char*)pgm_read_word(&(token_tbl[tknum])); // получим адрес указателя на строку (адрес элемента массива)

while (pgm_read_byte(tokenpointer)!=‘\0’) {
LCD_char(pgm_read_byte(tokenpointer), mode);
tokenpointer++;
}
}

void LCD_prn(unsigned char chr, unsigned char mode) { // печать символов на дисплее с кодами токенов
if ((chr>99) & (chr<192)) LCD_token(chr-100,mode);
else LCD_char(chr, mode);
}

void LCD_str(char *str, unsigned char mode) { // печать строки из Flash

if (mode==2) mode=lcd_blink;
if ((mode==1) & (lcd_X>0))
for (char y=0;y<8;y++) LCD_pixel(lcd_X-1, lcd_Y+y-1, 1); // если печать в режиме инверсии - сбоку от строки отчертим линию

while (pgm_read_byte(str)!=‘\0’) {
LCD_prn(pgm_read_byte(str), mode);
str++;
}
}

массив токенов описан по следующей схеме

char model[] PROGMEM = “МОДЕЛИ”;
char reset[] PROGMEM = “СБРОС”;
char load[] PROGMEM = “ЗАГРУЗИТЬ”;
char save[] PROGMEM = “ЗАПИСАТЬ”;

char channel[] PROGMEM = “КАНАЛ”;

char *token_tbl[] PROGMEM = { // таблица адресов токенов
model,
reset,
load,
save,
channel

};

в общем как говорит один мой знакомый - “нет предела совершенству”
поэтому драйвер дисплея у меня и переписался сам собой…

осталось найти в себе силы переписать остальное 😃

опс… извиняюсь, исправьте строки в LCD_char на следующие

lcd_buff[lcd_YC*128+lcd_X]=lcd_buff[lcd_YC*128+lcd_X] | (temp<<(7-lcd_YP)); // печать верхней части символа

if (lcd_YP<7) lcd_buff[(lcd_YC+1)*128+lcd_X]=lcd_buff[(lcd_YC+1)*128+lcd_X] | (temp>>(lcd_YP+1)); // печать нижней части символа

значения лучше не складывать арифметически, а логическим ИЛИ !!!
гм… вроде правил у себя… наверное при переходе с версии на версию где то опять просмотрел как откатился 😃

драйвер дисплея мсв неудачен в плане быстродействия, все таки попиксельно буквы рисовать это жесть 😃))

Для больших экранов - да, соглашусь. А вот для маленьких - весьма оправданно было. Это позволяло выводить текст не в координатах “координата по х, номер строки по Y”, а в координатах (х,y). Т.е. больше инфы можно было на дисплей упихать. Для больших дисплеев еще критическим моментом получался размер экранного буфера. Он нехило съедает ОЗУ. Можно и без него обходиться. Так что тут и плюсы и минусы есть.

То, что библиотека относительно тормознутая - это в принципе мелочь, т.к. крутится она в основном цикле, не влияющем на времянки управления. Легкое запаздывание гуи не влечет фатальных последсвий.

За-то у кодера есть другой плюс - однопотоковость. Точнее единственное прерывание. 😃 И то, точнее было… Это гарантировало отсутвие джиттера без просчета времянок. Всетаки атмеги не очень удобны своим жестким приоритетом прерываний.

А чем генерация ппм не понравилась? Хотя сейчас ппм вобще в принципе уже не нужен, лучше все в цифре гнать.

(lcd_YC+1)*128

Ну и на 128 глупо умножать. Хотя современные компиляторы должны оптимизировать это меняя на сдвиг. Надо асм смотреть.

Для больших экранов - да, соглашусь. А вот для маленьких - весьма оправданно было. Это позволяло выводить текст не в координатах “координата по х, номер строки по Y”, а в координатах (х,y). Т.е. больше инфы можно было на дисплей упихать.

Алексей, та процедура что я предложил для печати - печатает как раз в пиксельных координатах и по X и по Y …
если посмотреть то она даже проще чем попиксельная печать с циклами по x,y…

Для больших дисплеев еще критическим моментом получался размер экранного буфера. Он нехило съедает ОЗУ. Можно и без него обходиться. Так что тут и плюсы и минусы есть.

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

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

За-то у кодера есть другой плюс - однопотоковость. Точнее единственное прерывание. 😃 И то, точнее было… Это гарантировало отсутвие джиттера без просчета времянок. Всетаки атмеги не очень удобны своим жестким приоритетом прерываний.

это скорее минус 😦
тяжелое прерывание при увеличении количества вычислений делает невозможным например захват ppm с разбором…
в принципе для самокодера наверное это не страшно (функционал простой, считается быстро), а вот когда нужно обсчитывать 16 каналов, и еще всякие прибабахи считать в виде регулируемых микшеров, фильтров, кривых, задержек - то уже реально приходится считать время на все… 😦
я пробовал на турниге (в проекте VCoder генерация PPM которого была сделана как в самокодере - в одном прерывании) сделать захват в другом прерывании - так при тестах - из-за длинного прерывания иногда выпадал прием канала с ученика… причем с количеством каналов до 5ти все было ОК, а вот при количестве каналов 7 - уже захват был через раз… фактически пока шло прерывание передачи могло произойти 2 прерывания захвата… на выходе была каша…

А чем генерация ппм не понравилась? Хотя сейчас ппм вобще в принципе уже не нужен, лучше все в цифре гнать.

кому как, у меня пока все передатчики PPM съедают, спектрумовских у меня нет… да и смысла не вижу в них большого - у меня нет моделей которые потребовали бы больше 8 каналов

Ну и на 128 глупо умножать. Хотя современные компиляторы должны оптимизировать это меняя на сдвиг. Надо асм смотреть.

я уже смотрел, сдвиг и применен…
просто есть дисплеи с другим размером строки в байтах (например есть экраны на 84 точки по горизонтали),
править фрагмент кода (lcd_Y+1)*128 намного нагляднее чем (lcd_Y+1)<<7 - вот здесь фиг поймешь что я имел ввиду, и что сюда нужно будет написать (lcd_Y+1)*84 😃

Прошивка для I2C дисплеев и внешней памятью. В архиве уже компиленные три варианта под 12, 25, 45 моделей.
Количество моделей, максимум, примерно 24С64 - 12 моделей, 24С256 - 50 моделей, 24С512 - 100 моделей. Память и дисплей RDX0154 (TIC154 не проверял, но должно работать) сидят на аппаратном TWI (у атмеги вывод 25 - SCL, 26 - SDA). Есть подсветка, активная, но без ШИМ. Подключается PORTB.7 (17 нога меги).

Перевод меню на русский для RDX0077 и 0154
В архиве-для 0154-количество моделей для 24С32-пока другой не нашёл
На фото 0077 со снятой передней панелью пульта-мешало сфотографировать
И фузы

Вах, триммера потрясающие!!!