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

    Иногда мне приходят в голову интересные идеи о том, разработкой какого устройства можно было бы заняться, если бы нашёлся заказчик и потребитель. Иногда — это примерно раз в час. Эти идеи не дают мне спать, не дают работать. Я прикладываю нечеловеческие усилия, чтобы остаться в рамках задач, по которым заключены контракты. Я использовал разные способы, чтобы отвлечься от этих идей: рассказывал их самому большому критику из тех, что я знаю; заставлял себя детально просчитывать стоимость реализации каждой новой идеи, клал под подушку старые 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 метрах. А ведь это одно из важнейших назначений видеорегистратора: записать номер автомобиля или лицо/приметы человека, участвовавшего в ДТ или ином происшествии. Почему так происходит?

    Все видеорегистраторы сжимают видеопоток. Чтобы сжатие можно было производить на лету, используют аппаратные кодеки. Разработать даже по имеющемуся математическому алгоритму такой кодек — неимоверно сложная задача, посильная только колоссам электронной промышленности. Колоссы, как известно, видеорегистраторы не производят (кстати, интересно почему? знаю, что во многих странах car DVR не получили такого широкого применения как у нас и в китае). К счастью, есть несколько аппаратных платформ, выпускаемых дочками этих колоссов (или при их поддержке). Разработчики видеорегистраторов берут за основу такую программно-аппаратную платфорум, упаковывают в корпус (часто даже не переразводя плату!), конфигурируют, клеют свои шильдики и продают. Так, например, всем известный DOD F900LHD построен на широко известной в узких кругах платформе Yamaha с процессором Ambarella.

    Т.о., сами разработчики видеорегистраторов к разработке главной функции своего устройства непричастны и не могут подчас даже подправить конфигурацию кодека (не говоря уже о том, чтобы как-то серьёзно дорабатывать реализацию алгоритма). Они вынуждены пользоваться тем, что есть, другого выхода у них нет (если не отступать от принятой конструкции DVR’а). Ситуация усугубляется ещё и тем, что большинство производителей ориентируются на low-cost сегмент и потому намеренно не выкручивают качество на максимум — видеорегистратор станет не всеядным в отношении SD-карт. Кроме того, видео конфигурирование кодека подразумевает фокусировку на определённом параметре. Например, либо хорошо будет видно ночью, но картинка станет неестесственной, либо наоборот. И изменить эти параметры не всегда получается — как производитель кодека выставил, так обычно и работает. Я разговаривал с одним из участником рынка т.н. «российских» видеорегистраторов; мне попался достаточно энергичный человек, который не поленился вдолбить своим китайским поставщикам, что же он хочет, чтобы они поправили в настройках кодека. Те в свою очередь сделали запрос к разработчикам устройства, которые (видимо), обратившись к разработчикам базовой аппаратной платформы, выяснили, сколько может стоить простая правка конфигурации. Конечной суммой оказалось число в шесть нолей (не юаней). И это конфигурирование все равно не привело бы к прорыву, просто какая-то функция стала бы чуть лучше работать.

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

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

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

    Заключение



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

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

    ______________________
    Текст подготовлен в Хабра Редакторе от © SoftCoder.ru
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 85
    • –2
      Ruby — хорошо, JavaScript — лучше. Про остальное — ищите на eBay.
    • 0
      Подумываю над возможностью создания синтезатора (совсем другая история) в России, но сталкиваюсь со многими описанными проблемами, да и по хорошему бы надо платы заказывать, а не делать, да где денег взять… А так — я не эксперт, но идеи классные. Может кому и пригодится)
      • 0
        В каком смысле — платы «заказывать»? Заказывать разработку или производство? Если вы про производство, то тут вопросов нет — самому производить платы, все равно, что самому шить себе одежду и выращить все продукты питания: только этим и будешь заниматься и то плохо сделаешь.
        Если же речь шла о разработке, то в вашем случае, боюсь, это невозможно, т.к. зачем кому-то на заказ делать готовый продукт, если его можно продавать самому — уведут. Так можно заказывать только разработку плат, которые без софта бесполезны, а софт можно защитить битом RO в MCU.
        • 0
          Касательно проектирования вопроса не было — конечно же, половина плат уже была разработана и выложена, а вторая половина проектируется нами. Главное как разыло услышать про то, что с ними дальше делать. Пойду прицениваться, штоле.
      • +2
        Вот про mruby бы поподробнее…
      • 0
        Есть идея — делаете прототип, выходите на кикстартер, проверяете интерес к вашему продукту реальных потребителей. Если интерес есть — к вам инвесторы сами в очередь выстроятся. А если нет интереса — значит, не такая уж и хорошая была идея.
        • 0
          А дальше как? Когда интерес есть и инвесторы появились.
          • 0
            Так же, как и в любой другой отрасли. Организуете производство или продаете лицензии, договариваетесь с оптовиками или продаете сами. Полно историй успеха. (понятно, что провалов тоже дофига, но ориентиры-то есть)
            • 0
              Между. Я про саму разработку и подготовку к производству.
            • 0
              После этого ждете недели 2-3 и покупаете на ебее у китайцев устройство, сделанное по вашей идее.
              • 0
                Именно поэтому важно производить у нас, в России. И теперь это значительно проще.
                • 0
                  И платить безумные(по сравнению с китайскими фабриками) деньги за производство.
                  • +1
                    А вы производили что-нибудь там и тут? Вот уж где на самом деле страшилка, так это в вопросе «у китайцев все дешево, а у нас все дорого». Мы по долгу службы и тут и там производили. У Китайцев, конечно, несколько дешевле, но разница не настолько критична, чтобы из-за этого нельзя было бизнес вести. А уж монтаж давно у нас многие выполняют.
                    У китайцев просто жесточайшая конкуренция, поэтому они не считают, что без сверхприбыли нечего и начинать дело. Кстати, у нас тоже потихоньку к этому идут…
                • 0
                  Ну, во-первых, это просто страшилки. Сами китайцы крайне редко копируют что-то, т.к. это требует вложений собственных средств. Если уж копии появляются, то по заказу ваших «цивилизованных» конкурентов. И с этим легко бороться — сделайте цену такой, чтобы дешевле было купить у вас, чем производить самим.
                  А во-вторых, мы же знаем, что наличие китайских «айфонов» ничуть не мешает продажам настоящих, и оригинальные Ардуино продаются вовсю.
                  • 0
                    «сделайте цену такой, чтобы дешевле было купить у вас» — вот она, ключевая фраза. Пока на тебя тут наезжает таможня, налоговая, пожарники и прочие дармоеды — производить что-либо конкурентоспособное ты не сможешь. Соответственно, в бизнес-план надо закладывать первым пунктом или смену страны проживания, или смену правительства.
                    • +1
                      Простите, а вы пробовали? Или это так, музыкой навеяло?
                      Производить в России электронику на экспорт — бессмысленно (как и в большинстве других стран, кстати). Для внутреннего употребления иногда получается дешевле, чем импортировать, как ни странно.
                      А если разрабатывать здесь, а делать тираж в Китае, то вы оказываетесь в абсолютно одинаковых условиях со всем остальным миром. Конкурируйте на здоровье.
                      • 0
                        Не пробовал бы — не писал. А пока 50% стоимости продукта здесь составляют взятки — ничего путного не выйдет.
                        • +2
                          Я ни разу в жизни не давал взяток (если что — своей компании 5 лет, занимаемся электроникой). Что я делаю не так?
                          • 0
                            Я тоже не давал :) А кому давать-то? Мы что, нефтью торгуем? :) Мы не интересны для крупных структур, а слабые структуры давно прижучили (в Мск по крайней мере).
                            • +1
                              Человек написал, что у него издержки на взятки — половина от себестоимости. Мне реально интересно, как он добивается таких показателей?
                        • 0
                          Российские заводы, кстати, довольно много микросхем экспортируют. В том числе в Китай. Есть вещи, которые у нас дешевле и лучше.
                          • 0
                            Вас не затруднит привести примеры? Я без всякой иронии, просто очень хотелось бы посмотреть.
                            • 0
                              Вот например воронежский ВЗПП-Микрон: www.vsp-mikron.com/
                              У них даже сайт, как вы можете заметить, англоязычный — потому что почти вся продукция экспортируется.
                              Вот что говорит официальный пресс-релиз
                              «Сегодня предприятие представляет собой современный высокотехнологичный производственный комплекс по проектированию и массовому производству кристаллов силовых дискретных компонентов.
                              Внешнеэкономическая деятельность – стратегическое направление развития ВЗПП-Микрон. Сегодня более 60% продукции предприятия поставляется в Германию, КНР, Тайвань, Южную Корею, Филиппины и США.»

                              Вот что экспортирует Ангстрем: www.angstrem.ru/products/export/
                              Там все, конечно же, делается по старым технологиям и стоит копейки, но, тем не менее, приносит прибыль и успешно продается в мире. Собственно, на поставляемых микросхемах для калькуляторов российские заводы буквально выживали в 90-е.
                              • +1
                                Приятно такое видеть. Вдохновляет.
                      • +1
                        Это не страшилки. Это реальность. Если вы с таким не сталкивались — не значит, что этого нет. Если почувствуют, что прибыль будет — скопируют. И особых вложений для этого не нужно, т.к. как правило заводы производят изделия «под ключ». Лично я не сталкивался, т.к. сам лично не занимался этим вопросом, но мои коллеги, ответственные за работу с Азией, говорят, что случаев воровства полно. Так же они любят найти конкрутентов в той же стране и сделать им коммерческое предложение :)
                        • +2
                          Я не сталкивался, вы не сталкивались, а ваши коллеги «говорят». Это хорошая аргументация, да.
                          • 0
                            Коллеги, работавшие на тот момент со мной на одном предприятии. Более того, мне, как разработчику, начальство часто «вставляло» за «лишнюю» информацию, переданную северокорейцам и китайцам. При этом из слов начальства было понятно, что случаи были. Это, конечно, не доказательство, но и простыми слухами имеет мало общего: люди не в курилке байки травили, а выписывали конкретные распоряжения, чтобы защититься от воровства.
                • 0
                  Кстати давно мечтал о флешке умеющей монтировать ISO файлы подобно zalman'овому боксу ZM-VE200, там без экрана и кнопок и как минимум двух LUN-ов не обойтись.
                  • 0
                    Пытался однажды «изобрести» это дело. С помощью ISOLINUX что-то получалось, но потом я открыл для себя zalman.
                    • 0
                      А обычная флэшка + загрузчик grub2 не подходят? Исошки просто заливаются на ФС флешки и дальше граб с ними может по-всякому работать.
                      • 0
                        Там проблема в том, что после начала загрузки какой либо ос, флешка уже не доступна, и если эта ос не знает об этом то дальше она не загрузится… Конечно можно ковыряться в каждом iso образе, но это совсем не весело. Эмулятор дисковода гораздо сподручнее
                        • 0
                          Эммм. А кто мешает нужные для продолжения загрузки файлы закинуть на ramfs и уже оттуда…
                        • 0
                          grub грузит изошку в память (с очень невысокой скоростью) и потом передает ей управление, что для образов DVD неприемлемо — они даже загрузится не могут…
                          После мгновенного монтирования в zalman'е это даже для небольших образов не очень интересно
                      • 0
                        Швейцарская флешка системного администратора

                        Zalman VE-300/VE-400 удовлетоворяет вашим запросам. USB-Floppy может эмулировать большое количество флешек, конфигурируется спецсофтом это дело (flashboot.ru). В реальности пользуюсь только Zalman'ом. Создал там раздел впереди FAT32 на 8 гиг, использую для UEFI-boot. Супер девайс
                        • 0
                          но хотелось бы все таки флешку которую можно спокойно в кармане таскать
                          • 0
                            Тогда ISOLINUX с какими-то динамическими скриптами запрягать надо.
                            А USB-Floppy поддерживает уйма контроллеров. Вобщем-то как и USB-CDROM, только вот образ придется писать каждый раз через спецутилиту и «на ходу» не поменяешь.
                          • 0
                            Отличный девайс! Почему-то не натыкался на него. Видимо потому, что искал именно флешки.

                            Вообще-то он не все функции из описанных мной выполняет, но большую часть и самую востребованную — это точно. Очень хочется попробовать его в работе.
                          • НЛО прилетело и опубликовало эту надпись здесь
                            • +3
                              Автор несколько преувеличивает масштаб проблемы. Даже нереально толстый MJPG дает на 720р (а не 480р, как он предлагает) поток порядка 2-3 Мбайт/сек, что вполне успешно пишется на карточку. Это уже не говоря о H264.
                              Сама идея писать в RAM неплоха, это я согласен. Но просто нет такой уж прям необходимости в этом насущной. Ну и еще один забавный момент: 8 Гб RAM стоят в разы дороже 8 Гб eMMC.
                              • НЛО прилетело и опубликовало эту надпись здесь
                                • 0
                                  Я видимо плохо объяснил вот что: в качестве циклически перезаписываемой памяти используется _только_ оперативка. Т.е. в NVM что-либо скидывается только в случае возникновения ДТП. Сохраняется в итоге только один фрагмент длительностью 5 минут, но — самый важный.

                                  Я не говорю, что эта идея идеальна. Например, мы теряем возможность посмотреть какой-то важный фрагмент, если поняли, что он важный буквально через 5 минут. Но, на мой взгляд, такое происходит заметно реже. Чаще требуется сохранить какой-то один самый важный фрагмент либо нажатием кнопки (например, когда вы являетесь не участником, а наблюдателем), либо по датчику удара.
                                  • 0
                                    Регистратор нужен не только в случае ДТП, но и чтобы обосновать оборотням отсутствие нарушения, а тут уже нужна история (Например, чтобы доказать, что на светофоре горел зеленый). А на каждом светофоре кнопку нажимать не будешь…
                                    • 0
                                      На правах оффтопа: может быть это будет плохим оправданием идеи, но мой опыт показывает мне, что для оборотней в 99% случаев достаточно наличия видеорегистратора на лобовом стекле. Он может быть даже выключен.

                                      По теме: действительно, это минус устройства.
                                    • 0
                                      А что будет с устройством если в результате ДТП устройство будет повреждено? Данные в оперативке пропадут. Нет уж, критические данные должны писаться в ПЗУ сразу же. Пусть это будет и медленней, зато надежней.
                                      • 0
                                        Не смешите! Чтобы твердотельный видеорегистратор сломался, нужно втемяшиться так, чтобы кузов оказался замят до лобового стекла, чтобы печатная плата сломалась. В противном случае — это не HDD с механикой и магнитными дисками — ему ничего не будет (точнее будет камере, корпусу, наружным деталям, но не плате). На большинство микросхем максимальное ускорение — 500g. Я думаю эта цифра просто недостижима.
                                        • 0
                                          Бывают и более жесткие ДТП, да водителю уже скорей всего не поможешь, но есть еще куча заинтересованных лиц найти виновных. Ну и опять же при ДТП рег обычно отрывается от стекла и начинает летать по салону долбясь обо все подряд. Где гарантии, что что-нибудь, где нибудь не отойдет там? Например батарейку не оторвет, или какой нибудь из микро разъемов (в моем вот их 2) не даст дребезга и не повесит всю систему? Не обязательно ломать печатную плату, достаточно малейшего сбоя в работе из-за неконтакта. Причем потом он может и включиться как ни в чем ни бывало. И работать себе.

                                          Ну и, например, деградация батарей. У меня у рега аккумулятор просто сдох, в результате есть питание — пишем, нет сразу же вырубаемся. Если бы я это случайно не заметил, то так бы и ездил. А была бы у меня запись в раме? Ударился — питание выбило — запись потерялась.
                                          • 0
                                            Отвечу по пунктам.
                                            1. Не верю в то, что сделать надежный видеорегистратор нельзя. Не верю и все. То, что у кого-то что-то ломается — не показатель. Если конкретно: качественный поверхностный монтаж никакими ударами не отбить, backup батарейку надежно приделать к плате можно, микроразъемов в жизненно важных частях либо избежать, либо сделать надежными — тоже. Так что, считаю, что если не хочешь — можно найти сотню причин не делать что-то. Принципиальных трудностей не вижу.
                                            2. Деградацию батарей можно анализировать средствами самого видеорегистратора и вовремя сообщать об этом пользователю. И вообще, об аккумуляторах надо заботиться хотя бы как это делают ThinkPad'ы, многие производители об этом не думают, вот батарейки и летают. Ну и не забывать, что китайцы до сих пор Li-Ion не освоили, т.ч. брать только корею и японию.
                                            • 0
                                              Простите, что именно из Li-Ion китайцы не освоили до сих пор?
                                              • 0
                                                А что освоили? Я не вижу пока Li-Ion китайских аккумуляторов стабильного приемлемого качества, когда хотя бы 97% аккумуляторов имеют максимально допустимый здравым смыслом разброс емкости в 30%. А у японцев этот параметр до 15% доходит! Причем цена удельной емкости (реальной) получается даже ниже, чем у китайцев.
                                                • 0
                                                  В общей сложности мы уже закупили по двум проектам несколько тысяч китайских LiIon аккумуляторов. Разброса по емкости (судя по времени работы от полной зарядки) особого нет, брак — меньше 1%.
                                                  Вы свою статистику на каких количествах основываете?
                                                  А фабрики (например, в Донгуане, где много аккумуляторных) посещали? Смотрели на их продукцию?
                                                  • 0
                                                    Ого! Я пожалуй в личку обращусь. Буду рад взять свои слова обратно.
                                              • +2
                                                1. Конечно можно, вопрос лишь в цене и технологичности (т.е. опять в цене). Думаете пользователь готов за это переплатить? Готов оплатить испытания и повышенный контроль за монтажом?

                                                2. Ну ок, регистратор покажет, что батарейке пришел пушной зверь. Что дальше? Выбрасывать регистратор? Она обычно встроенная, если не встроенная, то см. пункт 1.
                                                • 0
                                                  Вы не доказываете, что это будет дорого, а просто постулируете это. Могу лишь согласиться с тем, что если это будет дорого, то идея окажется нежизнеспособной. Но я не считаю, что это будет слишком дорого. Опыт в разработке устройств подобного рода и подобных партий (около 100 тыс. шт. в год) у меня есть. Вас при этом, конечно, согласиться со мной не заставляю :)
                                                  • +2
                                                    Достаточно сравнить стоимость простых камер и экшн камер. Вторые значительно дороже, даже если это безродный нонейм с сомнительным качеством.
                                                    • 0
                                                      Они дороже не потому, что выше их себестоимость. На 70% разница между обычными и «спортивными» товарами складывается из-за наценки на спрос (спортивные товары популярней) и характер спроса (любителей спорта чаще не останавливает бОльшая цена).
                                    • 0
                                      1. Не уверен, что даже ваш смартфон ночью (с включённым ближним, конечно) и на колдобинах сможет записать видео, на котором будет виден номер машины на расстоянии хотя бы в 70% от того, на котором его видит человек с нормальным зрением. Если сможет — уже хорошо. Но тогда все равно останется трудность техническая: такие кодеки могут просто не дать китайцам, разрабатывающим видеорегистраторы. Вдруг они начнут клепать телефоны :)

                                      2. РАМ сейчас очень дешево стоит. Посмотрите на ebay, там 4 ГиБ планки продаются по 50-60 рублей. Конечно отдельно микросхемы будут стоить дороже, но ведь можно эти планки целиком и использовать :) (сделать слот на плате)
                                      • +1
                                        Тоже смутил этот момент. Зеркалки пишут в FullHD с ALL-I кодированием (высокое качество) спокойно на карты класса 10, обычные FullHD могут и на класс 4-6
                                        • –1
                                          Производители зеркалок несомненно смогут сделать видеорегистратор, но пока не делают. И вряд ли отдадут свои кодеки кому-то, чтобы те делали видеорегистраторы. Тут вопрос скорее технический. Принципиально я верю в то, что возможно писать сразу в NVM в хорошем качестве, но реализовать это на практике без миллионных тиражей и вложений наверняка не получится.
                                          • +1
                                            В статье говорится не про кодеки, а про SD карты, якобы это узкое место. Вот про что я.
                                            • 0
                                              Спасибо за замечание, исправил главу.
                                    • +1
                                      > К сожалению на разработку этого устройства такой команде как мы надо потратить около полугода.

                                      Неудобно вас огорчать, но уже не надо. Посмотрите DriveDroid в Google Play.
                                      • 0
                                        Классная идея, мне она в голову не пришла! Правда, если вы боитесь, что можете меня расстроить — перечитайте вступление к посту :) Я буду только рад, что кто-то эту идею уже реализовал.

                                        Правда, в данном случае я всё же считаю DriveDroid не полной заменой «Швейцарской флешки» т.к.:

                                        1. Далеко не все смартфоны способны выдать хорошие скорости записи-чтения по USB.
                                        2. Представляю себе, что вы будете делать, когда в процессе переразбиения диска gparted-ом у вас зазвонит телефон. Хорошо, если он при этом не сглючит и не зависнет :)
                                        3. RAIDа нету. Кстати, его и в Zalman'е нету.
                                        • 0
                                          Тоже не панацея, например в моем смартфоне ядро не поддерживает монтирование ISO как CD-ROM, только как USB-HDD, что далеко не для всех образов подходит (во всяком случаи нужные мне изошники не смогло нормально смонтировать)…
                                        • +5
                                          Я тут себе представил ассемблерные вставки и обработчики прерываний на ruby и умилился :) Как-то мне кажется, это не очень то вяжется с реальным временем.
                                          • 0
                                            Существует большое количество разнообразных задач. Я, например, ещё нигде не пользовался ассемлерными вставками в своей деятельности. Если задача решается правильными методами (а это, конечно, не всегда возможно), то ускорение участков кода переходом на ассемблерные вставки не требуется. Более того, как я писал в посте, большую часть времени процессор вообще простаивает, т.к. занимается только организацией процесса.

                                            Приведу простой утрированный пример того, что я называю организаторской деятельностью. Существует задача: преобразовать аналоговый сигнал в цифровой. У этой задачи по меньшей мере два решения.

                                            Решение 1.
                                            loop {
                                            Запускаем АЦП
                                            Выставляем выходной синал в 1
                                            Ждем T мс
                                            Выставляем выходной сигнал в 0
                                            Получаем значение из АЦП и записываем в T
                                            }

                                            Решение 2.
                                            Для выхода используем не GPIO, а ШИМ, АЦП ставим на автоперезапуск, DMA настраиваем на скидывание результата АЦП сразу в регистр ШИМа. В результате core после настройки этого процесса просто курит бамбук.

                                            Со временем у меня сформировалось совершенно четкое мнение: если где-то процессор выполняет много нудной работы и код этой задачи приходится оптимизировать, значит архитектура требует доработки. Даже если нет готового модуля — возможно получится поставить ПЛИС. Это, повторюсь, не всегда возможно, но надо стараться. И тогда не потребуется ставить сверхбыстрые процессоры и всё равно выпускать тормозные продукты.
                                            • 0
                                              Не всегда имеется достаточно периферии, чтобы все на нее спихнуть, хотя конечно лучше стремится процессор разгрузить от выполнения различных задач.
                                              Ассемблерные вставки, или точнее даже функции, вызывающие ассемблерные вставки, нужны для работы с прерываниями, для организации барьеров памяти и так далепее. Где-нибудь они обязательно встретятся.
                                              • 0
                                                Ассемблерные вставки, или точнее даже функции, вызывающие ассемблерные вставки, нужны для работы с прерываниями, для организации барьеров памяти и так далепее. Где-нибудь они обязательно встретятся.

                                                Это всё легко изолируется на уровне HAL, зачем это на самый верх тащить?

                                                Не всегда имеется достаточно периферии, чтобы все на нее спихнуть, хотя конечно лучше стремится процессор разгрузить от выполнения различных задач.

                                                Я ровно то же самое и говорил: стремиться надо, но не всегда получается :)
                                                • 0
                                                  В любом случае на чем-то этот HAL нужно писать во первых, а во вторых обычным программистам контроллеров в нем то и дело придется ковыряться, хочешь не хочешь, обычно оно редко просто берет и работает.
                                          • 0
                                            А может нужен склад для потенциально интересных идей?
                                            • 0
                                              Это скорее не склад, а повод к обсуждению этих идей. Ну и для кого-то может стать новостью, например, что существует mruby, который можно встроить в железку.
                                              • 0
                                                Вот-вот хаб как склад для идей, коих у каждого море, с возможностью узнать что-то новое или найти что-то нужное, доброе, вечное…
                                            • 0
                                              А нельзя прикрепить обычную маленькую видеокамеру и в режиме реального времени сбрасывать с неё инфу в компьютер? Почему сами производители автомобилей не встраивают их с приемлемым качеством по периметру. На цене не сильно бы сказалось.
                                              • +1
                                                Я, честно говоря, до сих пор не понимаю, почему в embedded тянут скриптовые языки? Ruby, python, lua… зачем? Обычно в таких языках сразу требуется сборщик мусора, типизация динамическая (словно замечательной типизации в С нам мало).
                                                В lua нельзя одновременно использовать целые числа и float.

                                                Почему бы не портировать нормальный компилируемый язык? Тот же D хотя бы. Строго говоря, любительскую сборку под cortex m3 я видел, но до финала там очень далеко.
                                                • 0
                                                  Согласен — было бы полезно. В каких-то задачах дивиденды от интерпретируемости совсем крохотные и можно было бы использовать какой-нибудь динамический, но компилируемый язык программирования. Отличная мысль. Просто я на данный момент вижу только mruby, про него и написал. Кстати, даже mruby был разработан в основном для встраивания в программы, а не в embedded. Т.ч. вашу мысль я бы обобщил до такой: «почему вообще до сих пор в embedded нет нормальных высокоуровневых языков?»
                                                  • +2
                                                    Ну, есть еще
                                                    Embedded lua
                                                    micro .Net
                                                    — есть ARM'ы с буквой J, которые поддерживают java-байткод
                                                    Micro python обещают.

                                                    И наверняка где-нибудь даже embedded javascript есть.
                                                    • 0
                                                      Класс! Спасибо за подборку, на досуге поизучаю. Однако компилируемых «чистых» ООП языков видимо нет, жаль…
                                                • 0
                                                  В Си как раз с типизацией все очень сложно, она хоть и статическая, но слабая, поэтому очень легко на проблемы с памятью нарваться: банально пострадать из за выравнивания структур.
                                                  Короче говоря, я бы действительно стремился портировать не скриптовый язык, а любой ЯП с детерменированной работой с памятью, то есть D или Rust. Да даже на C++ вполне можно аккуратно писать уже, но только грабли Си там все бережно сохраняются.
                                                  • –2
                                                    В Си++ нет динамизма, а, значит, нормальный пользовательский интерфейс не построить. Если он, конечно, нужен…
                                                    • 0
                                                      Речь все-таки идет о микроконтроллерах, а там нужен не динамизм, а предсказуемость.
                                                      • 0
                                                        А что произойдёт с предсказуемостью, если я вдруг запущу mruby на моём микроконтроллере? Понятно, что сейчас mruby хотя бы потенциально не стабилен. Но если предположить, что его отладили — то предсказуемость останется на прежнем уровне. Вот скорость выполнения операций ядром упадет — да. Но не в любой задаче это важно.

                                                        Мне кажется мы говорим о разных вещах. Я пытаюсь донести мысль «у нас появилась новая возможность», а вы — «чаще всего возникают задачи, в которых этот метод не проходит». Может быть чаще это действительно и так (хотя статистики у меня нет), но это не повод полностью отстранять идею.
                                                        • 0
                                                          Там есть сборщик мусора? Если есть, то предсказуемость падает однозначно.

                                                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.