Самодельный передатчик (часть 2)
"…device will enter the SPI Serial Programming mode. PEN has no function during normal operation." Хотя я вроде-бы никуда его не подключал…
Читал… Тыкал тестером - да, он, похоже, реально изнутря подтянут к VCC. Мучал вопросами народ на “телесистемах” - никто с ним ничего не делает, так и висит в воздухе. И программируется нормально.
И здесь ни у кого никаких проблем/вопросов не было.
А у меня: пока на землю не посажу - не программируется. Пока с земли не отпущу - в рабочий режим не переходит. Вывел его в разъем программирования и добавил в “маму” перемычку. Но все же как-то странно… 😃
И неудобно - приходится разъем постоянно снимать/ставить.
Надо еще инет порыть…
Самое главное в этом деле - форматирование и документирование. Иначе и дальше не разберётесь. Забывается всё очень быстро…
Ну и обязательно применение системы контроля версий - я использую TortoiseSVN и Araxis Mergre для сравнения файлов. Если есть желание могу небольшой ликбез по использованию устроить…
Если данная ветка позволяет-было бы интересно ознакомится.
Вот, вот она лажа с этими АВР! Плохая архитектура для нашего применения - у неё различная память по разному адресуется, а это значит что нельзя в функцию передавать указатель как на данные во флеше, так и на данные в ОЗУ. В конкретном примере нет возможности создания динамичных заголовков меню. Например, я хотел сделать формирование заголовка как “CH %d Mixer” и обломался. А сделать всё из ОЗУ нельзя - его и так мало… Так что действительно
Ну пожалуй от мк и не стоит требовать возможностей АРМ и х86 архитектур- задачи у них разные. А по сему обектное програмирование реализуется в мк в урезанном виде. Долго пытался найти компромис в данном вопросе- итог- нечто среднее между первыми версиями данного проекта и меню Николая. Наверное повторюсь, но всеже- главной задачей данного проекта (иначе проще купить готовую апу) считаю возможность изменения функциональность (добавить/убрать функции) в зависимости от предпочтений пользователя. Поэтому движок меню должен иметь минимальные возможности по отображению/перемещению по пунктам меню. Сама структура меню должна быть понятна на этапе инициализации
flash MENU_STRUCT MenuTable[MenuMaxItems]=
{
//-|---NameMenuDisp---|------|level|--|----Param-|-------|---------FUNC----------
{"SCR", 0, 0, &ShowMainDisp},
{ "Main", 1, 0, &ShowStdMenuDisp},
{ "Model", 2, 0, &ShowStdMenuDisp},
{ "Select", 3, MAX_MODELS, &ShowSelectModelDisp},
{ "Save", 3, MAX_MODELS, &ShowSaveModelDisp},
{ "Name", 3, MAX_MODELS_NAME+1, &ShowModelNameDisp},
{ "Mode", 3, 0, &ShowStdMenuDisp},//&&
{ "Settings", 2, 0, &ShowStdMenuDisp},
{ "Controls", 3, 0, &ShowStdMenuDisp},
{ "Curve", 4, CURVE_NODES+1, &ShowCurveDisp },
{ "DR&Exp", 4, 3, &ShowDRExpDisp},
{ "Swich", 4, 4, &ShowSwichDisp},
..........................................................................
пункты должны удалятся/добавлятся не требуя изменения кода программы за исключением кода, отвечающего за отображение соответствующего пункта.
Т.е. желающему модифицировать прошивку под себя допустим добавлением тахометра нужно будет вставить соотв. пункт в структуру меню и накиидать функцию отображения и изменения параметра. К сожалению реально в программном развитии пректа заинтересоваными оказались лиш 3 человека:)
Кажется, нашел я причины фигни с ногой !PEN. На ГАВе (www.gaw.ru/html.cgi/txt/doc/micros/…/19_2.htm):
====================================================================
Последовательность подачи питания: подать напряжение питания между VCC и GND, когда на входах RESET и SCK присутствует лог. 0. В некоторых системах, программатор не может гарантировать, что SCK = 0 при подаче питания. В этом случае необходимо сформировать положительный импульс на RESET длительностью не менее двух тактов ЦПУ после того, как SCK принял низкое состояние. Альтернативно сигналу RESET можно использовать вывод PEN. В этом случае будет важно только значение PEN во время сброса при подаче питания. Если программатор не гарантирует, что при подаче питания SCK =0, то использование PEN недопустимо. При использовании данного метода микроконтроллер может вернутся к нормальному режимы работы только снятием и возобновлением питания.
====================================================================
Похоже, что у меня сигнал Reset слишком короткий. Хотя до сих пор ни один камень не жаловался…
А вот и нифига! В Hitec Laser 6 стики используют не весь диапазон…
Значит хреновый объект модернизации 😃… В таком случае лучше использовать АЦП в диф. режиме. А пляски с регулировкой АРЕФ всеравно не лучшее решение.
К сожалению реально в программном развитии пректа заинтересоваными оказались лиш 3 человека
Так а что Вы хотите? Выложите свою версию с исходниками, и заинтересованных прибавится… Свое мнение о нецелесообразности коллективного развития столь несложножной поделки, уже неоднократно высказывал. Прийдется подстраиваться к чужим идеям, структурам, интерфейсам, стилю итп. А это требует серьезного менеджмента и займет больше времени, чем все еще раз под себя переписать.
Вот когда перейдем на ARM, начнем писать операционку для него, ну и дальше интерпретатор жавы, мр3-кодер, блюпуп с тачхрином приворачивать, тогда да… в одиночку сложновато справится будет… 😃
“К сожалению, реально в программном развитии проекта заинтересованными оказались лишь 3 человека”
А все ли могут программировать достаточно серьёзные вещи?
И опыт, и знания у всех разные…
Так а что Вы хотите? Выложите свою версию с исходниками, и заинтересованных прибавится… Свое мнение о нецелесообразности коллективного развития столь несложножной поделки, уже неоднократно высказывал. Прийдется подстраиваться к чужим идеям, структурам, интерфейсам, стилю итп. А это требует серьезного менеджмента и займет больше времени, чем все еще раз под себя переписать.
Вот когда перейдем на ARM, начнем писать операционку для него, ну и дальше интерпретатор жавы, мр3-кодер, блюпуп с тачхрином приворачивать, тогда да… в одиночку сложновато справится будет… 😃
Собственно с исходниками проблем нет.
narod.ru/disk/16006018000/prj.rar.html
В архиве сам проектик в кодевижене ии модель в протеусе- ррм-ппэмит, энкодер работает итд.
Реализовано большинство базовых функций.Если найдутся заинтересованые- постараюсь обяснить что-почему, но вроде все должно быть ясно. Проект особо не документировался:(, многие куски вставлены контрол-с, но большинство кода было переработано.
Вобщем надеюсь на заинтересованность(будет интересна и критика с исправленым кодом 😃).
сорри не ту ссылку дал, вот правильная prjmod.rar
сейчас посмотрим☕
хочется сравнить с 1.8
и посмотреть что нового
Если можно, пожалуйста, выложите прошивку v.1.8 под дисплей NOKIA3410. Заранее благодарен.
Вот для 3410 😒
Прошу прощения, но это чото не то или я чего-то не понял
все правильно ето на 3410
прошивай должон работать
Так где HEX файл
вот😁
Коллеги, ткните носом, где можно посмотреть методику настройки ВЧ-модуля, который в этом топике выложен. А то при внедрении кодера внутрь своего Flash-4 случайно коротнул ламели батарейного отсека на ВЧ-часть платы. Вышедшие из строя транзисторы заменил, вроде работает, но сильно греется выходной транзистор ( у меня спиральная антенна, настраивал по Глайдеру).
Пока внутрь не лазил не знал, что транзистор греется - передатчик работал отлично. Может он и раньше грелся, а может после расстройства катушек начал.
Интересует настройка предвыходного каскада и П-фильтра выходного каскада.
Из инструментов есть тестер, осциллограф. Радиолюбительский опыт большой, только с ВЧ-техникой дел до сих пор не имел.
Буду рад любой помощи.
Спасибо!
Я сейчас пытаюсь пристроить к кодеру дисплей TIC154. За основу взял исходники от MSV.
Такое ощущение, что функция displ_head из модуля displ.c работает как-то криво. Вывод строки начинается слишком близко к середине - видимо, некорректное значение возвращает функция LCD_get_char_len из модуля LCD_3320.c.
А знаний не хватает. Не понимаю, как определяется ширина символа через font_norm[ch-32][0].
Расскажите, плиз…
Я сейчас пытаюсь пристроить к кодеру дисплей TIC154. За основу взял исходники от MSV.
Такое ощущение, что функция displ_head из модуля displ.c работает как-то криво. Вывод строки начинается слишком близко к середине - видимо, некорректное значение возвращает функция LCD_get_char_len из модуля LCD_3320.c.
А знаний не хватает. Не понимаю, как определяется ширина символа через font_norm[ch-32][0].
Расскажите, плиз…
точно не помню, но в двух словах: тот шрифт что используется имеет разную ширину символов в точках. Ширина указана в 0 злементе массива шрифта. Для вычисления длинны слова в точках берем кол-во символов умноженное на соотв значение длинны каждой буквы шрифта.
Прошил проц прошивкой которая выше Coder3410(1.8).
Огромное спасибо – работает, но только все равно изображение не на весь экран.
Мелковато как-то.
Можно исправить этот недостаток???
Заранее благодарен.
Ширина указана в 0 злементе массива шрифта.
Понятно! Да, у шрифта font_norm описание символа = 9 байт, и в нем да, 0-й элемент сильно похож на ширину.
Но я включил у себя шрифт “font8x8”, а у него описание символа занимает почему-то всего 8 байт. И нулевой элемент на ширину совсем не похож.
И фиг с ним! Не больно-то оно и нужно, это центрирование…
где можно посмотреть методику настройки ВЧ-модуля
Уже отвечал, повторю свое ИМХО: слегка подстроить (выжать максимум) можно по индикатору поля или даже по макс. гулу в комп. колонках (мультипликативная помеха). Серьезно настроить/согласовать АФУ без КСВ-метра (а лучше + антеноскопа) невозможно никакими “народными” средствами. Тем более сильно укороченную антенну… Тем более с суррогатным противовесом…
2EagleB3 displ_head выводит заголовок по центру экрана. Левая координата считается как (width_screen/2)-(width_string/2). Меняйте width_screen и все должно быть ок. font8x8 -рудимент от первых версий. Для его использования необходимо менять функцию LCD_char.
2Серж ждите, может кто-нибудь поправит код для экрана с вашим разрешением. Для моей проги это непростая задачка… 😦 а для полноценного использования большего разрешения вообще полкода прийдется переписывать…
У VRV вроде бы как раз под 3410.