Метка: программирование

Прочитал недавно известную книгу Ф. Брукса «Мифический человеко-месяц». А сегодня в комментариях у bitoniau увидел довольно распространенное мнение — мол, известная демоплата Arduino не нужна, можно собрать то же самое «ручками», то есть съездить в «Чип-и-Дейл», купить паяльник ватт на двести, припой — лучше всего ПОС-40, флюс — канифольку смрадную, текстолит гетинакс, хлорное железо, микроконтролер, горсточку бракованных деталей, набор тупых мелких сверл, затем загадить мерзким раствором пол-квартиры, взять паяльник за «не тот» конец, собрать программатор, плату с микроконтролером, потом поставить на компьютере AVRStudio, WinAVR и еще кучу всякой дряни, сжечь LPT-порт при прошивке — и все это только для того, чтобы поморгать диодиком. Мало кто сейчас следует книжке Борисова и тренируется «на кошках», то есть на выпаянных неизвестно откуда КТ315. А зря, ибо когда Борисов начинает рассказывать о цифровых микросхемах (и на этом, кстати, книжка уже почти заканчивается), «юный радиолюбитель» превращается в закоренелого паялу, а для такого запаять 24-ногое чудо враждебной техники — раз плюнуть.

Казалось бы, чего общего может быть у умещающегося в одном DIP-корпусе микроконтролера и огромной IBM System/360, занимавшей несколько шкафов и жравшей немерянное количество электроэнергии, и какое отношение книга Брукса может иметь к «единоличной» разработке программ для МК? Дело не в том, что микроконтролер близок по своим «ресурсам» к «суперкомпьютерам» прошлых лет (System/360 всяко покруче будет!). Просто в те времена еще не было замечательных линуксов, работающих на кофеварках, и программы писались на сравнительно низком (не плохом, а приближенном к «железу») уровне. А особенно верно это для операционной системы совершенно новой машины — основываясь на опыте разработки которой, Брукс и написал книгу.

Вот один только абзац:

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

Этот опыт, однако, сослужил плохую службу при программировании новой машины. Лабораторные разработки, предварительные или ранние выпуски компьютеров не работают должным образом, не работают надежно и не остаются неизменными день ото дня. <…> И хуже всего неопределенность, лишающая стимула копаться в своем коде в поисках ошибки — ее может там вовсе не быть.

Программирование для микроконтроллерных систем — в чистом виде системное программирование для «новой машины». Да, микроконтроллер — довольно хорошо изученная и документированная штука, но вот трудность вызывает сборка «первой схемы», особенно, если это схема на МК. Разве может начинающий знать, что керамический конденсатор необходимо разместить как можно ближе к корпусу микросхемы? А то, что блокировочные конденсаторы для пары микросхем вовсе не стоит заменять одним, пусть даже и с емкостью, равной суммарной? А нюансы, связанные с подключением кварца?

Непонятно, почему «светодиодная моргалка», собранная «по всем правилам», не хочет работать. Дело ли в программе, в прошивальщике, в программаторе, в схеме, в монтаже — начинающему не понять. А применительно к AVR — вспомним хотя бы о «фузах», неправильной установкой которых так легко угробить контроллер (купленный, естественно, в единственном экземпляре).

Современный программист привык к тому, что железо всегда работает нормально, именно поэтому многие, спаявшие простейшую схему на МК, так никогда и не находят «соплю» между ножками. Демоплаты как раз и решают проблему с «нестабильностью» собранного новичком в «паяльном деле» «железа». Как минимум, повышается шанс запустить первую программу на нормально работающем «железе».

Касательно Arduino — лично я не вижу ничего особо выдающегося в этой плате. Разве что какой-то набор функций (своего рода «ОС») и Bootloader — вот и все, чем эта штуковина отличается от других плат. Ну и пиар, соответственно.

Для разговора про ардуиновскую «стандартную библиотеку» хочу вновь обратиться к истории. Технологии и методы программирования развивались в тесной связи с развитием возможностей «железа». Та же Simula оказалась невостребованной в конце 60-х — для тогдашних компьютеров более естественными оказались «процедурные» языки. Приведу маленький пример.

Для не очень хорошего программиста на Java или любом другом подобном языке вполне естественно написать что-то вроде:

var s = new String();

for(var i = 0; i < 100; i++) String += i + ",";

Кое-кто может сослаться на историю маляра Шлёмы, но речь немного не об этом, тем более что класс String можно реализовать и без недостатков сишных строк. Если кто-то, подобно тому не очень хорошему программисту, не читал книжек по Java или другим языкам со "сборкой мусора", то предлагаю проследить, что же происходит в цикле. При каждой его итерации создается несколько экземпляров класса String, которые не уничтожаются сразу после окончания вычисления (как в C++), а остаются в памяти.

То, что мы не заботимся о явном выделении памяти и ее освобождении, и называется абстракцией. Нас не волнуют такие вещи, как стек, страницы памяти и прочие малопонятные вещи. Даже мусор за нами должен собрать "сборщик мусора" (кстати, тоже сделанный в Simula).

Естественно, что за возможность написать код, наподобие приведенного выше, надо чем-то расплачиваться - а именно, ресурсами выполняющей эту гадость машины. Комфорт программиста, не заботящегося о "смысле", скрытом за легко читаемой строчкой, оплачивается памятью, тактами процессора и прочими ныне почти забытыми понятиями. Именно поэтому Simula и оказалась не нужна в 60-х. А вот разработанный практически в те же годы C оказался гораздо интереснее для компьютеров с очень сильно ограниченной памятью, да и на тех же AVR широко используется.

Похоже, то, что avr-gcc умеет компилировать и объектно-ориентированный C++, послужило поводом реализовать "объектно-ориентированную" стандартную библиотеку Arduino. Хоть Страуструп и утверждает, что "никакое языковое средство не должно приводить к снижению производительности программ, не использующих его", но из этого совершенно не следует, что реализованные с использованием ООП и без оного аналогичные функции будут работать одинаково.

Зато кому-то стало легче - не надо изучать такой непонятный RS-232, достаточно лишь написать Serial.println(15 - 10) :) А потом начинаются пляски с бубном около ООП-шных изысков, реализованных на неподходящей для этого системе.

PS Я ни в коем случае не утверждаю, что объектно-ориентированное програмирование, преобразование типов и прочие замечательные особенности соременных языков программирования - это "аццтой". Они действительно облегчают жизнь. Сборка мусора - это гораздо лучше, чем ручное управление памятью, примерно настолько же, насколько современная автоматическая коробка передач превосходит ручную. Только вот не надо пытаться присобачить "автомат" к "Жигулям" (за ссылку спасибо onfall).

Очень здорово написано по поводу гуглокалькулятора:

Для проведения одной элементарной операции с целыми числами задействуется огромное число компьютеров: начинается всё на локальном ПК с браузером, выполняющим сотни тысяч арифметических операций (аналогичных по сложности исходной операции) для формирования http-запроса; дальше работают десятки маршрутизаторов, пересылающих пакеты, каждый из которых опять же выполняет сотни арифметических действий; пыхтит коммуникационное оборудование на более низких уровнях модели OSI, и это оборудование тоже много вычисляет, упаковывая пакеты в каналах, кодируя и декодируя данные; лишь потом приходит черёд серверов Google, которые запрашивают базы данных (потому что всё равно идёт поисковая выдача).

После того, как где-то в череде этих миллиардов выполненных арифметических операций несколько наносекунд машинного времени потрачено на определение ответа, начинается процесс доставки ответа обратно. А это опять – серверы, маршрутизаторы, каналы, браузер и вывод результата, всё расходует миллионами арифметические операции, каждая из которых могла бы дать ответ самостоятельно.

В общем, как-то не впечатляют заявления гугля о том, что через десяток лет все ПО будет работать на стороне сервера, а работать с ним будут через браузер.

PS Кстати, если уж на каком-то девайсе смог запуститься интернет-браузер, то уж несложные программы могут выполняться на нем? Могут, естественно. А уж о критериях «несложности» можно подумать и самим. Для провоцирования срача скажу, что на 286-м можно развернуть почти полноценный веб-сервер, например :) Да что там 286-й, люди на PIC и AVR такое сооружают, что знатоки DOM, XML, COM, и прочих трехбуквенных технологий нервно курят в сторонке.

На днях я мучился с USB-устройством на V-USB, и обзавелся прекрасным набором разных «мониторов» и «снифферов» USB-шины. Для чего можно применить такую коллекцию? Среди всякого хлама обнаружился адаптер для авиамодельных передатчиков под названием RC Joystick Pro версии 2.2 производства «фирмы» ED&IGL Hobbies.

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

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

PS Конечно, «вычислимый на МК способ» может оказаться весьма гнусным, например, XOR с трехбайтовой маской. В общем, попробую поперебирать простые варианты, типа перестановок байт/полубайт, а там видно будет. А может, единственный метод «хацкерской» разлочки — брутфорс, ведь проверочный код может быть прошит одновременно с серийным номером.

Развитие нынешней вычислительной техники идет по пути наращивания вычислительных возможностей в рамках существующей архитектуры – больше гигагерц тактовой частоты, больше операций в секунду, больше гигабайт памяти… Для чего нужны такие мощности применительно к «домашнему» персональному компьютеру? Для того, чтобы отрисовывать «окошки» Windows или просчитывать несложную логику в играх, вполне достаточно чего-нибудь наподобие первого «Пентиума», а то «четыреста восемьдесят шестого».

Будем считать, что все программы написаны «хорошо», никто не пытается производить сложные вычисления только по причине криворукости программиста (луч анального поноса посылается фирме Lotus). Тогда все задачи, требующие большого количества вычислений, разбиваются на две категории – «мультимедиа», то есть работа с графикой, видео, цифровым звуком, синтез 3D-графики и «действительно сложные задачи» — например, расчет индекса Доу-Джонса или цены на бананы в Гондурасе.

«Мультимедийные» задачи, можно сказать, естественны для домашнего компьютера. Конечно, я ни разу не сторонник той мысли, что домашний компьютер должен быть гибридом медиацентра и игровой приставки с выходом в Интернет, но возьмем это в качестве примера. Мало кто рассчитывает дома атомные бомбы, а вот посмотреть фильм или поиграть в Doom – милое дело. Давайте оценим сложность, к примеру, декодирования JPEG. Предположим, что все вычисления выполняются на обычном «универсальном» процессоре. Тогда достаточно оценить скорость выполнения двух наиболее сложных операций – «деквантизации», представляющей собой 64 умножения и обратного косинус-преобразования. Если косинус-преобразование ускорить тем же способом, что и в случае быстрого дискретного преобразования Фурье, то в конечном итоге для декодирования каждого блока 8×8 понадобится 106 мультипликативных и 42 аддитивных операции. Точно так же оценивается и количество операций при кодировании JPEG. Заметьте, что я намеренно считаю сложения и умножения «порознь» — умножение зачастую — гораздо более сложная операция, обычно занимающая намного больше тактов процессора.

Все широко используемые видеокодеки основаны на той же идее дискретного косинус-преобразования и «квантизации», поэтому оценки скорости этих операций дают нам представление о числе операций, необходимом для просмотра видео на компьютере. Понятно, что это – довольно требовательная к ресурсам задача. Например, на стоящем в моем ноутбуке Pentium M с частотой 1,7 ГГц просмотр DVD-фильма требует 30-50% процессорного времени. Стоимость «минимального» процессора, способного в реальном времени декодировать MPEG-2 (какой-нибудь Pentium III), получается довольно высокой (а если учитывать и «обвязку» в виде памяти и контролеров привода – очень и очень существенной). При этом кажется непонятным, почему китайский DVD-плеер может стоить менее 30$, а микросхема, используемая в нем в качестве процессора, стоит около 10$.

Дело в том, что совершенно необязательно считать «элементарными» операциями обычные арифметические операции. Если рассмотреть все то же косинус-преобразование с квантизацией как функцию, «входом» которой являются 512 бит (таблица 8×8 байт), и с теми же 512 битами на выходе, то можно составить ее таблицу значений. Можно составить, например, схему из функциональных элементов И, ИЛИ и НЕ, которая будет реализовывать эту функцию. Есть даже методы автоматического синтеза таких схем, например, асимптотически оптимальный (то есть строящий схему с довольно близким к минимальному числом элементов) метод Лупанова. Реализовав такую схему «в железе», например, как модуль процессора, получим возможность вычислить заданную функцию за один такт.

Конечно, пример выше – своего рода жульничество. Нам никто не разрешит использовать такое количество элементов, которое возникнет в рассмотренной выше схеме – ее сложность будет сопоставима с «полноценным» процессором. Практическая ценность его близка к нулю, и сравнима с таковой, например, у программы для машины Тьюринга или чего-нибудь Brainfuck-подобного. В реальности поступают проще. Достаточно легко, к примеру, реализовать любой конечный автомат. Кроме этого, можно разбить задачу на более простые операции с более простыми схемами. Таким образом можно упростить схему. При этом скорость ее работы все равно останется очень высокой. Например, сделанный «на скорую руку» JPEG-кодер на довольно простой и «медленной» ПЛИС фирмы Xilinx способен обработать в секунду порядка 3 мегапикселей (тактовая частота – всего 50 МГц), при этом он состоит примерно из 7000 элементов. Для сравнения, «универсальный» процессор Zilog Z80 состоял из 3500 элементов, но ни о каком JPEG-кодировании на нем речь даже не идет. Если же вместо ПЛИС использовать специально разработанную микросхему, то скорость повысится на порядок. JPEG-кодер (какой-нибудь Zoran COACH или Ambarella) в любом современном цифровом фотоаппарате-мыльнице способен за одну секунду обработать не менее 20-30 мегапикселей. Это сравнимо с производительностью Pentium IV, но на порядок выгоднее и с точки зрения стоимости (напрямую зависящей от числа элементов), и с точки зрения энергопотребления.

Все современные процессоры представляют собой, грубо говоря, калькуляторы. Конечно, и у них существуют инструкции, позволяющие быстро выполнять некоторые характерные для «мультимедиа» операции, например, набор инструкций MMX в процессорах персоналок. Тем не менее, крайне важно сохранить универсальность центрального процессора, не превращая его в начинку для фотоаппарата или DVD-плеера. Для таких вычислений, как матричные операции для 3D-графики или преобразование Фурье для кодирования графики, уже давно применяют и более специализированные процессоры – соответственно, видеоускорители или аппаратные MPEG-декодеры. Даже первые «Pentium», снабженные аппаратным декодером MPEG, были способны показывать фильмы с DVD или VideoCD. Стоит упомянуть и компьютеры Amiga, которые в начале 90-х были единственными «персоналками», способными обрабатывать видео – благодаря специализированным сопроцессорам. Тактовая же частота центрального процессора составляла всего лишь 14 МГц. Конечно, никто не запрещает использовать для тех же вычислений центральный процессор, но специализированные справятся с ними гораздо быстрее.

Собственно, использование сопроцессоров для некоторых сложных операций – давно не новость. Гораздо интереснее может выглядеть другая, менее очевидная вещь. Уже достаточно давно выпускаются ПЛИС – программируемые логические интегральные схемы, специальные микросхемы, состоящие из отдельных «кирпичиков», каждый из которых может быть элементом И, ИЛИ и НЕ. Связи между этими модулями задаются «прошивкой» микросхемы. Именно с использованием ПЛИС моделируются «заказные» микросхемы (тут передаю горячий привет corvus_bkgk). В зависимости от «прошивки» ПЛИС может реализовывать самые различные функции.

Удивительно, но до использования перепрограммируемых ПЛИС в персональном компьютере «дошли» только у нас в России. Многие «спектрумисты» слышали про «клон» ZX Spectrum под названием Sprinter. На самом деле Sprinter – в корне отличающийся от Spectrum компьютер, способный только эмулировать последний. Более того, Sprinter может имитировать поведение несовместимых между собой «клонов», и может работать в «своем» режиме, превосходящем по возможностям любой другой Spectrum или его клон. Это достигается путем использования в качестве системной логики в этом компьютере нескольких ПЛИС, «прошивка» которых может заменяться «на лету», во время работы компьютера.

Довольно «объемистая» ПЛИС может выполнять функции, например, видеоускорителя, или декодера MPEG, и даже сопроцессора для любых других операций, например, криптографических. Конечно, использование ПЛИС в «персоналках» потребовало бы специальных библиотек, наподобие DirectX, но могло бы дать немалый выигрыш в вычислительно сложных операциях.

Не буду говорить об общей «кривости» архитектуры современного PC, состоящей преимущественно из тяжелого наследия уродца фирмы IBM и ночного кошмара фирмы Intel, не буду издеваться над тем, что самые современные процессоры состоят в основном из «костылей и подпорок» ради совместимости с Intel 8086, но замечу, что сейчас увеличение параметров процессоров происходит с большим трудом. Тактовая частота уже не увеличивается, растет лишь количество процессорных ядер на одном кристалле. Боюсь, что привычные нам «пни» уже достигли предела в своем развитии. Вполне возможно, что уже в недалеком будущем появятся первые «реконфигурируемые» вычислительные модули.

Кстати, на ПЛИС можно эмулировать и «обычные» процессоры. Например, уже существует несколько Open Source (!) реализаций все того же Z80. Интересно, чем будут мериться школьники на форумах, когда «апгрейд» процессора превратится в простое «скачивание» новой прошивки из Интернета?