Я начал эту статью так, потому что Linux невероятно интересная и прогрессивная платформа, но работать в ней человеку пришедшему из мира $MS титанически тяжко... Как в распространенной шутке, собственно, "первые три года тяжело, а потом привыкаешь" :) Вот и я подобно Кулику постоянно предпринимаю попытки найти философский камень в Linux, но всегда оказываюсь перед проблемой недостатка опыта и знаний что бы его найти. :) Отчаявшись приспособиться к линкусовой психологии шарахаешься опять в мир $MS где все привычно - где работают все "программаторы", где нет проблем с Quartus-ом, с VMLab-ом, но при всем при этом нет той понятности и стройности, а главное открытости операционной системы.
Начитавшись до дури статей я приступил: выкачал старого знакомого Ubuntu сменившего за мое отсутствие номер версии, установил и... и начала морочиться. Видимо нормальные люди разрабатывают в IDE, но я же настолько прирос к FAR-у (приятно осознавать что используешь продукт земляка воспитанного тем же ВУЗом, что и ты, с которым можно сказать через одно рукопожатие знаком :)). Ну и поскольку я уже привык к файловому менеджеру то MC меня начал раздражать практически сразу, я его выкинул из головы и перешел на терминал где возни конечно побольше, но хотя бы раздражения не вызывает. Тут надо сказать, что я забыл о великолепном ресурсе, который подготовил Vitasam, специально для тех кто отважился спрыгнуть с Win. Потерял бы меньше времени.
Начать необходимо с avr-binutils, avr-gcc, avr-lib, avrdude как основного и самого необходимого инструментария разработчика.
Затем задуматься над вопросом в чем писать. Vitasam предложил не плохой вариант без нагромождений - Geany. В принципе вариант достойный, единственное что не позволяет создать makefile как это делал например автоматически, VMLab. Страшного в этом ничего нет, те кто работал с WinAVR помнят что в поставке всегда был инструмент MFile. Мне приходилось пользоваться им крайне редко - обычно все решалось копированием имеющегося makefile и изменением содержимого: списка файлов проекта, типа микроконтроллера, опций компиляции. Однако автоматический генератор makefile существует он интерактивный так же как и в Win и он скрипт поэтому требуется небольшая доработка. Сам MFile находится по адресу. Доработка скрипта попила много крови, сперва я не понял почему не стартует скрипт, оказалось что в заголовке файла (который является для Linux исполнимым) прописан не Ubunt-овский интерпретатор Tcl/Tk. Прописывание интерпретатора Tclsh, оказавшимся в Ubuntu не самим файлом, а лишь ссылкой на него (/etc/alternatives/tclsh) ничего не решило. Tclsh - интерпретатор не поддерживающий работу mfile в GUI. Но на широких просторах интернета благодаря google отыщется все, а именно то что для запуска mfile нужно использовать wish прописав внутри самого mfiel строчку запуска #!/usr/bin/wish.
После компиляции и сборки обычно необходима симуляция. В Win это либо VMLab, либо AvrStudio, либо Proteus. С тех пор как VMLab стал свободен привык использоваться им, хоть он и вызывает у меня нарекания по навигации в исходнике. Под Wine VMLab устанавливается исключительно, даже под старый WINE 1.0.1, который по умолчанию находится в Ubunt-овском репозитари (sudo apt-get wine). Само собой изменения вносимые на ходу в проект VMLab компилировать toolchain-ом, который находится в Linux не будет. Конечно можно поставить под Wine и WinAVR но получится что-то вроде "масло-масляное". На сайте VMlab есть информация что включением опции Any 3rd party high level lenguage generating COFF при создании проекта производится выбор компиляции и сборки сторонними средствами генерирующими исполняемый файл в формате COFF для отладки его в VMLab. Эта ключевая фраза задала мне жару часа на 4 поиском ошибки makefile при создании COFF.
Рис.1. Использование VMLab для отладки проектов в Linux под WINE.
Благодаря ошибке с COFF возвращаемся к этапу номер один. В комплекте avr-binutils поставляется маленькая, но так необходимая утилитка avr-objcopy собирающая из elf файла coff файл. Попросту конвертор исполняемых форматов который нужен потому, что elf файлы VMlab не приемлет. Запущенный из makefile avr-objcopy при сборке выдает ошибку
avr-objcopy: "имя преобразуемого файла".cof: Invalid bfd target
Благодаря своему не важному знанию языка и не желанию вчитаться в "англицкий" текст хотя бы в течении пяти минут, я минимум три часа провел в бесполезном серфинге. Вот пост рассказывающий как победить ошибку. Все достаточно тривиально для того что бы ошибка была исправлена нужно либо "одеть" на новый avr-objcopy заплатку, либо взять старый файл, в котором этой проблемы еще не существовало. Репозитарий Debian или Ubuntu содержит свежие avr-binutils и ошибка там себя проявляет, а вот распространенный некогда cdk4avr остановился на версии GNU objcopy 2.16.1 + coff-avr-patch (20050630) (CDK4AVR 3.0 2.16.1-20060708) и в нем этой ошибки нет. Однако не спешите ставить это пакет, потому что остальные утилиты из avr-binutils нас устраивают , да и не стоит мешать сапоги с конфетами. Необходим только avr-objcopy нужно его извлечь из пакета cdk-avr-binutils_2.16.1-20060708_i386.deb находящегося на сайте архиватором и поместить, внимание !!! в два места /usr/bin и /usr/bin/lib/avr. Во вторую папку на всякий случай, хоть путь $PATH и указывает на /usr/bin, а вдруг где то жестко в makefile будет прописано /usr/bin/lib/avr для вызова binutils. Кстати копирование под Ubunu в системные места разрешено только "судоерам", так что про sudo перед командой копирования cp забывать не нужно.
#sudo cp avr-objcopy /usr/bin
И так проблем симуляции железа уже решена, но можно чуть расширить ее посмотрев в сторону Code::Block IDE который дает все возможности и по созданию проекта (вплоть до сборки) и по его симуляции с применением avr-dbg и simulavr, все это очень хорошо описано на этой страничке и нет смысла пересказывать. Однако у меня почему то не заладилось с отладкой все переменные были пустые хоть отладчик ходил по веткам кода.
Следующий вопрос является наиболее важным - ЧЕМ ШИТЬ?
Все время до этого пользовался удачным вариантом USB программатора AVR910 USB (разработки prottoss).
Программатор хороший но по рассказам на форуме линуксоидов для его использования необходимо пересобирать ядро включив туда изменения для нештатной работы с USB, либо перешивать сам программатор в avr-doper. Перешивать я не стал боясь оказаться без удобного рабочего инструмента (в загашнике на всякий случай есть деревянный PonyProg), а стал искать какой программатор легкий в сборке поддерживается и работает без нареканий в Linux. Таким программатором оказался USBasp. Конструкция похожа на AVR910 USB, но для того что бы на сигнальные линии диф-пары USB не попало напряжение питания микроконтроллера (в схеме USBasp VCC равно 5 вольт) использовано два стабилитрона на 3.6В. Такой "выверт" необходим из за того что не во всех материнских платах чипсеты толерантные к уровню TTL и требуют конвертирования уровней. Конструкция AVR910 USB обеспечивает питание микроконтроллера программатора 3.6V, чем координально решает вопрос с попаданием 4..5V уровней на сигнальные линии USB. Падение напряжения после двух диодов приводит к тому что напряжение питание VCC снижается с 5V до приемлемых 3.5-3.6V. Переделка отражена на рис.4., дополнительные детали (два диода и конденсатор) выделены красным цветом, а номинал резистора R3 изменен на 1.5КОм (на USBasp R3 = 2.2КОм).
Рис.2. Часть схемы USBasp обеспечивающая толерантность линий USB к уровню сигналов TTL с AVR.
Рис.3. Решение Prottoss на "корню" ликвидирующее не толерантность линий USB сигналам с AVR.
После сборки и зашивки USBasp его наличие в Linux можно проверить утилитой lsusb вот как это выглядит:
# lsusb
Bus 002 Device 003: ID 16c0:05dc VOTI USBasp AVR Programmer
Bus 002 Device 002: ID 16c0:05e1 VOTI
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Устройство 16c0:05dc это USBasp, а 16c0:05e1 это AVR910 USB. На форуме рекомендуют записать правило (помните про sudo) для определения USBasp утилитой avrdude и другими программами:
# UDEV-style hotplug map for usbasp programmer
# Put this file in /etc/udev/rules.d
SUBSYSTEM=="usb", ATTR{product}=="USBasp", ATTR{idProduct}=="05dc", ATTR{idVendor}=="16c0", MODE="666"
При помощи утилитки avrdude шьется огромная часть AVR и в принципе ее более чем достаточно для работы. Документация на русском Часть 1, Часть 2 также доступна благодаря блогу.
Но под USBasp оказывается есть софт не только для Windows, но и для Linux.
Однако надо сказать софт этот принес мне массу головоломок. После установки (простой распаковки) xAVR необходимо было установить wxGTK, как это рекомендует автор (usblib уже стоял). wxGTK взял с репозитария версии 2.8. Софт для работы с USBasp запускается из под sudo, о чем предупреждает автор. После запуска ./avrprog заявляет, что с библиотеками 2.8 работать не хочет, желает 2.6. Деинсталируем gtklib 2.8 ставим 2.6 - софт выдает уже одну ошибку вместо двух, где требует so-шку из библиотеки 2.8. Предупреждаю сразу ставить 2.8 бессмысленно получим тоже сообщение "с 2.8 несовместимо". Поступил так: выкачал RPM (для RedHart нашел в какой пакет засунуты нужные *.so) и скопировал их по адресу, который от меня требовали /usr/lib. Однако avrprog этого оказалось мало и он сгонял меня за следующим *.so из очередного пакета wxGTK. Под конец потребовав tiff-овскую библиотеку (tiff*.so), ублаженный запустился.
Рис.5. Ублаженный xAVR
Рис.6. Программатор USBasp с небольшими доработками, в работе.
Рис.7. USBasp макетная плата, работы не так уж много.
Рис.8. USBasp макетная плата, оборотная сторона.
Поскольку большинство программ мечтают о запуске через sudo, но не являются при этом терминальными то могу предложить использовать простой алгоритм по их запуску со стола кликом по значку - в созданном текстовом файле на столе располагается скрипт запуска
#!/bin/bash
gksudo /usr/bin/dolphin
Файл сохраняется с нужным именем, и назначается исполняемым выбором крыжика в закладке ПРАВА - позволять исполнения файла как программы. Кликом на это скрипт программа запустится с правами root, запросив при этом пароль.
На Рис.4 у Вас 2 и 3 ноги USB порта поменяны местами по сравнению с оригинальной схемой AVRasp, работать будет?
ОтветитьУдалитьМегу самого контроллера пить тоже 3.6В?
И на Рис4 С1 точно не электролит 22mF?
ОтветитьУдалитьи еще, может плохо искал, но в даташите на мегу8 не нашел, что она поддерживает 12мгц, а только 16 или 8. или это не важно?
ОтветитьУдалитьЯ прошу прощения что долго отсутствовал пока растет сын времени на блог нет совсем.
ОтветитьУдалить1. Схему от USBasp менял только в части питания и подтяжки ног как у Prottos. К сожалению монтажку отдал (та которая на фото) друг мне изготовил PCB под TQFP, в принципе могу выложить сюда печатную плату.
2. Нужно ставить электролит, так найти не полярный на такую емкость проблематично.
3. По поводу тактовой частоты не принципиально для AVR по фьюзам есть различие по резонаторам с высокой частотой и низкой. Соответственно нужно ставить HIGH. Если поставить 15.385 к примеру все равно заведется только в данном случае для USB нужно именно 12.000MHz