Комментарии 19
Когда вы говорите про загрузку «в три раза быстрее» — это сколько в цифрах? Если не использовать всякие хаки, через сколько секунд запустится мое юзерспейсовое приложение?
Я попробовал Yocto на виртуалке — показалось, что там все очень неторопливо относительно других около-embedded систем (сравниваю с OpenWRT, хотя, конечно, весовая категория разная). Однако допускаю, что я просто не умею его готовить.
Я попробовал Yocto на виртуалке — показалось, что там все очень неторопливо относительно других около-embedded систем (сравниваю с OpenWRT, хотя, конечно, весовая категория разная). Однако допускаю, что я просто не умею его готовить.
0
К сожалению, никаких рекордов — просто с sysvinit было медленно, больше 20 секунд. Но openWRT специализированный дистрибутив, а мы включили по умолчанию кучу демонов на Node.JS — для клауда, графической разработки, XDK. Впрочем, можно выключить и получить еще секунду. Плюс я не считал бутлоадер который тоже 3 секунды вместе с грубом.
0
Иду на хакатон, особенно интересует
У меня датчики опрашиваются по i2c, смогу ли я «заюзать» библиотеки от arduino и чтобы всё было реалтайм. Спасибо.
У меня не работает DHT22 сенсор X, которому нужно посылать микросекундные импульсы в точные временные отрезки — а Arduino это умеет.
У меня датчики опрашиваются по i2c, смогу ли я «заюзать» библиотеки от arduino и чтобы всё было реалтайм. Спасибо.
+1
Проблемы с RT обычно с датчиками, которые работают с GPIO bit bang. I2C обычно работает. Советы:
1. на galileo bus N = 0, на edison = 6
2. Выясните адрес устройства заранее, енумерация может не сработать.
3. Если повиснет — cold reboot.
ардуино библиотека может работать, а может и нет. realtime точно не будет, но i2c датчики обычно как раз скрывают за своим микроконтроллером необходимость hard RT
1. на galileo bus N = 0, на edison = 6
2. Выясните адрес устройства заранее, енумерация может не сработать.
3. Если повиснет — cold reboot.
ардуино библиотека может работать, а может и нет. realtime точно не будет, но i2c датчики обычно как раз скрывают за своим микроконтроллером необходимость hard RT
+1
ответил выше
0
И все-таки, почему не правоверный debian?
Тоже иду на хакатон, придется потратить значительную часть времени на освоение новой платформы.
И второй вопрос, есть ли возможность погонять OS на qemu? Я получаю сообщение о не поддерживаемых инструкциях процессора.
Тоже иду на хакатон, придется потратить значительную часть времени на освоение новой платформы.
И второй вопрос, есть ли возможность погонять OS на qemu? Я получаю сообщение о не поддерживаемых инструкциях процессора.
0
Главное в дебиане — десятки тысяч пакетов и dpkg. Но они все равно в-основном скомпилированы на на 586, то есть придется пересобирать. В мейнлайн дебиана пока попасть не получится, т.к. патчи для ядра, необходимые для загрузки, пока не в апстриме.
Не пробовал но странно, там все скомпилировано под 586.
Не пробовал но странно, там все скомпилировано под 586.
0
Принимаю предложение немного похоливарить, тем более от разработчика.
1. Почему Yocto, а не что-то другое — это понятно. Во-первых, над Yocto у Intel больше контроля, согласовывать добавление/изменение/удаление каких-то пакетов ни с кем не нужно. А еще потому, что в Quark X1000 имеется баг обработки префикса lock, из-за которого практически все современные дистрибутивы Linux не могут нормально работать на нем из-за постоянных сегфолтов.
2. К сожалению, создается впечатление, что Intel очень хорошо умеет делать железо, но не очень хорошо умеет делать ПО. Или не хочет, тут уж я не могу сказать. Понятно, что основные деньги зарабатываются продажей железа, но разница между Intel и другими специалистами рынка Embedded вроде TI или ST — огромная. Куда не ткнись по поводу поддержки ПО для Atom/Quark — везде затык. За один только EMGD иногда хочется убивать, а оно там все такое. Простой пример из недавнего: интерфейс MIPI CSI2 на Atom E38xx, которые так старательно рекламируют в Embedded-среде: «наш SoC его поддерживает, все работает, можете подключать свои камеры и сразу видеть результат.» Не указано только, что драйвер atomisp2 есть только для Yocto и Timesys Fedora 20, работает только с 32-битным ядром Linux 3.10 и поддерживает работу с ровно двумя камерами на 5 МП, которые, по невероятному стечению обстоятельств, и установлены на тестовой плате для CSI, а ее, в свою очередь, можно подключить только к CRB для Baytrail. В итоге я потратил неделю на то, чтобы заставить камеру работать через этот интерфейс хоть как-то, при том, что на iMX6 этот же интерфейс работает на любом современном Linux'е из коробки.
3. Почему Quark SoC имеет всего 16 линий GPIO на данный момент? Именно вследсвие этого пришлось ставить I2C port expander и делать всю совместимость с Arduino через него. Было бы достаточно GPIO — обошлись бы level shifter'ами.
4. Почему в Quark используется архитектура i586+, при всем том, что примерно 95% софта сейчас собираются для i686? В итоге потерялось едиственное преимущество x86 (кроме отлаженных драйверов для Linux) — обратная совместимость с уже собранным ПО. А если все равно нужно все пересобирать, то можно пересобрать и для ARM или MIPS.
5. Зачем понадобилось вообще выпускать Quark в качестве отдельного SoC, какова его ниша в данный момент? Производительность меньше чем у RaspberryPi за 30$, x86 «не настоящий», интерфейсов для IoT любой Atom предоставляет больше, рекорды энергопотребления он тоже не бьет. Я понимаю, когда такое урезанное ядро используется как synthesable IP core внутри какого-нибудь Atom для поддержки TXE, но зачем его в таком виде на рынок выводить, кособокого и без GPU, да еще и рекламировать его как дверь в мир IoT, при том, что I2C (в виде SMBus) и SPI есть на любом CPU и SoC производства Intel последних 5 лет? А еще можно поставить на плату копеечный МК на Cortex-M и получить все то же самое, только дешевле и с лучшей поддержкой со стороны ПО.
Получилось немного сумбурно, прошу меня извинить, тоже редко пишу по-русски.
Хочу сказать огромное спасибо за открытый код UEFI для Galileo (как раз пишу цикл статей про него в данный момент: раз, два, три, четвертая часть на подходе), очень жду открытия UEFI для Minnowboard MAX, обещали в сентябре, но вмешались "unforseen changes". Спасибо также за первый на моей памяти JTAG TAP для x86 без NDA и за $20 вместо $5000, теперь можно писать и отлаживать baremetal OS, не заключая контрактов.
Удачи вам, всей IOTG и другим ребятам из ED. Ровно одно пожелание для всех вас от простого инженера: обратите внимание на поддержку своих продуктов со стороны ПО, желательно еще до их выхода. А то ведь Galileo уже почти год как выпущен, а репозиторий для opkg появился только сейчас, аппаратные интерфейсы на SoC есть — драйверов для них нет, и так далее. А то получается продуктивнее просто сказать, что на наших платах нет поддержки CSI2, CAN и HSUART, чем приводить их Proof-of-Concept-драйверы от Intel в пригодное для клиентов состояние. За любой сдвиг в этом направлении — охапку лучей добра вам заранее.
1. Почему Yocto, а не что-то другое — это понятно. Во-первых, над Yocto у Intel больше контроля, согласовывать добавление/изменение/удаление каких-то пакетов ни с кем не нужно. А еще потому, что в Quark X1000 имеется баг обработки префикса lock, из-за которого практически все современные дистрибутивы Linux не могут нормально работать на нем из-за постоянных сегфолтов.
2. К сожалению, создается впечатление, что Intel очень хорошо умеет делать железо, но не очень хорошо умеет делать ПО. Или не хочет, тут уж я не могу сказать. Понятно, что основные деньги зарабатываются продажей железа, но разница между Intel и другими специалистами рынка Embedded вроде TI или ST — огромная. Куда не ткнись по поводу поддержки ПО для Atom/Quark — везде затык. За один только EMGD иногда хочется убивать, а оно там все такое. Простой пример из недавнего: интерфейс MIPI CSI2 на Atom E38xx, которые так старательно рекламируют в Embedded-среде: «наш SoC его поддерживает, все работает, можете подключать свои камеры и сразу видеть результат.» Не указано только, что драйвер atomisp2 есть только для Yocto и Timesys Fedora 20, работает только с 32-битным ядром Linux 3.10 и поддерживает работу с ровно двумя камерами на 5 МП, которые, по невероятному стечению обстоятельств, и установлены на тестовой плате для CSI, а ее, в свою очередь, можно подключить только к CRB для Baytrail. В итоге я потратил неделю на то, чтобы заставить камеру работать через этот интерфейс хоть как-то, при том, что на iMX6 этот же интерфейс работает на любом современном Linux'е из коробки.
3. Почему Quark SoC имеет всего 16 линий GPIO на данный момент? Именно вследсвие этого пришлось ставить I2C port expander и делать всю совместимость с Arduino через него. Было бы достаточно GPIO — обошлись бы level shifter'ами.
4. Почему в Quark используется архитектура i586+, при всем том, что примерно 95% софта сейчас собираются для i686? В итоге потерялось едиственное преимущество x86 (кроме отлаженных драйверов для Linux) — обратная совместимость с уже собранным ПО. А если все равно нужно все пересобирать, то можно пересобрать и для ARM или MIPS.
5. Зачем понадобилось вообще выпускать Quark в качестве отдельного SoC, какова его ниша в данный момент? Производительность меньше чем у RaspberryPi за 30$, x86 «не настоящий», интерфейсов для IoT любой Atom предоставляет больше, рекорды энергопотребления он тоже не бьет. Я понимаю, когда такое урезанное ядро используется как synthesable IP core внутри какого-нибудь Atom для поддержки TXE, но зачем его в таком виде на рынок выводить, кособокого и без GPU, да еще и рекламировать его как дверь в мир IoT, при том, что I2C (в виде SMBus) и SPI есть на любом CPU и SoC производства Intel последних 5 лет? А еще можно поставить на плату копеечный МК на Cortex-M и получить все то же самое, только дешевле и с лучшей поддержкой со стороны ПО.
Получилось немного сумбурно, прошу меня извинить, тоже редко пишу по-русски.
Хочу сказать огромное спасибо за открытый код UEFI для Galileo (как раз пишу цикл статей про него в данный момент: раз, два, три, четвертая часть на подходе), очень жду открытия UEFI для Minnowboard MAX, обещали в сентябре, но вмешались "unforseen changes". Спасибо также за первый на моей памяти JTAG TAP для x86 без NDA и за $20 вместо $5000, теперь можно писать и отлаживать baremetal OS, не заключая контрактов.
Удачи вам, всей IOTG и другим ребятам из ED. Ровно одно пожелание для всех вас от простого инженера: обратите внимание на поддержку своих продуктов со стороны ПО, желательно еще до их выхода. А то ведь Galileo уже почти год как выпущен, а репозиторий для opkg появился только сейчас, аппаратные интерфейсы на SoC есть — драйверов для них нет, и так далее. А то получается продуктивнее просто сказать, что на наших платах нет поддержки CSI2, CAN и HSUART, чем приводить их Proof-of-Concept-драйверы от Intel в пригодное для клиентов состояние. За любой сдвиг в этом направлении — охапку лучей добра вам заранее.
+3
Спасибо огромное за длинный, годный комментарий. Я переведу и покажу коллегам в IOTG и NDG. (Можно будет как-нибудь развиртуализоваться, как я буду в очередной раз в Деггендорфе навещать, как я догадываюсь, вашего работадателя на букву C или K)
Буду отвечать по очереди, постепенно. Баг с локом — не единственная причина отсутствия Дебиана. Еще он не так страшен, как вы описываете. Там не постоянные сегфолты, а редкие и неожиданные. Хрен редьки не слаще, конечно. Главная проблема скорее организационная — пока нет в quark patch в апстриме, мейнтейнеры debian не будут рады такому таргету. Ну и на 586 все перекомпилировать действительно плохо.
Буду отвечать по очереди, постепенно. Баг с локом — не единственная причина отсутствия Дебиана. Еще он не так страшен, как вы описываете. Там не постоянные сегфолты, а редкие и неожиданные. Хрен редьки не слаще, конечно. Главная проблема скорее организационная — пока нет в quark patch в апстриме, мейнтейнеры debian не будут рады такому таргету. Ну и на 586 все перекомпилировать действительно плохо.
+2
Пожалуйста, хорошо, что сейчас можно вот так просто взять и написать непосредственно разработчикам. Будете в офисе Congatec Deggendorf — заходите в отдел R&D, буду рад познакомиться лично.
Баг с локом не страшный, но неприятный, и проблема именно в его внезапности. Можно обновить glibc на непатченый и пару суток с ним работать без сбоев, а потом очередной вызов чего-нибудь из pthreads внезапно упадет и приехали. Я пробовал запустить Debian i386 через debootstrap, работает, но необходимость постоянно проверять, не пришел ли новый glibc с каждым обновлением — она напрягает, так что Yocto наше все в данный момент.
Еще одна хотелка, если можно: выложите Quark_EDK2 куда-нибудь на GitHub, чтобы можно было прозрачно его форкнуть, поправить и выслать пулл-реквест. А то, к примеру, все танцы вокруг spi-flash-tools и sysimage можно было бы пропустить, достаточно лишь правильно написать файл QuarkPlatformPkg/QuarkPlatformPkg.fdf. Я уже начал это делать для 4 части моей статьи, потому что разработка DXE-драйверов подразумевает постоянную пересборку образа UEFI, а проходить каждый раз через не самый простой процесс его сборки для Galileo, даже при наличии скрипта — то еще удовольствие.
Баг с локом не страшный, но неприятный, и проблема именно в его внезапности. Можно обновить glibc на непатченый и пару суток с ним работать без сбоев, а потом очередной вызов чего-нибудь из pthreads внезапно упадет и приехали. Я пробовал запустить Debian i386 через debootstrap, работает, но необходимость постоянно проверять, не пришел ли новый glibc с каждым обновлением — она напрягает, так что Yocto наше все в данный момент.
Еще одна хотелка, если можно: выложите Quark_EDK2 куда-нибудь на GitHub, чтобы можно было прозрачно его форкнуть, поправить и выслать пулл-реквест. А то, к примеру, все танцы вокруг spi-flash-tools и sysimage можно было бы пропустить, достаточно лишь правильно написать файл QuarkPlatformPkg/QuarkPlatformPkg.fdf. Я уже начал это делать для 4 части моей статьи, потому что разработка DXE-драйверов подразумевает постоянную пересборку образа UEFI, а проходить каждый раз через не самый простой процесс его сборки для Galileo, даже при наличии скрипта — то еще удовольствие.
0
К сожалению я уже в другой команде, но даже раньше я отвечал за содержимое git.yoctoproject.org/cgit/cgit.cgi/meta-intel-iot-devkit/ — все открыто в гите, но начинает грузиться после груба.
+1
>Intel очень хорошо умеет делать железо, но не очень хорошо умеет делать ПО.
к сожалению, формат нашего общения не предрасполагает к обсуждению причин распространенности такого мнения, но при личной встрече (if ever) обсудим.
> разница между Intel и другими специалистами рынка Embedded вроде TI или ST — огромная.
У Intel embedded продуктов есть огромный плюс, но он же и минус. Практически все они — суть доработки dekstop/mobile/server процессоров-чипсетов. Это позволяет использовать мощный R&D и manufacturing process, но поэтому нет такого фокуса только на этот сегмент, как у компаний, у которых он единственный. Поэтому приоритет фич, нужный для embedded — далеко не первый.
к сожалению, формат нашего общения не предрасполагает к обсуждению причин распространенности такого мнения, но при личной встрече (if ever) обсудим.
> разница между Intel и другими специалистами рынка Embedded вроде TI или ST — огромная.
У Intel embedded продуктов есть огромный плюс, но он же и минус. Практически все они — суть доработки dekstop/mobile/server процессоров-чипсетов. Это позволяет использовать мощный R&D и manufacturing process, но поэтому нет такого фокуса только на этот сегмент, как у компаний, у которых он единственный. Поэтому приоритет фич, нужный для embedded — далеко не первый.
+1
>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 — это уже портировать. Может повести, и хорошо написанная софтина портируется простой перекомпиляцией. Но везет не всегда.
вычислительное ядро внутри Quark начинался как scunkworks/research проект, и во-многом использовался 486, в который удалось поместить 586 инструкции, но 686 уже нет. Как и у Atom с Core есть roadmap, в котором ваши замечания к первому представителю этого семейства CPU учтены.
С i686 на i586 — именно пересобрать, и результирующий бинарник работать будет хоть на Xeon'е. А с i686 на ARM/MIPS — это уже портировать. Может повести, и хорошо написанная софтина портируется простой перекомпиляцией. Но везет не всегда.
+1
А всего-то systemd вместо sysvinit.
А вы не думали о OpenRC? А то меня пугает этот bloatware ну и OpenRC вроде приятнее допиливается/портируется.
Как минимум для embedded это должно быть важно.
+2
О, вопрос номер три. Да, лично я предпочитал OpenRC когда мы обсуждали это в команде, но остальные убедили меня, что раз у нас не совсем embedded платформа, а почти PC, то можно сделеть вид, что мы обычный дистрибутив, а они все перешли на systemd, поэтому скоро пользователям станет привычнее, и решения проблем будут гуглиться.
0
Спасибо за обзор!
Не подскажете новичку — смогу я работать с этим набором, имея обычный компьютер (на Windows или Linux), без Arduino или Edison?
Интересно, т.к. разбираюсь с платформой ThingWorx, и хочется с железом поиграться.
Не подскажете новичку — смогу я работать с этим набором, имея обычный компьютер (на Windows или Linux), без Arduino или Edison?
Интересно, т.к. разбираюсь с платформой ThingWorx, и хочется с железом поиграться.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Содержимое Intel IOT development kit