Введение
Итак, сначала краткий обзор того, о чем уже много раз говорено. Вот наш подопытный:
Изначально это – китайский роутер, снабженный USB-портом, и позиционирующийся как мобильный раздатчик 3G-интернета (в USB предполагается втыкать 3G-модем). За наличие USB-порта и малые габариты он и полюбился разработчикам, потому что, по сути, мы имеем миниатюрный компьютер с полноценным линуксом (OpenWRT) на борту, снабженный USB и даже имеющий несколько свободных GPIO. Продается за сумму порядка 850 рублей в Москве.
Что касается его собрата TL-WR703N. Аппаратно он почти полностью идентичен MR3020, но предназначен исключительно для китайского рынка, поэтому у нас его найти намного труднее. Из отличий – он меньше по размерам (размер всего роутера, вместе с корпусом, равен размеру печатной платы MR3020), у него меньше GPIO (на которых у 3020 висят светодиоды), и, по непроверенным мной данным, несколько хуже антенна Wi-Fi.
Что касается разнообразных модов и хаков, описанных в сети – в основном, на зарубежных сайтах, описывают работу именно с 703N, но 99.99% этих хаков без изменения подходят для MR3020.
Аппаратная часть представлена вот этим:
- Atheros AR7240 CPU (400Mhz)
- Atheros AR9331 Chipset (integrated wireless)
- 802.11 b/g/n 150Mbps (130Mbps real)
- wireless power output 20dBm — 100mW
- 4 MB flash memory
- 32 MB RAM
- USB 2.0 port
Далее я настоятельно рекомендую ознакомиться со статьями wiki.openwrt.org/toh/tp-link/tl-mr3020 и wiki.openwrt.org/toh/tp-link/tl-wr703n и сопутствующими им материалами, чтобы получить необходимые представления об этих роутерах и OpenWRT, так как просто перепечатывать уже написанное в вики в эту статью я считаю нецелесообразным.
Если базовое понимание о работе с OpenWRT есть – идем дальше.
Пути развития
Итак, что больше всего огорчает в этом роутере?
- 0. Нулевой пункт объединяет в себе то, на что, увы, мы повлиять никак не сможем. Это, собственно, роутерное происхождение железа – то есть, тот факт, что оно не предназначено для разработчиков, схематика закрыта, и, вообще говоря, мы не имеем права модифицировать его и использовать в коммерческих продуктах. А также тот факт, что когда китайцам надоест его производить, все решения на нем придется срочно перетаскивать подо что-то другое.
- 1. Малый объем ПЗУ – в нашем распоряжении всего 4 мегабайта флеш-памяти, около 1.5 из которых заняты прошивкой
- 2. Один порт USB – учитывая, что часто требуется много периферии (камеры, модемы, GPS, флешки) – это тоже печалит.
- 3. Не очень большой объем ОЗУ – 32 мегабайта.
Итак, начнем по порядку.
Не для нас железо паялось
Что касается пункта 0 – все что мы можем сделать на этот счет – перейти на другую аппаратную платформу. Из доступных разработчику – плата Carambola. Почти идентичная по характеристикам роутеру, почти идентичная по размерам, почти идентичная по цене (если не считать доставку). Предназначена для разработчиков, выведена куча GPIO, можно подпаять что душе угодно.
Из недостатков – схематика, вопреки расхожему мнению, таки закрыта. Открыта только схематика их дев-боарда, в который эта карамбола вставляется.
А также к недостаткам можно отнести стоимость доставки и время ожидания – роутер получается намного дешевле и быстрее (можно сразу же приобрести за 850 рублей в соседнем магазине).
Плюс, неоднозначное свойство карамболы, которое нельзя отнести ни к достоинствам, ни к недостаткам – на плате не смонтированы ни USB-разъемы, ни развязка с разъемами Ethernet – только голые пины. В случае, если вы проектируете свою базовую плату, в которую будет втыкаться карамбола – это несомненный плюс. Если же нужно быстрое решение из серии «накупил готового и соединил» — придется помахать паяльником.
Переходим к пункту 1.
Малый объем ПЗУ
В принципе, все зависит от ваших нужд. При желании можно упихаться в эти несчастные 4 метра, и потом следить, чтобы, не дай Фон Нейман, не записать какой тяжелый лог из проги.
Я лично рекомендую память сразу расширить и забыть о ПЗУ навсегда. Это одна из тех вещей, которая обеспечит вам комфортность работы без постоянных мыслей «а сколько там у меня осталось», поэтому поговорим о способах осуществления этого замысла.
Начнем с самых экзотических – можно перепаять саму флешку.
В чем плюсы решения? Очевидно, в том, что все остается интегрированным в плату роутера – ничего не висит снаружи, потребление остается низким.
В чем минусы? В том, что посадочное место там под корпус SO-8, в котором из попинно-совместимых флешек есть только 8-метровые. Это не то расширение, которое я подразумевал, говоря «комфортная работа». Однако, если для вас критичен плюс этого решения – вполне осуществимо. Прочитать про это можно тут. Если кратко – вам необходимо будет после перепайки пересобрать загрузчик и ядро, не забыв его пропатчить на предмет емкости флеш-памяти, размещения в ней системы и идентификатора чипа, без чего устройство откажется стартовать.
Еще более экзотический вариант – на внешней плате разместить не совместимую по пинам флешку, и, отпаяв родную память роутера, завести управляющие пины (шина SPI) на нее. Это позволит вам выйти за пределы 8 мегабайт, но потребует очередного патча ядра и загрузчика, чтобы линукс эту флешку опознал. Вариант на очень большого любителя. Его разновидность — использование одного из свободных GPIO как программного пина выбора слейва на шине (SS) и подключение дополнительной флешки в параллель к имеющейся. Если предыдущий был на любителей, то этот – для некромантов-извращенцев, желающих получить монстра, сшитого из кусков трупов. Однако, реализуемый, на мой взгляд.
Наконец, традиционное решение – использовать внешнюю память с USB-интерфейсом.
Плюсы – быстро, удобно, не требует пересборки ядра (только установки соответствующих модулей) и абсолютно не требует пересборки загрузчика. Память можно расширять сколько влезет, поставив флешку на 8 ГБ я навсегда забыл о проблемах со свободным местом на роутере.
Минусы – занят один USB-порт, потребление тока возрастает миллиампер на 50. В случае монтирования ее как корневой ФС (будет рассмотрено позже) возрастает время загрузки. Сама флешка может быть большой – не всегда приятно когда болтается такой довесок.
Итак, давайте начнем с последнего минуса (размера флешки) и подумаем, что с ним можно сделать. Проведя обзор рынка, я пришел двум вариантам «из коробки» и одному – радиолюбительскому. Что касается первых двух, то здесь все просто: на рынке существуют очень миниатюрные флешки и очень миниатюрные микро-SD картридеры:
Устройство считывания/записи карт памяти Hama
В принципе, и тот и другой вариант достаточно миниатюрны, чтобы не раздражать, будучи воткнутыми в USB, однако, изначально я предполагал отпаять микросхему контроллера и разместить ее на своей плате, чтобы избавиться от корпуса и сделать устройство более интегрированным – все расширения и дополнительное питание я планировал разместить на второй плате, размером с плату самого роутера. Я остановился на картридере, так как этот вариант показался мне более гибким, с точки зрения возможности выбора носителя по объему и скорости чтения, а также его замены. После приобретения картридера я снял с него часть корпуса (все остальное было жестко заделано в сам USB-разъем, туда же вставлялась micro-SD карта), что можно лицезреть на фотографии ниже.
К моему великому разочарованию, мост USB-2-SD оказался выполнен в виде бескорпусной микросхемы, залитой компаундом, не предназначенной для выпайки. Однако, перехватив VID и PID этого девайса, я смог отыскать соответствующую микросхему. Это оказалось творение фирмы китайской фирмы Silicon Motion. Да, они производили эти микросхемы и в корпусном варианте. Возможно, их даже можно было достать у нас. Проблема была в том, что этот мост являл собой традиционное для таких решений 8051-ядро+контроллер SD+контроллер USB в одном кристалле, и чтобы заставить его работать, нужен был софт, который подобные фирмы не предоставляют одиночным покупателям.
Исходя из этого можно сделать вывод (упомянутое выше радиолюбительское решение): если есть желание решить эту задачу красиво, и разместить на своей плате не чужой (хоть и очень миниатюрный картридер), а свои компоненты, можно купить любой из контроллеров с SD USB интерфейсом на борту (например, какой нибудь из ST32F103), потратить время, реализовав там USB-mass storage (рассмотрен в примерах к STMовской USB библиотеке) и использовать его как однокристальный мост USB-2-SD для вашего роутера или любого другого аналогичного проекта.
Я этим заниматься не стал за неимением времени (хотя возможно когда-нибудь и соберусь), плюс несколько засомневался, что смогу своим решением занять на плате площадь меньшую или сравнимую с этим чужим картридером – без корпуса он стал настолько мелкий, что выглядел просто как один из небольших девелоперских модулей или каких-то экранированных компонентов (вид экрана создавали остатки USB-разъема, служащие упором для micro-SD). Что касается портов USB. Разумеется на помощь приходит любой китайский USB-хаб. Однако, как показала практика, в основном они выполнены на одной и той же микросхеме (AU6256) независимо от бренда, и имеют очень, очень неприятную особенность – потреблять 100 мА х 5В (пол ватта!) даже не будучи никак задействованными. Это, честно говоря, меня несколько напрягло – вы втыкаете пустой хаб в USB-порт и он начинает потреблять больше чем сам роутер.
Существуют аналогичные микросхемы от всеми любимых Texas Instruments – вот такая, напрмер (TUSB2046B), в даташите которой заявлено потребление 40 мА – опять таки, пока не дошли руки проверить ее, но я склонен верить TI больше, чем китайцам.
Переходим к пункту 3.
Малый объем RAM
На этот счет можно озвучить две новости. Хорошая – то что RAM безболезненно можно заменить на совместимую микросхему в 64 мегабайта, коих, вероятнее всего, для подавляющего большинства экспериментов более чем хватит. Для этого не нужна перешивка, не нужно патчить загрузчики и ядра. Об этом подробно написано тут
Плохая новость – все подобные решения – и вышеозначенные роутеры, и их большие собратья от ASUS (такие как WL-500), и девелоперская Карамбола построены на древнейших DDR1-микросхемах, и найти совместимую с ними 64-мегабайтную сейчас уже большая проблема. Возможные источники указаны по ссылке выше – ими являются старые модули оперативной памяти (в основном, от разных ноутбуков) – но при гуглении чаще всего находятся не предложения о продаже, а мольбы на барахолках от таких же электронщиков, которые слово в слово перечисляют этот список и просят откликнуться обладателей хоть одной такой планки, на удивление окружающему народу.
Это, кстати, одна из причин, по которой мне бы очень хотелось увидеть аналогичное решение на каких-нибудь современных чипах, скажем, SITARA, от Texas Instruments – это современные, легкодоступные процессоры с ядром ARM, на которые давно портирован линукс. К ним прилагаются апноуты с типовыми схемами дев-боардов, SDK, и прочие плюшки, кроме того они работают с DDR3. Однако разработка подобной платы требует большого количества времени и достаточно солидных инвестиций (ЛУТ не поможет, нужны многослойные), так что я этим пока не решаюсь заняться, тем более что конкретной задачи пока не стоит. Возможно, кто-то этим уже занимается/планирует заняться – можно было бы скооперироваться – цель – сделать минимальный одноплатный компьютер, аналогичный Карамболе – без накручивания лишнего железа, как стартовую платформу для разработчиков на замену таким вот «роутерным» решениям.
Но вернемся к нашим роутерам. Закончив обзор железа, приступаем непосредственно к конфигурированию и пересборкам.
Пересобираем ядро
Сразу озвучу задачи. Чего я хотел достичь, пересобирая ядро?
- Так как OpenWRT легко позволяет подгрузить из репозитория все необходимое, включая модули ядра, я счел излишним вбилдивать в свою сборку то, что не требуется для старта системы.
- Во избежание лишних проблем с путями и прочих недоразумений всю корневую ФС я решил перенести на флешку, а не просто подмонтировать ее как дополнительный диск. Это решает все возможные проблемы «не нахождения» пакетами каких-либо библиотек из-за установки их в неположенную локацию и делает использование роутера более удобным, на мой взгляд. Из этого вытекают требования к вбилденным в ядро модулям – поддержка usb, файловой системы ext4, внешнего диска
- Мелкие преднастройки роутера – раздражает, когда после перепрошивки приходится начинать все заново, поэтому некоторые конфиги можно поправить уже на уровне ФС в прошивке, чтобы не заниматься этим каждый раз – например, для меня намного удобнее чтобы по умолчанию MR3020 сразу после перепрошивки выступал бы DHCP-клиентом, получая IP и становясь частью моей сети, а не пытался бы изображать из себя сервера, пиная мой настоящий роутер – упрощает процесс разработки/отладки, не нужно перетыкаться каждый раз, выбирая между «есть интернет» и «есть связь с MR3020»
Сам процесс пересборки отлично описан тут, рекомендую читать до просветления, так как, опять же, не будем по сто раз переписывать «введите команду make menuconfig сконфигурировать ваше ядро».
Предполагаю, что на момент чтения этого абзаца вы уже выполнили все описанные в статье пункты до, собственно, menuconfig, и даже попробовали собрать ядро, убедившись, что все работает. У меня это, в принципе, получилось с первого раза, значит у вас не должно вызвать проблем – все шаги довольно прозрачны. Единственное что отмечу – в случае каких-то проблем, как ни странно, помогает сделать make dirclean, что вычищает не только то, что вы набилдили, но и то, что набилдила сама система – то есть собранные тулчейны и прочее.
Если и это не помогает, то стоит попробовать сделать make distclean – это вычищает вообще все, включая то, что было докачено системой. После этого весь билд будет идти с самого начала, очень, очень долго, но есть шанс что проблем больше не возникнет. Не делайте этого без особой необходимости, если не хотите ждать несколько часов, пока все соберется.
Не забываем зайти в menuconfig, выбрать правильный таргет и таргет профиль (Atheros AR7xxx/AR9xxx, TP-Link TL-MR3020), после чего сохраниться, и сказать make defconfig, что заполнит наш конфиг дефлотными для MR3020 значениями.
Выполнив make menuconfig я снес из билда почти все, включая iptables и иже с ними – во-первых, потому, что это больше не роутер, а во вторых, потому что это все легко можно доставить потом. Поэтому проходим по менюшкам и сносим все, что нам не нужно.
Я оставил следующее:
- В Base System смотрим чтобы обязательно был вбилден block-mount, что необходимо для подключения дисков, из того что по умолчанию остается base-files, busybox, dnsmasq, dropbear, hotplug2 (его точно не забывайте, если не хотите остаться без нотификаций о подключении usb и нажатий на кнопки), mtd, opkg, uci
- В Kernel Modules заходим в раздел Filesystems и активируем там kmod-fs-ext4.
Если есть желание, можно выбрать какую-нибудь другую систему, но и одной ext4 вполне хватит. Все остальные кернел модули у меня не установлены, за исключением присутствующих по дефолту нескольких пунктах из LED-modules (если их убрать, понятное дело, роутер не станет моргать своими светодиодами и вы даже не узнаете как прошел процесс загрузки), модуля из Other Modules по имени kmod-gpio-button-hotplug, дающего нотификации при нажатии на кнопки роутера (у него есть одна кнопка и один трехпозиционный рычажок, также считающийся линуксом за две кнопки), дефолтного kmod-wdt-ath79 там же, очень важных нам kmod-usb-ochi, kmod-usb-storage-extras, kmod-usb-uchi, kmod-usb2 из USB Support и драйвера на встроенный вайфай – kmod-ath9k из Wireless Drivers.
Все остальное было отключено, либо скомпилено в виде модулей для последующей установки.
На данном этапе не помешает сбилдить ваше ядро, после чего прошить его, следуя инструкциям из вики по OpenWRT:
cd /tmp wget адрес-ресурса-куда-вы-выложили-свое-ядро.bin mtd write ваше-ядро.bin reboot Если после этого роутер загрузился успешно – обращаем внимение на MOTD (message of the day, приглашение после логина) – там должен измениться номер билда – поздравляю, вы успешно собрали свое ядро и перешили систему. Если роутер отказывается грузиться – не беда, положение можно спасти при помощи умного бутлодера, который вы, к счастью, не трогали – опять таки следуем инструкциям с вики (понадобится usb – rs232 переходник).
Теперь перейдем к конфигам. Логично предположить, что ФС вбилдена в образ, прошиваемый во флеш, и лежит где-то среди исходников OpenWRT. Это так, вы можете найти свою FS по пути
openwrt/trunk/build_dir/target-mips_r2_uClibc-0.9.33.2/root-ar71xx
(в дальнейшем все пути буду писать так, как представлены на моем компьютере, openwrt – директория в которую был сделан чекаут исходников)
Здесь вы можете править все что угодно и не бояться сильно испортить свою билд-систему, потому что эта директория генерится заново при каждом билде. Поэтому сначала конфигурим ядро, собираем его, а дальше – вносим сюда правки, и добилдиваем нужные модули отдельно, без ребилда ядра. Если что-то испортили, то просто заново делаем make, и директория будет восстановлена. Чтобы вбилдить ее образ из openwrt/trunk отдаем команду make target/install
Есть, однако, более фундаментальный способ – редактировать содержимое директории /openwrt/trunk/package/base-files/files – там лежат так называемые «скелеты» для генерирования целевой FS, которые не затираются при ребилде ядра. Но, в отличие от способа, описанного выше, там нельзя найти полный образ ФС, в том виде, в каком он будет на целевой машине и легко что-нибудь необратимо испортить, поэтому туда я особо не лазил.
В общем, на данном этапе можно приступать к настройке образа. И первое, что мы сделаем – отредактируем конфиг /etc/config/fstab так, чтобы при старте система воспринимала флешку как корень.
Небольшая справка: делается это через overlayfs, суть которого в том, что в прозрачном для пользователя режиме ему подсовывают содержимое нескольких файловых систем. Для чего это нужно? Ну например, это изначально задействовано в OpenWRT, даже если вы не хотите использовать флешку – файловая система там SquashFS, занимающая мало места, но read-only. Чтобы у пользователя была возможность редактировать файлы (и при этом все, что не редактировалось оставалось в удобной SquashFS) используется этот самый оверлей. Две ФС как бы сливаются в одну, и, в общем, данные берутся из SquashFS, но как только пользователь редактирует какой-то файл, в разделе, доступном для чтения и записи (по умолчанию там JFFS) создается его копия. Когда система, реализующая эти оверлеи, видит доступный файл с тем же именем в, собственно, оверлейной JFFS, она уже подсовывает пользователю именно его, при этом оставляя все остальные файлы по-прежнему из SquashFS.
Таким образом, что бы мы ни меняли в роутере, стоит отключить оверлеи и мы получим нашу рид-онли ФС в первозданном виде, что и юзается для режима восстановления роутера (в который я как-то ни разу не попадал, хотя один раз пытался).
Кстати, по этой же причине попытки снести какие-либо из пакетов, присутствующих в прошивке приведут к *уменьшению* свободного места – так как пакеты останутся там же, где и были, плюс создастся оверлейная копия файлов настроек и прочих вещей, затронутых удалением.
Мы же используем тот же трюк, но уже для файловой системы с флешки – на флеше будет полная копия нашей ФС, которую мы подготовим заранее, как только закончим все настройки. При загрузке она будет размещена оверлеем поверх встроенной файловой системы, и все изменения будут происходить исключительно на флешке. При этом если перед загрузкой флешку извлечь, роутер спокойно загрузится (со своей чистой фс, той самой, которую мы сейчас редактируем в образе), не забыв сообщить о том, что примонтировать указанный оверлей не удалось.
И так, форматируем флешку в ext4, создаем там два раздела – я создал один под своп (первый), второй под корневую ФС. При желании можно сделать отдельный раздел для /home или еще что, но мне хватило и такого. Теперь в упомянутом /etc/config/fstab (полный путь к которому openwrt/trunk/build_dir/target-mips_r2_uClibc-0.9.33.2/root-ar71xx/etc/config/fstab) пишем следующее:
config mount option target / option device /dev/sda2 option fstype ext4 option options rw,sync option enabled 1 option is_rootfs 1 config swap option device /dev/sda1 option enabled 1 Этим мы сообщаем, что нам нужно примонтировать оверлейную корневую систему в /dev/sda2 (за это отвечает опция is_rootfs, которая говорит что это не просто маунт, а именно extroot) и своп в /dev/sda1
Все, основное сделано. Дальше конфигурим все по нашему усмотрению. Лично я почистил конфиги, так как они генерятся сразу в расчете на все платы, поэтому в любом из них мы увидим такое великолепие как огромные ифы вида
case $(ar71xx_board_name) in wzr-hp-ag300h) ar922x_disable_gpio_jtag $phyname ;; Можно безжалостно удалять все случаи из ифов, не относящиеся к нашей плате, то есть к MR3020. Кроме того, некоторые файлы конфигурации, такие как правила хотплага для ieee1394 или JTAGа, которых у нас физически нет, вообще не имеют смысла для данной платы и сгенерились точно так же, для совместимости этого всего с другими платформами – их тоже можно убить.
К тому же следует помнить – некоторые файлы в директории /etc/config будут сгенерированы системой UCI автоматически. Все это реализовано скриптами, лежащими в /lib – вы их сразу заметите. К ним относятся, например, ar71xx.sh и functions.sh, которые выполняют начальную конфигурацию и дергают остальные скрипты (в частности, как раз-таки детектят нашу плату и заполняют ту переменную, ar71xx_board_name). Так, например, файл /lib/wifi/mac80211.sh в самом конце содержит те самые строки, которые будут добавлены в файл /etc/config для вашего радио:
cat <<EOF config wifi-device radio$devidx option type mac80211 option channel ${channel} option macaddr $(cat /sys/class/ieee80211/${dev}/macaddress) option hwmode 11${mode_11n}${mode_band} $ht_capab # REMOVE THIS LINE TO ENABLE WIFI: option disabled 1 config wifi-iface option device radio$devidx option network lan option mode ap option ssid OpenWrt option encryption none EOF devidx=$(($devidx + 1)) done } Тут можно поправить название интерфейса, дефолтное имя точки, шифрование и т.п., после чего при первом старте содержимое /etc/config/wireless будет сгенерировано в соответствии с нашими правками.
После того, как все настройки завершены, нам необходимо сделать полную копию этой файловой системы на нашей флешке, с которой будем грузиться. При этом настоятельно рекомендую сделать такой финт: в /etc/banner расположен MOTD, выводящийся при логине по SSH/Telnet в систему. Его можно как угодно поменять (я убрал этот раздражающий рецепт коктейля, оставив только лого OpenWRT), но одну вещь с ним сделать обязательно стоит: после копирования ФС на флешку берем и дописываем в этот файл что-нибудь, так, чтобы он отличался от файла в openwrt/trunk/build_dir/target-mips_r2_uClibc-0.9.33.2/root-ar71xx/etc/config
Например, в строке меняем строку ATTITUDE ADJUSTMENT (Bleeding Edge, r33444) на ATTITUDE ADJUSTMENT (Bleeding Edge, r33444, USB Overlay)
Теперь, благодаря этой небольшой хитрости, мы сразу после логина сможем понять – сработал оверлей, или нет (например, если внезапно «отвалилась» флешка или весь хаб)
После этого со спокойной душой возвращаемся в корень наших исходников (openwrt/trunk) и говорим make target/install – это запустит процесс генерации итогового имейджа, который появится в папке /openwrt/trunk/bin/ar71xx и будет носить имя openwrt-ar71xx-generic-tl-mr3020-v1-squashfs-sysupgrade.bin
После прошиваем его уже известным методом, и, после загрузки (не забываем вставить флешку в роутер!) и логина через telnet видим долгожданное приветствие
ATTITUDE ADJUSTMENT (Bleeding Edge, r33444, USB Overlay)
Дополнительно удостовериться можно введя команду df. Не забываем задать пароль командой passwd, после чего получаем возможность работать по SSH вместо telnet. Кстати, не рекомендую использовать пустой пароль не только из соображений безопасности, но и потому, что некоторые утилиты (о которых речь пойдет ниже) даже при выбранной опции «запоминать пароль» считают что пустой пароль не достоин запоминания и продолжают постоянно раздражающе запрашивать его.
Инструментарий разработчика
В заключительной части статьи мы поговорим о том, ради чего это все, собственно, затевалось – о разработке под чудо-девайс. Рассмотрим инструментарий под Windows, т.к. из-под убунты я только компилю ядра и модули. Разумеется у нас остается возможность писать на С/С++, кросскомпиляя наш код как мы кросскомпиляли ядро, но это муторный и не самый удачный вариант – скорость разработки и поддерживаемость кода куда выше у языков типа Java, C# и разных скриптовых типа Python и Ruby. Явамашина под OpenWRT есть, но, согласно тестам igor_suhorukov она еле ползает. Правда, igor_suhorukov собрал под OpenWRT более легковесную phoneME машину, но у меня так и не дошли руки ее потестировать. Поэтому будем исходить из того, что нам доступно, а доступен нам целый ворох скриптовых языков – Python, Ruby, Lua, Perl
Я, честно говоря, совсем не любитель динамически типизированных языков и скриптов вообще, но из приведенного набора я решил выбрать именно питон – раз уж обращаться за помощью к темным силам, то пусть это будут самые известные и захватившие весь мир темные силы.
Заходим на роутер по SSH и устанавливаем нужные нам пакеты:
opkg update opkg install vsftpd python Это установит SFTP-сервер и, собственно, интерпретатор питона.
Далее, устанавливаем на свою девелоперскую машину WinSCP бесплатную утилиту, которая позволит нам легко лазить по файловой системе роутера и обмениваться с ним файлами. Создадим новую конфигурацию в WinSCP: в поле Host Name задаем IP-адрес либо сетевое имя нашего роутера, порт оставляем по умолчанию, вводим имя пользователя и пароль, протокол выбираем SFTP.
Нажимаем «Login» и получаем полный доступ к ФС роутера – это ускорит процесс редактирования конфигов и т.п., если такая необходимость возникнет.
Теперь скачиваем и устанавливаем великолепную IDE от известной фирмы JetBrains – PyCharm. Следим за тем, чтобы версия была не ниже 2.6 – в прошлых есть баг, из-за которого удаленная отладка не срабатывала.
Заходим в File – Settings – Deployment, нажимаем на плюсик над списком для добавления нового деплоймент сервера. В появившемся окне вводим имя, например, MR3020 и выбираем протокол SFTP.
Далее конфигурируем деплоймент сервер: на вкладке Connection указываем адрес нашего роутера в поле SFTP Host, поля Port и Root Path оставляем по умолчанию.
Ввводим имя пользователя и пароль в соответствующие поля, ставим галочку «Save Password», чтобы нас не запрашивали при каждом деплое. После можно нажать «Test SFTP connection», чтобы убедиться, что все прошло нормально.
Заходим через WinSCP или SSH на наш роутер и создаем где-нибудь где удобно, например, в /root, директорию pyHelpers – сюда будут скопированы вспомогательные скрипты IDE.
Заходим в File – Settings – Project Interpreter – Python Interpreters и нажимаем на плюсик справа, выбирая в выпадающем после этого меню «Remote…». В появившемся окне нажимаем на ссылку «Fill from deployment settings», и выбираем настроенный ранее деплоймент сервер по имени MR3020. В полях «Python interpreter path» и «Copy PyCharm helpers to» указываем путь к бинарнику питона на роутере (по умолчанию правильный, /usr/bin/python) и путь к созданной нами директории для хелперов — /root/PyHelpers
После нажатия «OK» откидываемся на спинку стула и ждем, пока IDE не пообщается с интерпретатором на роутере и не построит список его возможностей и библиотек при помощи своих хелперов.
Дальше идет самое интересное: когда мы хотим начать разработку под наш роутер, мы создаем новый проект, выбирая в качестве интерпретатора наш настроенный Remote Python. Далее заходим в File – Settings – Deployment на вкладку Mappings и выбираем путь к нашему проекту на роутере, в поле Deployment Path on server ‘MR3020’. Не забываем нажать «Use this as default server».
В меню Tools – Deployment – Options устанавливаем удобный для нас режим деплоймента в поле «Upload changed files automatically to default server» – для меня это «On explicit save action» — теперь при нажатии CTRL+C измененные файлы будут автоматически аплодится на роутер.
Теперь можно добавить первый файл в проект и написать там долгожданную строку print “Hello World”. Сохраняем файл, и видим как IDE в консоли снизу рапортует об удачном аплоаде файла на сервер. Далее жмем правой кнопкой на имя файла в дереве проекта и выбираем «Run» — это автоматом создаст конфигурацию для запуска. Если что-то не так, и программа не запустилась, заходим в Run – Edit Configurations и проверяем, чтобы в поле Script был прописан путь к скрипту на роутере. Результат выполнения программы будет выведен в консоль внизу экрана.
Заключение
Вот, собственно, и все. Теперь у нас есть мощная современная IDE, позволяющая писать на питоне на своей девелоперской машине, автоматически загружая скрипты на целевую платформу (роутер), исполняя их там, и выводя результат в консоль IDE. А также позволяющая проводить их отладку и трассировку. За счет исключения из процесса шагов «написал, скомпилил, перебросил на роутер, зашел на роутер, запустил, поглядел, не заработало, вернулся к девелоперской машине» скорость разработки вырастает во много раз, а переносимость питоновских скриптов гарантирует, что большая часть ваших задач уже была в том или ином виде кем-то решена и оформлена в виде библиотек – достаточно только погуглить.
Так, например, при разработке проекта на работе к роутеру был легко прикручен GPS за счет библиотеки PyNMEA.
MR3020 станет отличным «мозгом» для ваших роботов или систем домашней автоматизации, особенно, если комбинировать его возможности с реал-тайм обработкой на тех же STM32 – в этом случае, мелкие кортексы М3 будут служить аппаратными контроллерами низкоуровневых систем, отдавая по USB информацию и получая команды от роутера, более тяжеловесная часть алгоритмов которого будет написана на удобном питоне. Например, в случае с роботами, STM32-контроллер превосходно служит контроллером сервоприводов, генерируя ШИМ-сигнал, а также собирает информацию с различных датчиков, собирает ее в пакет и шлет роутеру, в то время как питоновские скрипты реализуют уже более высокоуровневое «поведение».
Удачных разработок!
ссылка на оригинал статьи http://habrahabr.ru/post/158127/
Добавить комментарий