>интересовалась корпорация Apple. Сейчас _редмондская_ корпорация, по слухам, работает над собственным электромобилем, ..., Apple готова была заплатить
Так Microsoft или Apple интересовалась?
Хорошие результаты, но все предсказуемо — при маленьких объемах вызов микрокода — относительно большие накладные расходы для фронт енда. При больших объемах — вызов амортизируется, фронт енду наоборот приходится декодировать лишние объемы кода, особенно если он не поместился в LSD.
О, вопрос номер три. Да, лично я предпочитал OpenRC когда мы обсуждали это в команде, но остальные убедили меня, что раз у нас не совсем embedded платформа, а почти PC, то можно сделеть вид, что мы обычный дистрибутив, а они все перешли на systemd, поэтому скоро пользователям станет привычнее, и решения проблем будут гуглиться.
>4. Почему в Quark используется архитектура i586+, при всем том, что примерно 95% софта >сейчас собираются для i686? В итоге потерялось едиственное преимущество x86 (кроме >отлаженных драйверов для Linux) — обратная совместимость с уже собранным ПО. А если >все равно нужно все пересобирать, то можно пересобрать и для ARM или MIPS.
вычислительное ядро внутри Quark начинался как scunkworks/research проект, и во-многом использовался 486, в который удалось поместить 586 инструкции, но 686 уже нет. Как и у Atom с Core есть roadmap, в котором ваши замечания к первому представителю этого семейства CPU учтены.
С i686 на i586 — именно пересобрать, и результирующий бинарник работать будет хоть на Xeon'е. А с i686 на ARM/MIPS — это уже портировать. Может повести, и хорошо написанная софтина портируется простой перекомпиляцией. Но везет не всегда.
>Intel очень хорошо умеет делать железо, но не очень хорошо умеет делать ПО.
к сожалению, формат нашего общения не предрасполагает к обсуждению причин распространенности такого мнения, но при личной встрече (if ever) обсудим.
> разница между Intel и другими специалистами рынка Embedded вроде TI или ST — огромная.
У Intel embedded продуктов есть огромный плюс, но он же и минус. Практически все они — суть доработки dekstop/mobile/server процессоров-чипсетов. Это позволяет использовать мощный R&D и manufacturing process, но поэтому нет такого фокуса только на этот сегмент, как у компаний, у которых он единственный. Поэтому приоритет фич, нужный для embedded — далеко не первый.
Спасибо огромное за длинный, годный комментарий. Я переведу и покажу коллегам в IOTG и NDG. (Можно будет как-нибудь развиртуализоваться, как я буду в очередной раз в Деггендорфе навещать, как я догадываюсь, вашего работадателя на букву C или K)
Буду отвечать по очереди, постепенно. Баг с локом — не единственная причина отсутствия Дебиана. Еще он не так страшен, как вы описываете. Там не постоянные сегфолты, а редкие и неожиданные. Хрен редьки не слаще, конечно. Главная проблема скорее организационная — пока нет в quark patch в апстриме, мейнтейнеры debian не будут рады такому таргету. Ну и на 586 все перекомпилировать действительно плохо.
Главное в дебиане — десятки тысяч пакетов и dpkg. Но они все равно в-основном скомпилированы на на 586, то есть придется пересобирать. В мейнлайн дебиана пока попасть не получится, т.к. патчи для ядра, необходимые для загрузки, пока не в апстриме.
Не пробовал но странно, там все скомпилировано под 586.
Удачи на хакатоне. И да, если критичен realtime — захватите с собой и Uno, которую можно повесить как периферию на galileo/edison — я видел на хакатонах людей, которые так делали.
Проблемы с RT обычно с датчиками, которые работают с GPIO bit bang. I2C обычно работает. Советы:
1. на galileo bus N = 0, на edison = 6
2. Выясните адрес устройства заранее, енумерация может не сработать.
3. Если повиснет — cold reboot.
ардуино библиотека может работать, а может и нет. realtime точно не будет, но i2c датчики обычно как раз скрывают за своим микроконтроллером необходимость hard RT
К сожалению, никаких рекордов — просто с sysvinit было медленно, больше 20 секунд. Но openWRT специализированный дистрибутив, а мы включили по умолчанию кучу демонов на Node.JS — для клауда, графической разработки, XDK. Впрочем, можно выключить и получить еще секунду. Плюс я не считал бутлоадер который тоже 3 секунды вместе с грубом.
>драйверы, которые якобы собраны для x86, на практике даже на Atom работают либо сильно медленнее тех же драйверов, но на современных i3 / i5
а на galileo будет еще медленнее, чем на Atom, увы. Инструкции, которых нет на Atom/Quark — в-основном SIMD, которые в kernel mode драйверах обычно не используют.
>гигагерцовых многоканальных осцилографов
У quark на такое мощИ не хватит, конечно. Как и у бОльшей части ARMов.
Так Microsoft или Apple интересовалась?
вычислительное ядро внутри Quark начинался как scunkworks/research проект, и во-многом использовался 486, в который удалось поместить 586 инструкции, но 686 уже нет. Как и у Atom с Core есть roadmap, в котором ваши замечания к первому представителю этого семейства CPU учтены.
С i686 на i586 — именно пересобрать, и результирующий бинарник работать будет хоть на Xeon'е. А с i686 на ARM/MIPS — это уже портировать. Может повести, и хорошо написанная софтина портируется простой перекомпиляцией. Но везет не всегда.
к сожалению, формат нашего общения не предрасполагает к обсуждению причин распространенности такого мнения, но при личной встрече (if ever) обсудим.
> разница между Intel и другими специалистами рынка Embedded вроде TI или ST — огромная.
У Intel embedded продуктов есть огромный плюс, но он же и минус. Практически все они — суть доработки dekstop/mobile/server процессоров-чипсетов. Это позволяет использовать мощный R&D и manufacturing process, но поэтому нет такого фокуса только на этот сегмент, как у компаний, у которых он единственный. Поэтому приоритет фич, нужный для embedded — далеко не первый.
Буду отвечать по очереди, постепенно. Баг с локом — не единственная причина отсутствия Дебиана. Еще он не так страшен, как вы описываете. Там не постоянные сегфолты, а редкие и неожиданные. Хрен редьки не слаще, конечно. Главная проблема скорее организационная — пока нет в quark patch в апстриме, мейнтейнеры debian не будут рады такому таргету. Ну и на 586 все перекомпилировать действительно плохо.
Не пробовал но странно, там все скомпилировано под 586.
1. на galileo bus N = 0, на edison = 6
2. Выясните адрес устройства заранее, енумерация может не сработать.
3. Если повиснет — cold reboot.
ардуино библиотека может работать, а может и нет. realtime точно не будет, но i2c датчики обычно как раз скрывают за своим микроконтроллером необходимость hard RT
Уже не будущих, несколько месяцев как можно купить, например, ark.intel.com/products/78953/Intel-NUC-Kit-DN2820FYK
или yocto c software.intel.com/en-us/iotdevkit
из www.dailymail.co.uk/sciencetech/article-2578633/The-Man-vs-Machine-table-tennis-showdown-went-viral-actual-cleverly-shot-TV-ad.html
а на galileo будет еще медленнее, чем на Atom, увы. Инструкции, которых нет на Atom/Quark — в-основном SIMD, которые в kernel mode драйверах обычно не используют.
>гигагерцовых многоканальных осцилографов
У quark на такое мощИ не хватит, конечно. Как и у бОльшей части ARMов.