Аппаратное обеспечение RepRap. Часть 1. 8 бит хватит всем.

Мне периодически задают вопросы по 'малинкам', 'апельсинкам' и тому, куда это вообще и зачем. И тут я начинаю понимать, что перед тем, как писать 'узкие' инструкции по настройке, неплохо было бы вкратце рассказать о том, как эта кухня вообще работает, снизу вверх и слева направо. Лучше поздно, чем никогда, поэтому вашему вниманию предлагается некое подобие ликбеза по ардуинам, рампсам и другим страшным словам. Изначально я думал, что уложусь буквально в одну статью, максимум в две. Но, боюсь, это это слишком оптимистично. Так что, часть первая - про восьмибитные микроконтроллеры Atmel с архитектурой AVR, применительно к 3D-печати.

Тому, что у нас сейчас есть возможность за разумные деньги купить или собрать собственный FDM-принтер, мы обязаны движению RepRap. Не буду сейчас о его истории и идеологии - нам сейчас важно то, что именно в рамках RepRap сформировался определенный 'джентльменский набор' железа и софта.

Чтобы не повторяться, скажу один раз: в рамках данного материала я рассматриваю только 'обычные' FDM-принтеры, не уделяя внимания промышленным проприетарным монстрам, это совершенно отдельная вселенная со своими законами. Бытовые устройства с 'собственными' железом и софтом (а таких немало 'за бугром', да и до нас иногда добираются) тоже трогать не буду. Далее под 'принтером' я понимаю полностью или частично открытое устройство, 'уши' которого торчат из RepRap.

8 бит хватит всем

Исторически сложилось так, что 'мозг' большинства принтеров - это восьмибитный микроконтроллер от Atmel с архитектурой AVR, в частности, ATmega 2560. А в этом виноват другой монументальный проект - Arduino называется. Программная его составляющая в данном случае не интереса - Arduino-код более прост для понимания новичками (по сравнению с обычным C), но работает медленно, а ресурсы жрет как бесплатные. Поэтому, когда ардуинщики упираются в нехватку производительности, они или бросают затею, или потихоньку превращаются в эмбеддеров ('классических' разработчиков микроконтроллерных устройств). При этом, кстати, 'железо' Arduino бросать совершенно не обязательно - оно (в виде китайских клонов) дешевое и удобное, просто начинает рассматриваться не как Arduino, а как микроконтроллер с минимальной необходимой обвязкой. По факту, Arduino IDE используется как удобный в установке набор из компилятора и программатора, 'языком' Arduino в прошивках и не пахнет.

Но я немного отвлекся. Задача микроконтроллера - выдавать управляющие воздействия (осуществлять так называемый 'ногодрыг') в соответствии с получаемыми инструкциями и показаниями датчиков. Очень важный момент: данные маломощные микроконтроллеры обладают всеми типичными чертами компьютера - в маленьком чипе есть процессор, оперативная память, постоянная память (FLASH и EEPROM). Но если ПК работает под управлением операционной системы (и она уже 'разруливает' взаимодействие железа и многочисленных программ), то на 'меге' у нас крутится ровно одна программа, работающая с железом напрямую. Это принципиально.

Часто можно услышать вопрос, почему не делают контроллеры 3D-принтеров на основе микрокомпьютера вроде того же Raspberry Pi. Казалось бы, вычислительной мощности вагон, можно сразу сделать и веб-интерфейс, и кучу удобных плюшек… Но! Тут мы вторгаемся в страшную область систем реального времени.

Википедия дает следующее определение: 'Система, которая должна реагировать на события во внешней по отношению к системе среде или воздействовать на среду в рамках требуемых временных ограничений'. Если совсем на пальцах: когда программа работает 'на железе' непосредственно, программист полностью контролирует процесс и может быть уверен, что заложенные действия произойдут в нужной последовательности, и что на десятом повторении между ними не вклинится какое-то другое. А когда мы имеем дело с операционной системой, то она решает, когда исполнять пользовательскую программу, а когда отвлечься на работу с сетевым адаптером или экраном. Повлиять на работу ОС, конечно, можно. Но предсказуемую работу с требуемой точностью можно получить не в Windows, и не в Debian Linux (на вариациях которой в основном работают микро-пк), а в так называемой ОСРВ (операционная система реального времени, RTOS), изначально разработанной (или доработанной) для данных задач. Применение RTOS в RepRap на сегодняшний день - жуткая экзотика. А вот если заглянуть к разработчикам станков с ЧПУ, там уже нормальное явление. Для примера - плата не на AVR, а на 32-битном NXP LPC1768. Smoothieboard называется. Мощи - уйма, функций - тоже.

А дело все в том, что на данном этапе развития RepRap, '8 бит хватит всем'. Да, 8 бит, 16 МГц, 256 килобайт флеш-памяти и 8 килобайт оперативной. Если не всем, то очень многим. А тем, кому недостаточно (это бывает, например, при работе с микрошагом 1/32 и с графическим дисплеем, а также с дельта-принтерами, у которых относительно сложная математика расчета перемещений), в качестве решения предлагаются более продвинутые микроконтроллеры. Другая архитектура, больше памяти, больше вычислительной мощности. И софт все равно в основном работает 'на железе', хотя, некоторые заигрывания с RTOS маячат на горизонте.