Pull to refresh

Comments 20

Я так и не понял, можно ли его программировать и прошивать через JTAG? Мне хотелось бы изучить архитектуру, поработать напрямую с прерываниями, а не использовать Linux API, к примеру.
У него есть 10 pin JTAG. Intel System Studio поддерживает его через переходник на Intel JTAG, а потом нужен еще и Intel JTAG (или Macgraigor). Достаточно дорого, к сожалению.

Без отладчика можно baremetal/efi/grub разрабатывать и сейчас.

Мы скорее всего летом выпустим baremetal примеры. Я был удивлен, что очень многие хотят использовать baremetal. Интересно, почему?
Только что поговорил с нашим разработчиком jtag, он сказал что можно при помощи openocd и ftdi адаптера дебажить.
здесь есть ссылка на то, как приладить jtag к galileo без Intel XDP Jtag.
Если вдруг разработчику захочется поставить более функциональный дистрибутив Линукса, то сборка и конфигурация займет несколько часов.

Это вы хорошо пошутили. Не забудьте дописать что i5 минимум и памяти тоже побольше надо. А то иначе это займет не пару часов.
Да, у меня заняло 3 часа на моей рабочей станции. Старенький Xeon-EP Sandy Bridge…
Sandy Bridge то даа сильно старенький :)
Можно я задам, наверное, очень глупый, но подозреваю, крутящийся не у одного у меня в голове вопрос — в чем selling point этого направления Intel? Какие для меня, как для разработчика, плюсы перехода с ARMовых Arduino на Galileo?

Я пока вижу один и то, относительно призрачный — наличие шин вроде PCI/PCIe.

Поправьте меня, но по всем остальным направлениям с точки зрения массмаркета все будет относительно плохо ведь? Дешевизна в mass production — сильно вряд ли, сомневаюсь, что в планы Intel входит побить китайские ARMы ценой. Удобство разработки — весьма относительное. Быстродействие — о нем речь как таковом не идет. Сверхминиатюрность — тоже нет, Quark относительно большой. Потребление — на уровне с аналогичными ARMами, а никак не на порядок лучше. Я, видимо, как-то не так понимаю, для чего это все?
Эм. Вообще говоря это скорее конкурент RasberryPi и его аналогов, нежели Arduino. К примеру на борт можно засунуть полноценный linux и писать под него.
да, там, где не нужна графика — собрать данные с сенсоров — датчиков, обработать, послать наверх. или мозги не очень продвинутого робота.
Внезапно, на Arduino ARM — тоже почти полноценный Linux и все возможности писать под него. Плюс shield'ы, куча вводов-выводов, JTAGи и все такое.

Пока у меня складывается впечатление о том, что Intel пытается изо всех сил запрыгнуть на уходящий поезд, и получается как-то загадочно. Да, проделали огромную работу в попытке догнать ARM, но в итоге каких-то сверхкрутых плюсов пока толком и нет.

Сейчас Intel попытается продавить это все маркетингом, чтобы за счет весьма дешевых железок попытаться создать какую-то движуху и коммьюнити вокруг Galileo — посмотрим, получится ли. Если честно, что-то сомневаюсь.
Пусть Tre сначала выйдет, тогда посмотрим, что там с конкуренцией. Или вы имеете в виду Due?
Да я, собственно, и не пытаюсь так сильно сравнивать с Arduino. Из того, что я вижу по поводу ARMовых Arduino — тот же Due по сути играет совсем на другом поле, нежели предыдущие AVRовские Arduino — и в 99% случаев его используют, как еще-один-девборд-на-каком-то-там-не-очень-мощном-и-весьма-generic ARM, нежели что-то самоценное.

Что будет с Tre — действительно, еще посмотрим. Но что-то мне подсказывает, что перевернуть сознание людей, делающих железки на «давайте у нас будет два процессора — один для высокоуровневого менеджмента, другой для низкоуровневого управления какими-то там контактными группами» — это еще сильно не факт, что выйдет.

Я-то, собственно, и не ратую как бы особенно за Arduino. Грубо говоря, из того, что я сейчас вижу — у тех, кто занимается железками — де факто в подавляющем большинстве случаев проще и дешевле приобрести готовый дизайн законченного блока (который будет либо на ARM, либо на MIPS), чем делать что-то совсем уникальное свое на универсальной платформе. Особенно если мы говорим о той самой зоне плюс-минус шаг вправо-шаг влево, которая несколько выходит за базовые возможности.
Эм. На текущий момент нет. В Due стоит M3 туда linux запихать невозможно, слишком мало памяти.
> призрачный — наличие шин вроде PCI/PCIe
Да, вся PC перефирия на USB/PCIe работает из коробки, драйвера для Linux/x86 — наиболее стабильные/оттестированные.

> Удобство разработки — весьма относительное
Наша команда будет стараться, чтобы превратить это в важное преимущество.

По предыдущему пункту, разработка для embedded как на PC, используя все возможные PC development perks — python/node.js, labview/mathalb, библиотеки типа opencv, и тд в этом духе может быть преимуществом. В последние года софт экосистемы ARM серьезно продвинулась в этом направлении, но еще не совсем догнала PC.
Да, вся PC перефирия на USB/PCIe работает из коробки, драйвера для Linux/x86 — наиболее стабильные/оттестированные.

Вот здесь позволю себе определенный скепсис. Если взять какие-нибудь NVIDIA / ATI (AMD), то уже не единожды натыкались на то, что, скажем, драйверы, которые якобы собраны для x86, на практике даже на Atom работают либо сильно медленнее тех же драйверов, но на современных i3 / i5, либо, в худшем случае, не работают вообще (видимо, если очередную версию кто-нибудь сильно умный соберет с какой-то оптимизацией и инструкциями, которые есть только на Core).

С менее consumer-железками, например, типа тех же гигагерцовых многоканальных осцилографов — там проблема будет, боюсь, будет банально в том, что поддержки Linux зачастую нет вообще никакой. Плату продают вместе с соответствующим софтом, который Windows-only — и все.

Год назад, например, я делал проект, в котором нужна была плата видеозахвата на много камер и много одновременных FPS. Пытались сделать маленькую коробочку на Atom + одна-две PCIe плат. Перепробовали штук 5, в итоге плюнули и просто закупили готовых китайских видеорегистраторов на ARMах и похакали им прошивку, чтобы выполнять наш специфичный workflow. Плохо все было и с драйверами, и с производительностью для наших задач, и с доступностью железок и т.д.

«Про разработку для ARM» — боюсь, что ничем из вышеперечисленного особенно не удивишь. И языки / фреймворки практически любые на Linux под ARM запустятся и будут вполне работоспособны, и opencv работает и т.п.

Labview — возможно, будет неким selling point, но это примерно как с PCI — во-первых, так ли там все гладко, во-вторых, настолько ли многим оно нужно?
>драйверы, которые якобы собраны для x86, на практике даже на Atom работают либо сильно медленнее тех же драйверов, но на современных i3 / i5
а на galileo будет еще медленнее, чем на Atom, увы. Инструкции, которых нет на Atom/Quark — в-основном SIMD, которые в kernel mode драйверах обычно не используют.

>гигагерцовых многоканальных осцилографов
У quark на такое мощИ не хватит, конечно. Как и у бОльшей части ARMов.
Ну, собственно, поэтому смысл использовать производительные потоковые PCI-e карточки — какой-то призрачный. К сожалению, видимо, в драйверах видеокарточек такие части есть.

Про осцилографы — мощь там и не нужна. Там по сути отдельный компьютер-в-компьютере. Я помню, что игрался с четырехканальным гигагерцовым осцилографом лет 7-8 назад — прекрасно работало чуть ли не на хосте с Pentium 3 и Windows 2000. У нее собственная память и обработчики внутри, скорость компьютера влияет только в одном случае — когда пойманный массив или какие-то его производные начинаешь сгружать на хост — но в этом случае зачастую все упирается в производительность HDD, а совсем не процессора. Думаю, что оно прекрасно работало бы и на Atom, и на Quark, только, возвращаясь к началу разговора, энтузиастов покупать железки по 40-50K$, а потом реверсить их и писать драйверы под Linux — видимо, нет.
Вы используете стандартный openembedded. Все что собирается им под x86 так же спокойно собирается под ARM. Это основная фича. Ну разве что вы отдельный layer сделаете с фичами для gallileo
да, yocto сейчас работает практически одинаково на arm и x86 платформах. Но PC перефирия просто более оттестирована на x86, багов меньше.
Sign up to leave a comment.