Идеи и возможности разработки электроники в России31.05.2014 05:03

Иногда мне приходят в голову интересные идеи о том, разработкой какого устройства можно было бы заняться, если бы нашёлся заказчик и потребитель. Иногда — это примерно раз в час. Эти идеи не дают мне спать, не дают работать. Я прикладываю нечеловеческие усилия, чтобы остаться в рамках задач, по которым заключены контракты. Я использовал разные способы, чтобы отвлечься от этих идей: рассказывал их самому большому критику из тех, что я знаю; заставлял себя детально просчитывать стоимость реализации каждой новой идеи, клал под подушку старые MCS51-ые…, но ничего не помогает.И вот я хочу опробовать очередной способ: рассказать о своих идеях и мыслях на Хабре.

Привет Хабр!

Теперь мы можем намного больше! Хорошая новость! Теперь мы можем в России производить печатные платы 5-го класса точности. Почему это так важно? Потому что, если вы хотите сделать что-то новое, интересное и современное, то без 5-го класса точности вам никак не обойтись. Почти любая BGA-микросхема требует платы 5-го класса точности. Сотовые телефоны, планшеты, SSD-диски, электронные читалки — все эти устройства содержат, например, микросхемы массового хранения данных (Mass Storage). Сейчас на рынке имеются два типа микросхем этого назначения — NAND и eMMC. NAND очень сложен в применении и даже опасен в случае плохо написанного обслуживающего софта, зато eMMC — это просто SD-карта в BGA корпусе. Т.ч. NAND«ы сейчас можно увидеть разве что в дешевых китайских планшетах и видеорегистраторах.

Именно возможности наших отечественных производителей ПП долгое время затрудняли использование BGA микросхем в России.

Оперативная память — оно нам надо? Действительно, а зачем нам оперативная память? Почему бы не хранить все данные (в том числе и запущенные процессы) в энергонезависимой памяти? Как было бы удобно: пропало питание — процессор остановился, появилось питание — процессор продолжил исполнять задачи дальше с той самой инструкции, на которой остановился. Мгновенный Hibernate/Wakeup! Сколько бы проблем сразу исчезло. Например, журналирование файловых систем во многих задачах стало бы просто не нужным!

Конечно же нас останавливает скорость работы всех доступных методов энергонезависимого хранения данных. Однако есть хорошая новость: уже более десяти лет разрабатывается магниторезистивная память. Скорость и количество циклов перезаписи — как у оперативной, независимость от внешнего питания — как у NVM. Не так давно в продаже появились образцы этой памяти, позволяющие собрать массив в 8–16 МБайт. Это даёт возможность уже сейчас развернуть в этой памяти Линукс и начать работу над его адаптацией к новым условиям, чтобы к тому моменту, когда магниторезистивная память в цене сравняется с обычной оперативной, быть на коне и при оружии. И уже сейчас можно начать применять эту технологию в тех задачах, где не требуется графический интерфейс (например, роутер с вечноживущим Linux«ом на борту смотрится очень даже неплохо).

Ruby в каждый чип «Уже пол-шестого утра… Ты знаешь, где сейчас твой указатель стека? «Автор неизвестен (обнаружено на Хабре)

«Писать на C или C++ — это как работать с бензопилой без какой-либо защиты.«Bob Gray. Писатель.

Как много времени тратят embedded-программисты на разработку кода на старом, неудобном и опасном Си. Но… опять хорошая новость! Matz выпустил mruby, который практически не имеет внешних зависимостей, написан на Си и легко встраивается куда угодно. Один японский фанат представил доклад на Ruby Conf 2012, в котором описал свой опыт встраивания интерпретатора этого замечательного языка программирования в среду с 1 МиБ памяти кода и 128 КиБ памяти данных! Процессоры с такими характеристиками стоят жалкие $3-$4 (при серийном производстве). При этом скорость и безопасность разработки увеличиваются в разы. Можно даже строить некое подобие операционных систем, т.к. Руби не имеет указателей и задача контроля доступа там решается сама собой (на уровне языка программирования!).

Многие считают, что Embedded и интерпретируемые высокоуровневые языки программирования — взаимоисключающие понятия. Но это не так! В качестве примера могу привести случай из собственной жизни. Мы разрабатывали умную «флешку». Помимо функций хранения данных устройство имело специальную логику, реализуемую заказчиком. Стек USB и его профиль — Mass Storage — реализовывали сами. Перед сдачей мы много раз проверяли скорости чтения и записи, и оптимизировали процессы. В итоге добились 14 МиБ/сек на чтение raw-данных и 10-ти — на запись. Для тех, кто не очень ориентируется, скажу, что это почти предел того, что можно реализовать на USB 2.0 Highspeed не применяя ASIC. Когда проект был сдан и заказчик начал разрабатывать свою логику для устройства, выяснилось, что скорость шифрования (это было СЗИ) очень низкая. Мы долго пытались выяснить в чем же дело, пока не обнаружили, что забыли выкрутить частоту процессора на максимум: он работал на частоте 60 МГц, вместо положенных 180-ти и это не сказывалось на скоростях чтения/записи. Почему это происходит? Да потому, что 95% кода стандартной прошивки для грамотно спроектированного исполнительного устройства — это как правило администраторские работы: настройка регистров, выдача команд на старт процедур, обработка ошибок и т.д. Все поточные операции должны выполнять (в идеале) специализированные модули. Процессор не должен заниматься неинтеллектуальной работой — он должен организовывать процесс, а «забивать гвозди» должен неинтеллектуальный модуль, который ничего не умеет кроме своей специальной работы, но выполняет эту работу с максимальной скоростью и, что самое главное, параллельно всем другим процессам в чипе! Так вот производительность этих-то организационных процессов — некритичный параметр. Если даже они вдруг станут выполняться в 10 раз медленнее, на общей скорости работы устройства это вряд ли скажется. Но именно эта организационная деятельность является самым сложнопроектируемым узлом, именно на неё уходит большая часть кода. Так почему же не быть этому коду интерпретируемым ради ускорения разработки и заботы о нервах разработчика?

Мы сейчас как раз проводим исследования в данной области и, если по комментариям поймём, что это интересно не нам одним — опубликуем результаты. Встраиваем mruby мы в NXP LPC18xx.

Швейцарская флешка системного администратора С тех пор, как мы выполнили свой первый проект, в котором необходимо было разработать флешко-подобное устройство, меня не отпускает мысль о том, что многим могла бы пригодиться флешка с большим количеством нестандартных функций. Вот некоторые из этих функций:

Конфигурируемое количество LUN«ов. LUN«ы — это логические разделы устройства на уровне Mass Storage драйвера. Для конечного пользователя LUN«ы выглядят как самостоятельные физические диски. Например, несколько LUN«ов обычно имеют кард-ридеры: по одному LUN«у на слот. Для каждого LUN«а можно предусмотреть задание типа носителя: обычный жесткий диск, CD, removable/non removable и т.д. Для каждого диска можно предусмотреть задание режима доступа: RW/R. Это всё удобно, например, когда какая-то старая программа хочет работать только при вставленном CD с нужным серийным номером. Вы можете разбить нашу швейцарскую флешку на два LUN«а: один — под этот CD, второй — обычный извлекаемый носитель. RAID режимы. На устройстве можно разместить не одну, а несколько микросхем памяти и реализовать RAID0/1 режимы. Причём можно сделать так, что один LUN будет RAID0, второй — RAID1, третий — обычная «флешка», а четвертый — вообще CD… Нестандартные интерфейсы. Иногда системному администратору приходится брать в руки… USB-Floppy. А почему бы не брать ему в руки флешку, которая умеет маскироваться под дискету? Программируемые кнопки и дисплей. Было бы удобно иметь несколько профилей работы и иметь возможность быстро переключаться между ними. Для этого можно предусмотреть несколько кнопок на корпусе и дисплей для отображения текущего профиля. В добавок кнопки можно сделать полностью программируемыми: например, назначить на одну из комбинаций кнопок полное уничтожение данных на устройстве. Ну вы поняли о применении в какой области я говорю… USB 3.0 и >100 МиБ/сек на чтение. Не столько уже особенность, сколько просто требование времени. Работа в качестве открывашки пивных пробок. А что, разве системному администратору не нужна такая функция? К сожалению на разработку этого устройства такой команде как мы надо потратить около полугода. И это притом, что у нас уже богатый опыт разработки устройств такого класса. Без инвестиций это невозможно сделать, а инвесторы что-то не находят в этой идее ничего интересного. Но если кто-нибудь реализует эту идею — я буду только рад, для того о ней и пишу здесь.

Видеорегистратор высокой четкости Вам нравится качество картинки вашего автомобильного видео регистратора? Мне — нет. Я видел много видеорегистраторов (в том числе и изнутри) и все они обладают одним существенным недостатком: из-за применения алгоритмов сжатия с потерями при определенных условиях (в сумерки или при тряске) на экране невозможно рассмотреть даже номер автомобиля, находящегося в 10–15 метрах. А ведь это одно из важнейших назначений видеорегистратора: записать номер автомобиля или лицо/приметы человека, участвовавшего в ДТ или ином происшествии. Почему так происходит?

Дело в том, что видеорегистраторам приходится писать данные на медленные sd-карты и потому так сильно сжимать видеопоток, что часто уже не важно, на сколько у вас «мегапикселей» камера, какой у неё угол обзора и т.д. Видно только общий ход событий, но совершенно не видно деталей. Зато вы можете хранить на карте 8 часов ваших поездок с дома на работу и с работы домой… А почему бы не отказаться от длительности записи в пользу качества? Почему бы не писать в оперативную память?

Возьмем 8 ГиБ оперативной памяти. Какой продолжительности видео разрешением 720×480 можно записать в оперативную память такого объема? 3 байта на пиксель x 720×480×25 кадров в секунду = 26 МиБ/сек. Более 5 минут кристально чистой картинки. Вы часто встречали ДТП, история развития которого начиналась ранее, чем за 3 минуты, а развитие которого занимало бы более чем 1 минуту? А уже после того, как ДТП произошло, можно снимать ещё, например, минуту, а потом перенести все на eMMC или SD-карту.

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

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

Так и не придумал, в какие хабы добавить свой пост. Был бы хаб «Разработка железа» — добавил бы туда, «Программирование микроконтроллеров» — несколько не то (хотя аудитория почти та, что надо), «DIY или сделай сам» — совсем не то. Буду благодарен подсказке.

______________________