Как стать автором
Обновить
16
0
Артём Левенков @ALev

Пользователь

Отправить сообщение
Вы не доказываете, что это будет дорого, а просто постулируете это. Могу лишь согласиться с тем, что если это будет дорого, то идея окажется нежизнеспособной. Но я не считаю, что это будет слишком дорого. Опыт в разработке устройств подобного рода и подобных партий (около 100 тыс. шт. в год) у меня есть. Вас при этом, конечно, согласиться со мной не заставляю :)
Класс! Спасибо за подборку, на досуге поизучаю. Однако компилируемых «чистых» ООП языков видимо нет, жаль…
А вы производили что-нибудь там и тут? Вот уж где на самом деле страшилка, так это в вопросе «у китайцев все дешево, а у нас все дорого». Мы по долгу службы и тут и там производили. У Китайцев, конечно, несколько дешевле, но разница не настолько критична, чтобы из-за этого нельзя было бизнес вести. А уж монтаж давно у нас многие выполняют.
У китайцев просто жесточайшая конкуренция, поэтому они не считают, что без сверхприбыли нечего и начинать дело. Кстати, у нас тоже потихоньку к этому идут…
Я тоже не давал :) А кому давать-то? Мы что, нефтью торгуем? :) Мы не интересны для крупных структур, а слабые структуры давно прижучили (в Мск по крайней мере).
А что освоили? Я не вижу пока Li-Ion китайских аккумуляторов стабильного приемлемого качества, когда хотя бы 97% аккумуляторов имеют максимально допустимый здравым смыслом разброс емкости в 30%. А у японцев этот параметр до 15% доходит! Причем цена удельной емкости (реальной) получается даже ниже, чем у китайцев.
Это скорее не склад, а повод к обсуждению этих идей. Ну и для кого-то может стать новостью, например, что существует mruby, который можно встроить в железку.
Согласен — было бы полезно. В каких-то задачах дивиденды от интерпретируемости совсем крохотные и можно было бы использовать какой-нибудь динамический, но компилируемый язык программирования. Отличная мысль. Просто я на данный момент вижу только mruby, про него и написал. Кстати, даже mruby был разработан в основном для встраивания в программы, а не в embedded. Т.ч. вашу мысль я бы обобщил до такой: «почему вообще до сих пор в embedded нет нормальных высокоуровневых языков?»
Ассемблерные вставки, или точнее даже функции, вызывающие ассемблерные вставки, нужны для работы с прерываниями, для организации барьеров памяти и так далепее. Где-нибудь они обязательно встретятся.

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

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

Я ровно то же самое и говорил: стремиться надо, но не всегда получается :)
Отвечу по пунктам.
1. Не верю в то, что сделать надежный видеорегистратор нельзя. Не верю и все. То, что у кого-то что-то ломается — не показатель. Если конкретно: качественный поверхностный монтаж никакими ударами не отбить, backup батарейку надежно приделать к плате можно, микроразъемов в жизненно важных частях либо избежать, либо сделать надежными — тоже. Так что, считаю, что если не хочешь — можно найти сотню причин не делать что-то. Принципиальных трудностей не вижу.
2. Деградацию батарей можно анализировать средствами самого видеорегистратора и вовремя сообщать об этом пользователю. И вообще, об аккумуляторах надо заботиться хотя бы как это делают ThinkPad'ы, многие производители об этом не думают, вот батарейки и летают. Ну и не забывать, что китайцы до сих пор Li-Ion не освоили, т.ч. брать только корею и японию.
Это не страшилки. Это реальность. Если вы с таким не сталкивались — не значит, что этого нет. Если почувствуют, что прибыль будет — скопируют. И особых вложений для этого не нужно, т.к. как правило заводы производят изделия «под ключ». Лично я не сталкивался, т.к. сам лично не занимался этим вопросом, но мои коллеги, ответственные за работу с Азией, говорят, что случаев воровства полно. Так же они любят найти конкрутентов в той же стране и сделать им коммерческое предложение :)
Не смешите! Чтобы твердотельный видеорегистратор сломался, нужно втемяшиться так, чтобы кузов оказался замят до лобового стекла, чтобы печатная плата сломалась. В противном случае — это не HDD с механикой и магнитными дисками — ему ничего не будет (точнее будет камере, корпусу, наружным деталям, но не плате). На большинство микросхем максимальное ускорение — 500g. Я думаю эта цифра просто недостижима.
Именно поэтому важно производить у нас, в России. И теперь это значительно проще.
Существует большое количество разнообразных задач. Я, например, ещё нигде не пользовался ассемлерными вставками в своей деятельности. Если задача решается правильными методами (а это, конечно, не всегда возможно), то ускорение участков кода переходом на ассемблерные вставки не требуется. Более того, как я писал в посте, большую часть времени процессор вообще простаивает, т.к. занимается только организацией процесса.

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

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

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

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

По теме: действительно, это минус устройства.
Спасибо за замечание, исправил главу.
Производители зеркалок несомненно смогут сделать видеорегистратор, но пока не делают. И вряд ли отдадут свои кодеки кому-то, чтобы те делали видеорегистраторы. Тут вопрос скорее технический. Принципиально я верю в то, что возможно писать сразу в NVM в хорошем качестве, но реализовать это на практике без миллионных тиражей и вложений наверняка не получится.
Отличный девайс! Почему-то не натыкался на него. Видимо потому, что искал именно флешки.

Вообще-то он не все функции из описанных мной выполняет, но большую часть и самую востребованную — это точно. Очень хочется попробовать его в работе.
Классная идея, мне она в голову не пришла! Правда, если вы боитесь, что можете меня расстроить — перечитайте вступление к посту :) Я буду только рад, что кто-то эту идею уже реализовал.

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

1. Далеко не все смартфоны способны выдать хорошие скорости записи-чтения по USB.
2. Представляю себе, что вы будете делать, когда в процессе переразбиения диска gparted-ом у вас зазвонит телефон. Хорошо, если он при этом не сглючит и не зависнет :)
3. RAIDа нету. Кстати, его и в Zalman'е нету.
1. Не уверен, что даже ваш смартфон ночью (с включённым ближним, конечно) и на колдобинах сможет записать видео, на котором будет виден номер машины на расстоянии хотя бы в 70% от того, на котором его видит человек с нормальным зрением. Если сможет — уже хорошо. Но тогда все равно останется трудность техническая: такие кодеки могут просто не дать китайцам, разрабатывающим видеорегистраторы. Вдруг они начнут клепать телефоны :)

2. РАМ сейчас очень дешево стоит. Посмотрите на ebay, там 4 ГиБ планки продаются по 50-60 рублей. Конечно отдельно микросхемы будут стоить дороже, но ведь можно эти планки целиком и использовать :) (сделать слот на плате)
Я видимо плохо объяснил вот что: в качестве циклически перезаписываемой памяти используется _только_ оперативка. Т.е. в NVM что-либо скидывается только в случае возникновения ДТП. Сохраняется в итоге только один фрагмент длительностью 5 минут, но — самый важный.

Я не говорю, что эта идея идеальна. Например, мы теряем возможность посмотреть какой-то важный фрагмент, если поняли, что он важный буквально через 5 минут. Но, на мой взгляд, такое происходит заметно реже. Чаще требуется сохранить какой-то один самый важный фрагмент либо нажатием кнопки (например, когда вы являетесь не участником, а наблюдателем), либо по датчику удара.

Информация

В рейтинге
Не участвует
Откуда
Москва, Москва и Московская обл., Россия
Дата рождения
Зарегистрирован
Активность