Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 85
Ruby — хорошо, JavaScript — лучше. Про остальное — ищите на eBay.
Подумываю над возможностью создания синтезатора (совсем другая история) в России, но сталкиваюсь со многими описанными проблемами, да и по хорошему бы надо платы заказывать, а не делать, да где денег взять… А так — я не эксперт, но идеи классные. Может кому и пригодится)
В каком смысле — платы «заказывать»? Заказывать разработку или производство? Если вы про производство, то тут вопросов нет — самому производить платы, все равно, что самому шить себе одежду и выращить все продукты питания: только этим и будешь заниматься и то плохо сделаешь.
Если же речь шла о разработке, то в вашем случае, боюсь, это невозможно, т.к. зачем кому-то на заказ делать готовый продукт, если его можно продавать самому — уведут. Так можно заказывать только разработку плат, которые без софта бесполезны, а софт можно защитить битом RO в MCU.
Если же речь шла о разработке, то в вашем случае, боюсь, это невозможно, т.к. зачем кому-то на заказ делать готовый продукт, если его можно продавать самому — уведут. Так можно заказывать только разработку плат, которые без софта бесполезны, а софт можно защитить битом RO в MCU.
Вот про mruby бы поподробнее…
Это встраиваемый Ruby. Можно, например, встроить в свой C/C++ код, откомпилировать и запускать байт-код.
matt.aimonetti.net/posts/2012/04/25/getting-started-with-mruby/
en.wikipedia.org/wiki/Mruby
matt.aimonetti.net/posts/2012/04/25/getting-started-with-mruby/
en.wikipedia.org/wiki/Mruby
Есть идея — делаете прототип, выходите на кикстартер, проверяете интерес к вашему продукту реальных потребителей. Если интерес есть — к вам инвесторы сами в очередь выстроятся. А если нет интереса — значит, не такая уж и хорошая была идея.
А дальше как? Когда интерес есть и инвесторы появились.
Так же, как и в любой другой отрасли. Организуете производство или продаете лицензии, договариваетесь с оптовиками или продаете сами. Полно историй успеха. (понятно, что провалов тоже дофига, но ориентиры-то есть)
После этого ждете недели 2-3 и покупаете на ебее у китайцев устройство, сделанное по вашей идее.
Именно поэтому важно производить у нас, в России. И теперь это значительно проще.
И платить безумные(по сравнению с китайскими фабриками) деньги за производство.
А вы производили что-нибудь там и тут? Вот уж где на самом деле страшилка, так это в вопросе «у китайцев все дешево, а у нас все дорого». Мы по долгу службы и тут и там производили. У Китайцев, конечно, несколько дешевле, но разница не настолько критична, чтобы из-за этого нельзя было бизнес вести. А уж монтаж давно у нас многие выполняют.
У китайцев просто жесточайшая конкуренция, поэтому они не считают, что без сверхприбыли нечего и начинать дело. Кстати, у нас тоже потихоньку к этому идут…
У китайцев просто жесточайшая конкуренция, поэтому они не считают, что без сверхприбыли нечего и начинать дело. Кстати, у нас тоже потихоньку к этому идут…
Ну, во-первых, это просто страшилки. Сами китайцы крайне редко копируют что-то, т.к. это требует вложений собственных средств. Если уж копии появляются, то по заказу ваших «цивилизованных» конкурентов. И с этим легко бороться — сделайте цену такой, чтобы дешевле было купить у вас, чем производить самим.
А во-вторых, мы же знаем, что наличие китайских «айфонов» ничуть не мешает продажам настоящих, и оригинальные Ардуино продаются вовсю.
А во-вторых, мы же знаем, что наличие китайских «айфонов» ничуть не мешает продажам настоящих, и оригинальные Ардуино продаются вовсю.
«сделайте цену такой, чтобы дешевле было купить у вас» — вот она, ключевая фраза. Пока на тебя тут наезжает таможня, налоговая, пожарники и прочие дармоеды — производить что-либо конкурентоспособное ты не сможешь. Соответственно, в бизнес-план надо закладывать первым пунктом или смену страны проживания, или смену правительства.
Простите, а вы пробовали? Или это так, музыкой навеяло?
Производить в России электронику на экспорт — бессмысленно (как и в большинстве других стран, кстати). Для внутреннего употребления иногда получается дешевле, чем импортировать, как ни странно.
А если разрабатывать здесь, а делать тираж в Китае, то вы оказываетесь в абсолютно одинаковых условиях со всем остальным миром. Конкурируйте на здоровье.
Производить в России электронику на экспорт — бессмысленно (как и в большинстве других стран, кстати). Для внутреннего употребления иногда получается дешевле, чем импортировать, как ни странно.
А если разрабатывать здесь, а делать тираж в Китае, то вы оказываетесь в абсолютно одинаковых условиях со всем остальным миром. Конкурируйте на здоровье.
Не пробовал бы — не писал. А пока 50% стоимости продукта здесь составляют взятки — ничего путного не выйдет.
Российские заводы, кстати, довольно много микросхем экспортируют. В том числе в Китай. Есть вещи, которые у нас дешевле и лучше.
Вас не затруднит привести примеры? Я без всякой иронии, просто очень хотелось бы посмотреть.
Вот например воронежский ВЗПП-Микрон: www.vsp-mikron.com/
У них даже сайт, как вы можете заметить, англоязычный — потому что почти вся продукция экспортируется.
Вот что говорит официальный пресс-релиз
«Сегодня предприятие представляет собой современный высокотехнологичный производственный комплекс по проектированию и массовому производству кристаллов силовых дискретных компонентов.
Внешнеэкономическая деятельность – стратегическое направление развития ВЗПП-Микрон. Сегодня более 60% продукции предприятия поставляется в Германию, КНР, Тайвань, Южную Корею, Филиппины и США.»
Вот что экспортирует Ангстрем: www.angstrem.ru/products/export/
Там все, конечно же, делается по старым технологиям и стоит копейки, но, тем не менее, приносит прибыль и успешно продается в мире. Собственно, на поставляемых микросхемах для калькуляторов российские заводы буквально выживали в 90-е.
У них даже сайт, как вы можете заметить, англоязычный — потому что почти вся продукция экспортируется.
Вот что говорит официальный пресс-релиз
«Сегодня предприятие представляет собой современный высокотехнологичный производственный комплекс по проектированию и массовому производству кристаллов силовых дискретных компонентов.
Внешнеэкономическая деятельность – стратегическое направление развития ВЗПП-Микрон. Сегодня более 60% продукции предприятия поставляется в Германию, КНР, Тайвань, Южную Корею, Филиппины и США.»
Вот что экспортирует Ангстрем: www.angstrem.ru/products/export/
Там все, конечно же, делается по старым технологиям и стоит копейки, но, тем не менее, приносит прибыль и успешно продается в мире. Собственно, на поставляемых микросхемах для калькуляторов российские заводы буквально выживали в 90-е.
Это не страшилки. Это реальность. Если вы с таким не сталкивались — не значит, что этого нет. Если почувствуют, что прибыль будет — скопируют. И особых вложений для этого не нужно, т.к. как правило заводы производят изделия «под ключ». Лично я не сталкивался, т.к. сам лично не занимался этим вопросом, но мои коллеги, ответственные за работу с Азией, говорят, что случаев воровства полно. Так же они любят найти конкрутентов в той же стране и сделать им коммерческое предложение :)
Я не сталкивался, вы не сталкивались, а ваши коллеги «говорят». Это хорошая аргументация, да.
Коллеги, работавшие на тот момент со мной на одном предприятии. Более того, мне, как разработчику, начальство часто «вставляло» за «лишнюю» информацию, переданную северокорейцам и китайцам. При этом из слов начальства было понятно, что случаи были. Это, конечно, не доказательство, но и простыми слухами имеет мало общего: люди не в курилке байки травили, а выписывали конкретные распоряжения, чтобы защититься от воровства.
Кстати давно мечтал о флешке умеющей монтировать ISO файлы подобно zalman'овому боксу ZM-VE200, там без экрана и кнопок и как минимум двух LUN-ов не обойтись.
Пытался однажды «изобрести» это дело. С помощью ISOLINUX что-то получалось, но потом я открыл для себя zalman.
А обычная флэшка + загрузчик grub2 не подходят? Исошки просто заливаются на ФС флешки и дальше граб с ними может по-всякому работать.
Там проблема в том, что после начала загрузки какой либо ос, флешка уже не доступна, и если эта ос не знает об этом то дальше она не загрузится… Конечно можно ковыряться в каждом iso образе, но это совсем не весело. Эмулятор дисковода гораздо сподручнее
grub грузит изошку в память (с очень невысокой скоростью) и потом передает ей управление, что для образов DVD неприемлемо — они даже загрузится не могут…
После мгновенного монтирования в zalman'е это даже для небольших образов не очень интересно
После мгновенного монтирования в zalman'е это даже для небольших образов не очень интересно
Швейцарская флешка системного администратора
Zalman VE-300/VE-400 удовлетоворяет вашим запросам. USB-Floppy может эмулировать большое количество флешек, конфигурируется спецсофтом это дело (flashboot.ru). В реальности пользуюсь только Zalman'ом. Создал там раздел впереди FAT32 на 8 гиг, использую для UEFI-boot. Супер девайс
но хотелось бы все таки флешку которую можно спокойно в кармане таскать
Отличный девайс! Почему-то не натыкался на него. Видимо потому, что искал именно флешки.
Вообще-то он не все функции из описанных мной выполняет, но большую часть и самую востребованную — это точно. Очень хочется попробовать его в работе.
Вообще-то он не все функции из описанных мной выполняет, но большую часть и самую востребованную — это точно. Очень хочется попробовать его в работе.
Автор несколько преувеличивает масштаб проблемы. Даже нереально толстый MJPG дает на 720р (а не 480р, как он предлагает) поток порядка 2-3 Мбайт/сек, что вполне успешно пишется на карточку. Это уже не говоря о H264.
Сама идея писать в RAM неплоха, это я согласен. Но просто нет такой уж прям необходимости в этом насущной. Ну и еще один забавный момент: 8 Гб RAM стоят в разы дороже 8 Гб eMMC.
Сама идея писать в RAM неплоха, это я согласен. Но просто нет такой уж прям необходимости в этом насущной. Ну и еще один забавный момент: 8 Гб RAM стоят в разы дороже 8 Гб eMMC.
Я видимо плохо объяснил вот что: в качестве циклически перезаписываемой памяти используется _только_ оперативка. Т.е. в NVM что-либо скидывается только в случае возникновения ДТП. Сохраняется в итоге только один фрагмент длительностью 5 минут, но — самый важный.
Я не говорю, что эта идея идеальна. Например, мы теряем возможность посмотреть какой-то важный фрагмент, если поняли, что он важный буквально через 5 минут. Но, на мой взгляд, такое происходит заметно реже. Чаще требуется сохранить какой-то один самый важный фрагмент либо нажатием кнопки (например, когда вы являетесь не участником, а наблюдателем), либо по датчику удара.
Я не говорю, что эта идея идеальна. Например, мы теряем возможность посмотреть какой-то важный фрагмент, если поняли, что он важный буквально через 5 минут. Но, на мой взгляд, такое происходит заметно реже. Чаще требуется сохранить какой-то один самый важный фрагмент либо нажатием кнопки (например, когда вы являетесь не участником, а наблюдателем), либо по датчику удара.
Регистратор нужен не только в случае ДТП, но и чтобы обосновать оборотням отсутствие нарушения, а тут уже нужна история (Например, чтобы доказать, что на светофоре горел зеленый). А на каждом светофоре кнопку нажимать не будешь…
А что будет с устройством если в результате ДТП устройство будет повреждено? Данные в оперативке пропадут. Нет уж, критические данные должны писаться в ПЗУ сразу же. Пусть это будет и медленней, зато надежней.
Не смешите! Чтобы твердотельный видеорегистратор сломался, нужно втемяшиться так, чтобы кузов оказался замят до лобового стекла, чтобы печатная плата сломалась. В противном случае — это не HDD с механикой и магнитными дисками — ему ничего не будет (точнее будет камере, корпусу, наружным деталям, но не плате). На большинство микросхем максимальное ускорение — 500g. Я думаю эта цифра просто недостижима.
Бывают и более жесткие ДТП, да водителю уже скорей всего не поможешь, но есть еще куча заинтересованных лиц найти виновных. Ну и опять же при ДТП рег обычно отрывается от стекла и начинает летать по салону долбясь обо все подряд. Где гарантии, что что-нибудь, где нибудь не отойдет там? Например батарейку не оторвет, или какой нибудь из микро разъемов (в моем вот их 2) не даст дребезга и не повесит всю систему? Не обязательно ломать печатную плату, достаточно малейшего сбоя в работе из-за неконтакта. Причем потом он может и включиться как ни в чем ни бывало. И работать себе.
Ну и, например, деградация батарей. У меня у рега аккумулятор просто сдох, в результате есть питание — пишем, нет сразу же вырубаемся. Если бы я это случайно не заметил, то так бы и ездил. А была бы у меня запись в раме? Ударился — питание выбило — запись потерялась.
Ну и, например, деградация батарей. У меня у рега аккумулятор просто сдох, в результате есть питание — пишем, нет сразу же вырубаемся. Если бы я это случайно не заметил, то так бы и ездил. А была бы у меня запись в раме? Ударился — питание выбило — запись потерялась.
Отвечу по пунктам.
1. Не верю в то, что сделать надежный видеорегистратор нельзя. Не верю и все. То, что у кого-то что-то ломается — не показатель. Если конкретно: качественный поверхностный монтаж никакими ударами не отбить, backup батарейку надежно приделать к плате можно, микроразъемов в жизненно важных частях либо избежать, либо сделать надежными — тоже. Так что, считаю, что если не хочешь — можно найти сотню причин не делать что-то. Принципиальных трудностей не вижу.
2. Деградацию батарей можно анализировать средствами самого видеорегистратора и вовремя сообщать об этом пользователю. И вообще, об аккумуляторах надо заботиться хотя бы как это делают ThinkPad'ы, многие производители об этом не думают, вот батарейки и летают. Ну и не забывать, что китайцы до сих пор Li-Ion не освоили, т.ч. брать только корею и японию.
1. Не верю в то, что сделать надежный видеорегистратор нельзя. Не верю и все. То, что у кого-то что-то ломается — не показатель. Если конкретно: качественный поверхностный монтаж никакими ударами не отбить, backup батарейку надежно приделать к плате можно, микроразъемов в жизненно важных частях либо избежать, либо сделать надежными — тоже. Так что, считаю, что если не хочешь — можно найти сотню причин не делать что-то. Принципиальных трудностей не вижу.
2. Деградацию батарей можно анализировать средствами самого видеорегистратора и вовремя сообщать об этом пользователю. И вообще, об аккумуляторах надо заботиться хотя бы как это делают ThinkPad'ы, многие производители об этом не думают, вот батарейки и летают. Ну и не забывать, что китайцы до сих пор Li-Ion не освоили, т.ч. брать только корею и японию.
Простите, что именно из Li-Ion китайцы не освоили до сих пор?
А что освоили? Я не вижу пока Li-Ion китайских аккумуляторов стабильного приемлемого качества, когда хотя бы 97% аккумуляторов имеют максимально допустимый здравым смыслом разброс емкости в 30%. А у японцев этот параметр до 15% доходит! Причем цена удельной емкости (реальной) получается даже ниже, чем у китайцев.
В общей сложности мы уже закупили по двум проектам несколько тысяч китайских LiIon аккумуляторов. Разброса по емкости (судя по времени работы от полной зарядки) особого нет, брак — меньше 1%.
Вы свою статистику на каких количествах основываете?
А фабрики (например, в Донгуане, где много аккумуляторных) посещали? Смотрели на их продукцию?
Вы свою статистику на каких количествах основываете?
А фабрики (например, в Донгуане, где много аккумуляторных) посещали? Смотрели на их продукцию?
1. Конечно можно, вопрос лишь в цене и технологичности (т.е. опять в цене). Думаете пользователь готов за это переплатить? Готов оплатить испытания и повышенный контроль за монтажом?
2. Ну ок, регистратор покажет, что батарейке пришел пушной зверь. Что дальше? Выбрасывать регистратор? Она обычно встроенная, если не встроенная, то см. пункт 1.
2. Ну ок, регистратор покажет, что батарейке пришел пушной зверь. Что дальше? Выбрасывать регистратор? Она обычно встроенная, если не встроенная, то см. пункт 1.
Вы не доказываете, что это будет дорого, а просто постулируете это. Могу лишь согласиться с тем, что если это будет дорого, то идея окажется нежизнеспособной. Но я не считаю, что это будет слишком дорого. Опыт в разработке устройств подобного рода и подобных партий (около 100 тыс. шт. в год) у меня есть. Вас при этом, конечно, согласиться со мной не заставляю :)
1. Не уверен, что даже ваш смартфон ночью (с включённым ближним, конечно) и на колдобинах сможет записать видео, на котором будет виден номер машины на расстоянии хотя бы в 70% от того, на котором его видит человек с нормальным зрением. Если сможет — уже хорошо. Но тогда все равно останется трудность техническая: такие кодеки могут просто не дать китайцам, разрабатывающим видеорегистраторы. Вдруг они начнут клепать телефоны :)
2. РАМ сейчас очень дешево стоит. Посмотрите на ebay, там 4 ГиБ планки продаются по 50-60 рублей. Конечно отдельно микросхемы будут стоить дороже, но ведь можно эти планки целиком и использовать :) (сделать слот на плате)
2. РАМ сейчас очень дешево стоит. Посмотрите на ebay, там 4 ГиБ планки продаются по 50-60 рублей. Конечно отдельно микросхемы будут стоить дороже, но ведь можно эти планки целиком и использовать :) (сделать слот на плате)
Тоже смутил этот момент. Зеркалки пишут в FullHD с ALL-I кодированием (высокое качество) спокойно на карты класса 10, обычные FullHD могут и на класс 4-6
Производители зеркалок несомненно смогут сделать видеорегистратор, но пока не делают. И вряд ли отдадут свои кодеки кому-то, чтобы те делали видеорегистраторы. Тут вопрос скорее технический. Принципиально я верю в то, что возможно писать сразу в NVM в хорошем качестве, но реализовать это на практике без миллионных тиражей и вложений наверняка не получится.
> К сожалению на разработку этого устройства такой команде как мы надо потратить около полугода.
Неудобно вас огорчать, но уже не надо. Посмотрите DriveDroid в Google Play.
Неудобно вас огорчать, но уже не надо. Посмотрите DriveDroid в Google Play.
Классная идея, мне она в голову не пришла! Правда, если вы боитесь, что можете меня расстроить — перечитайте вступление к посту :) Я буду только рад, что кто-то эту идею уже реализовал.
Правда, в данном случае я всё же считаю DriveDroid не полной заменой «Швейцарской флешки» т.к.:
1. Далеко не все смартфоны способны выдать хорошие скорости записи-чтения по USB.
2. Представляю себе, что вы будете делать, когда в процессе переразбиения диска gparted-ом у вас зазвонит телефон. Хорошо, если он при этом не сглючит и не зависнет :)
3. RAIDа нету. Кстати, его и в Zalman'е нету.
Правда, в данном случае я всё же считаю DriveDroid не полной заменой «Швейцарской флешки» т.к.:
1. Далеко не все смартфоны способны выдать хорошие скорости записи-чтения по USB.
2. Представляю себе, что вы будете делать, когда в процессе переразбиения диска gparted-ом у вас зазвонит телефон. Хорошо, если он при этом не сглючит и не зависнет :)
3. RAIDа нету. Кстати, его и в Zalman'е нету.
Тоже не панацея, например в моем смартфоне ядро не поддерживает монтирование ISO как CD-ROM, только как USB-HDD, что далеко не для всех образов подходит (во всяком случаи нужные мне изошники не смогло нормально смонтировать)…
Я тут себе представил ассемблерные вставки и обработчики прерываний на ruby и умилился :) Как-то мне кажется, это не очень то вяжется с реальным временем.
Существует большое количество разнообразных задач. Я, например, ещё нигде не пользовался ассемлерными вставками в своей деятельности. Если задача решается правильными методами (а это, конечно, не всегда возможно), то ускорение участков кода переходом на ассемблерные вставки не требуется. Более того, как я писал в посте, большую часть времени процессор вообще простаивает, т.к. занимается только организацией процесса.
Приведу простой утрированный пример того, что я называю организаторской деятельностью. Существует задача: преобразовать аналоговый сигнал в цифровой. У этой задачи по меньшей мере два решения.
Решение 1.
loop {
Запускаем АЦП
Выставляем выходной синал в 1
Ждем T мс
Выставляем выходной сигнал в 0
Получаем значение из АЦП и записываем в T
}
Решение 2.
Для выхода используем не GPIO, а ШИМ, АЦП ставим на автоперезапуск, DMA настраиваем на скидывание результата АЦП сразу в регистр ШИМа. В результате core после настройки этого процесса просто курит бамбук.
Со временем у меня сформировалось совершенно четкое мнение: если где-то процессор выполняет много нудной работы и код этой задачи приходится оптимизировать, значит архитектура требует доработки. Даже если нет готового модуля — возможно получится поставить ПЛИС. Это, повторюсь, не всегда возможно, но надо стараться. И тогда не потребуется ставить сверхбыстрые процессоры и всё равно выпускать тормозные продукты.
Приведу простой утрированный пример того, что я называю организаторской деятельностью. Существует задача: преобразовать аналоговый сигнал в цифровой. У этой задачи по меньшей мере два решения.
Решение 1.
loop {
Запускаем АЦП
Выставляем выходной синал в 1
Ждем T мс
Выставляем выходной сигнал в 0
Получаем значение из АЦП и записываем в T
}
Решение 2.
Для выхода используем не GPIO, а ШИМ, АЦП ставим на автоперезапуск, DMA настраиваем на скидывание результата АЦП сразу в регистр ШИМа. В результате core после настройки этого процесса просто курит бамбук.
Со временем у меня сформировалось совершенно четкое мнение: если где-то процессор выполняет много нудной работы и код этой задачи приходится оптимизировать, значит архитектура требует доработки. Даже если нет готового модуля — возможно получится поставить ПЛИС. Это, повторюсь, не всегда возможно, но надо стараться. И тогда не потребуется ставить сверхбыстрые процессоры и всё равно выпускать тормозные продукты.
Не всегда имеется достаточно периферии, чтобы все на нее спихнуть, хотя конечно лучше стремится процессор разгрузить от выполнения различных задач.
Ассемблерные вставки, или точнее даже функции, вызывающие ассемблерные вставки, нужны для работы с прерываниями, для организации барьеров памяти и так далепее. Где-нибудь они обязательно встретятся.
Ассемблерные вставки, или точнее даже функции, вызывающие ассемблерные вставки, нужны для работы с прерываниями, для организации барьеров памяти и так далепее. Где-нибудь они обязательно встретятся.
Ассемблерные вставки, или точнее даже функции, вызывающие ассемблерные вставки, нужны для работы с прерываниями, для организации барьеров памяти и так далепее. Где-нибудь они обязательно встретятся.
Это всё легко изолируется на уровне HAL, зачем это на самый верх тащить?
Не всегда имеется достаточно периферии, чтобы все на нее спихнуть, хотя конечно лучше стремится процессор разгрузить от выполнения различных задач.
Я ровно то же самое и говорил: стремиться надо, но не всегда получается :)
А может нужен склад для потенциально интересных идей?
А нельзя прикрепить обычную маленькую видеокамеру и в режиме реального времени сбрасывать с неё инфу в компьютер? Почему сами производители автомобилей не встраивают их с приемлемым качеством по периметру. На цене не сильно бы сказалось.
Я, честно говоря, до сих пор не понимаю, почему в embedded тянут скриптовые языки? Ruby, python, lua… зачем? Обычно в таких языках сразу требуется сборщик мусора, типизация динамическая (словно замечательной типизации в С нам мало).
В lua нельзя одновременно использовать целые числа и float.
Почему бы не портировать нормальный компилируемый язык? Тот же D хотя бы. Строго говоря, любительскую сборку под cortex m3 я видел, но до финала там очень далеко.
В lua нельзя одновременно использовать целые числа и float.
Почему бы не портировать нормальный компилируемый язык? Тот же D хотя бы. Строго говоря, любительскую сборку под cortex m3 я видел, но до финала там очень далеко.
Согласен — было бы полезно. В каких-то задачах дивиденды от интерпретируемости совсем крохотные и можно было бы использовать какой-нибудь динамический, но компилируемый язык программирования. Отличная мысль. Просто я на данный момент вижу только mruby, про него и написал. Кстати, даже mruby был разработан в основном для встраивания в программы, а не в embedded. Т.ч. вашу мысль я бы обобщил до такой: «почему вообще до сих пор в embedded нет нормальных высокоуровневых языков?»
Ну, есть еще
— Embedded lua
— micro .Net
— есть ARM'ы с буквой J, которые поддерживают java-байткод
— Micro python обещают.
И наверняка где-нибудь даже embedded javascript есть.
— Embedded lua
— micro .Net
— есть ARM'ы с буквой J, которые поддерживают java-байткод
— Micro python обещают.
И наверняка где-нибудь даже embedded javascript есть.
Класс! Спасибо за подборку, на досуге поизучаю. Однако компилируемых «чистых» ООП языков видимо нет, жаль…
Я лично вообще мало компилируемых языков знаю :) Objective C, D, Rust, Go, Haskell, Ocaml, Pascal, Basic… и все, пожалуй.
D таки можно затащить, при желании, насчет остального — не знаю.
D таки можно затащить, при желании, насчет остального — не знаю.
В Си как раз с типизацией все очень сложно, она хоть и статическая, но слабая, поэтому очень легко на проблемы с памятью нарваться: банально пострадать из за выравнивания структур.
Короче говоря, я бы действительно стремился портировать не скриптовый язык, а любой ЯП с детерменированной работой с памятью, то есть D или Rust. Да даже на C++ вполне можно аккуратно писать уже, но только грабли Си там все бережно сохраняются.
Короче говоря, я бы действительно стремился портировать не скриптовый язык, а любой ЯП с детерменированной работой с памятью, то есть D или Rust. Да даже на C++ вполне можно аккуратно писать уже, но только грабли Си там все бережно сохраняются.
В Си++ нет динамизма, а, значит, нормальный пользовательский интерфейс не построить. Если он, конечно, нужен…
Речь все-таки идет о микроконтроллерах, а там нужен не динамизм, а предсказуемость.
А что произойдёт с предсказуемостью, если я вдруг запущу mruby на моём микроконтроллере? Понятно, что сейчас mruby хотя бы потенциально не стабилен. Но если предположить, что его отладили — то предсказуемость останется на прежнем уровне. Вот скорость выполнения операций ядром упадет — да. Но не в любой задаче это важно.
Мне кажется мы говорим о разных вещах. Я пытаюсь донести мысль «у нас появилась новая возможность», а вы — «чаще всего возникают задачи, в которых этот метод не проходит». Может быть чаще это действительно и так (хотя статистики у меня нет), но это не повод полностью отстранять идею.
Мне кажется мы говорим о разных вещах. Я пытаюсь донести мысль «у нас появилась новая возможность», а вы — «чаще всего возникают задачи, в которых этот метод не проходит». Может быть чаще это действительно и так (хотя статистики у меня нет), но это не повод полностью отстранять идею.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Идеи и возможности разработки электроники в России