- PVSM.RU - https://www.pvsm.ru -
Иногда мне приходят в голову интересные идеи о том, разработкой какого устройства можно было бы заняться, если бы нашёлся заказчик и потребитель. Иногда — это примерно раз в час. Эти идеи не дают мне спать, не дают работать. Я прикладываю нечеловеческие усилия, чтобы остаться в рамках задач, по которым заключены контракты. Я использовал разные способы, чтобы отвлечься от этих идей: рассказывал их самому большому критику из тех, что я знаю; заставлял себя детально просчитывать стоимость реализации каждой новой идеи, клал под подушку старые MCS51-ые…, но ничего не помогает.
И вот я хочу опробовать очередной способ: рассказать о своих идеях и мыслях на Хабре.
Привет!
Хорошая новость! Теперь мы можем в России производить печатные платы 5-го класса точности. Почему это так важно? Потому что, если вы хотите сделать что-то новое, интересное и современное, то без 5-го класса точности вам никак не обойтись. Почти любая BGA-микросхема требует платы 5-го класса точности. Сотовые телефоны, планшеты, SSD-диски, электронные читалки — все эти устройства содержат, например, микросхемы массового хранения данных (Mass Storage). Сейчас на рынке имеются два типа микросхем этого назначения — NAND и eMMC. NAND очень сложен в применении и даже опасен в случае плохо написанного обслуживающего софта, зато eMMC — это просто SD-карта в BGA корпусе. Т.ч. NAND’ы сейчас можно увидеть разве что в дешевых китайских планшетах и видеорегистраторах.
Именно возможности наших отечественных производителей ПП долгое время затрудняли использование BGA микросхем в России.
Действительно, а зачем нам оперативная память? Почему бы не хранить все данные (в том числе и запущенные процессы) в энергонезависимой памяти? Как было бы удобно: пропало питание — процессор остановился, появилось питание — процессор продолжил исполнять задачи дальше с той самой инструкции, на которой остановился. Мгновенный Hibernate/Wakeup! Сколько бы проблем сразу исчезло. Например, журналирование файловых систем во многих задачах стало бы просто не нужным!
Конечно же нас останавливает скорость работы всех доступных методов энергонезависимого хранения данных. Однако есть хорошая новость: уже более десяти лет разрабатывается магниторезистивная память. Скорость и количество циклов перезаписи — как у оперативной, независимость от внешнего питания — как у NVM. Не так давно в продаже появились образцы этой памяти, позволяющие собрать массив в 8–16 МБайт. Это даёт возможность уже сейчас развернуть в этой памяти Линукс и начать работу над его адаптацией к новым условиям, чтобы к тому моменту, когда магниторезистивная память в цене сравняется с обычной оперативной, быть на коне и при оружии. И уже сейчас можно начать применять эту технологию в тех задачах, где не требуется графический интерфейс (например, роутер с вечноживущим Linux’ом на борту смотрится очень даже неплохо).
«Уже пол-шестого утра… Ты знаешь, где сейчас твой указатель стека?»
Автор неизвестен (обнаружено на Хабре)
«Писать на 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.
С тех пор, как мы выполнили свой первый проект, в котором необходимо было разработать флешко-подобное устройство, меня не отпускает мысль о том, что многим могла бы пригодиться флешка с большим количеством нестандартных функций. Вот некоторые из этих функций:
К сожалению на разработку этого устройства такой команде как мы надо потратить около полугода. И это притом, что у нас уже богатый опыт разработки устройств такого класса. Без инвестиций это невозможно сделать, а инвесторы что-то не находят в этой идее ничего интересного. Но если кто-нибудь реализует эту идею — я буду только рад, для того о ней и пишу здесь.
Вам нравится качество картинки вашего автомобильного видео регистратора? Мне — нет. Я видел много видеорегистраторов (в том числе и изнутри) и все они обладают одним существенным недостатком: из-за применения алгоритмов сжатия с потерями при определенных условиях (в сумерки или при тряске) на экране невозможно рассмотреть даже номер автомобиля, находящегося в 10–15 метрах. А ведь это одно из важнейших назначений видеорегистратора: записать номер автомобиля или лицо/приметы человека, участвовавшего в ДТ или ином происшествии. Почему так происходит?
Дело в том, что видеорегистраторам приходится писать данные на медленные sd-карты и потому так сильно сжимать видеопоток, что часто уже не важно, на сколько у вас «мегапикселей» камера, какой у неё угол обзора и т.д. Видно только общий ход событий, но совершенно не видно деталей. Зато вы можете хранить на карте 8 часов ваших поездок с дома на работу и с работы домой… А почему бы не отказаться от длительности записи в пользу качества? Почему бы не писать в оперативную память?
Возьмем 8 ГиБ оперативной памяти. Какой продолжительности видео разрешением 720×480 можно записать в оперативную память такого объема? 3 байта на пиксель x 720×480 x 25 кадров в секунду = 26 МиБ/сек. Более 5 минут кристально чистой картинки. Вы часто встречали ДТП, история развития которого начиналась ранее, чем за 3 минуты, а развитие которого занимало бы более чем 1 минуту? А уже после того, как ДТП произошло, можно снимать ещё, например, минуту, а потом перенести все на eMMC или SD-карту.
Что интересно — именно такой видеорегистратор вполне можно быстро разработать в России. Дело в том, что самая сложная часть всех видеорегистраторов — это аппаратные кодеки видео. Кодеки эти проприетарные и требуют покупки лицензии; с каждого проданного устройства вы должны платить отчисления, но даже не в этом самая большая трудность. Самая большая трудность заключается в том, что с разработчиками, не предоставившими гарантии миллионных тиражей своей продукции, просто не будут связываться…
Я очень кратко описал свои идеи. На самом деле из каждой из них можно сделать целый пост. Но где взять на это время? Так что, если у кого-нибудь возникнет интерес к одной из тем, затронутых в этом посте, я буду рад обсудить возникшие мысли в комментариях. Кроме того, было бы интересно услышать о том, что интересного может рассказать разработчик железа.
Так и не придумал, в какие хабы добавить свой пост. Был бы хаб «Разработка железа» — добавил бы туда, «Программирование микроконтроллеров» — несколько не то (хотя аудитория почти та, что надо), «DIY или сделай сам» — совсем не то. Буду благодарен подсказке.
______________________
Автор: ALev
Источник [2]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/news/61124
Ссылки в тексте:
[1] Хабра Редакторе: http://www.softcoder.ru/habraeditor/
[2] Источник: http://habrahabr.ru/post/224749/
Нажмите здесь для печати.