Для кого как

Зависит от кристалла.

bear metal programming

Если я правильно понял, то собираешь кросс-компилером, а потом заливаешь на железку, так?

Ъ

beer, metal, programming

Если я правильно понял, то собираешь кросс-компилером, а потом заливаешь на железку, так?

если процессор с толстеньким ядром ARM, открываешь еррату на процессор и охереваешь как он вообще работает. Короче для микроконтроллеров обычное дело без ОС, для application processor - без ОС конкретный геморой получишь.

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

Да. Но настоящего хардкора сейчас уже не встретишь.

Думаю это очень перспективно. Сейчас 90% всего уже работает на виртуалках и ещё один уровень абстракций в виде ОС уже не очень нужен. Думаю скоро появятся фреймворки позволяющие писать приложения без ос для запуска в гипервизорах и прочего...

меня эта история конечно впечатлила, когда я её прочитал, но если рационально рассуждать, аффтар должен был просто послать заказчика, «берите новый процессор и переделывайте всю партию, ниибёт»

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

Что входит в начальный уровень? Мне кажется с этим у меня всё в порядке вроде.

По описанию очень напоминает программирование PLC.

закон Ома, законы Кирхгофа, знать про индуктивность, ёмкость и сопротивление в цепях переменного тока, как работают транзистор и диод, основы цифровой электроники - триггеры, шины и всё такое

Уже давно

https://mirage.io/

Интересненько.. значит будет что вспомнить, подучить, если что. Короче шлю резюме )

Зависит от задачи. Бибикать и мигать светодиодом — просто, очень просто.

Что вы об этом думаете?

Bare-metal programming вполне себе востребован много где

Насколько это хардкорно?

Если есть нормальная среда разработки с дебаггером и поддержкой нужного железа то ничего особо сложного тут нет

В применении к Linux можно здесь посмотреть до чего дошла наука

http://www.wiki.xilinx.com/Multi-OS Support (AMP & Hypervisor)

а с прошлой работой что?

а с прошлой работой что?

Пока работаю, но не совсем понятно, что будет с компанией через 2-4 месяца, поэтому присматриваюсь )

Если есть нормальная среда разработки с дебаггером и поддержкой нужного железа то ничего особо сложного тут нет

Т.е. компилер не всегда будет под онтопик получается. В зависимости от железа также.

Да не особо оно хардкорно...

Думаю скоро появятся фреймворки позволяющие писать приложения без ос для запуска в гипервизорах и прочего...

Называются «контейнеры».

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

А, да, тебе ещё нужно будет чутка асмового кода, который тебе настроит стек для сишечки.

закон Ома, законы Кирхгофа, знать про индуктивность, ёмкость и сопротивление в цепях переменного тока, как работают транзистор и диод,

как интересно ... где это использовать при программировании?

Звучит бредовенько.

Речь о SoC-ах? Не особо хардкорно, если не нужно заново писать дрова для переферии. Подготовка окружения и инициализация процессора и памяти не на много сложнее, чем для микроконтроллера (с учетом того, что сейчас микроконтроллеры пошли похлеще СоКов). Особенно, если есть IDE от производителя.

где это использовать при программировании?

при программировании, очевидно

процессор, который программируется, не в воздухе висит, а к какому-то реальному железу подключён, нужно иметь представление, как оно работает, что будет, когда ты запишешь единичку или нолик в какой-нибудь регистр или прочитаешь его оттуда, знать, что переходные процессы происходят не мгновенно

короче перечислять долго

закон Ома, законы Кирхгофа, знать про индуктивность, ёмкость и сопротивление в цепях переменного тока, как работают транзистор и диод, основы цифровой электроники - триггеры, шины и всё такое

Мне кажется это не обязательно. Сейчас в схемах очень редко можно встретить одиночные триггеры. А уж индуктивностей в пути прохождения сигнала (с точки зрения программиста) вообще не бывает. Важнее уметь читать даташиты. И иметь хорошую память или пару дополнительных мониторов :)

А уж индуктивностей в пути прохождения сигнала (с точки зрения программиста) вообще не бывает.

почему не бывает, а длинные проводки на высоких частотах? :)

Важнее уметь читать даташиты.

А в даташитах что обычно, схема подключения обвязки, режимы работы (напряжения, токи, температура), блок-схемы всего девайса или отдельных его компонентов (где триггеры как раз присутствуют), и как это всё будет читать программист без элементарных знаний по части электроники?

Контейнеры это не то, слишком медленно и что самое главное ось есть. А я говорил про запуск блоба без каких либо внешних зависимостей допустим в kvm или xen.

kvm — подсистема ядра линукс. И чем XenServer не ОС? Памятью рулить умеет, устройствами тоже.

Есть разные задачи в довольно широком диапазоне: от «инвертируй состояние пина по прерыванию таймера и усни» до ЦОС на DSP.

bear grills metal...
Настолько сурово, что в микросхемы прямо скармливается НЁХ код.
от чего те плавятся и втекают.

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

А, да, тебе ещё нужно будет чутка асмового кода, который тебе настроит стек для сишечки.

Обычно все-таки есть что-то типа Freescale Codewarrior или Xilinx Software Development Kit которые включают Board Support Packages для большинства чипов производителя — необходимые библиотеки в том числе для инициализации и доступа к перефирии

С железом для которого этого нет я бы без крайней необходимости связываться не стал

нет, это не называется «контейнеры».

в общем-то такого уже не мало есть, но пока хипа вокруг какого либо из решений не возникло.

почему не бывает, а длинные проводки на высоких частотах? :)

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

А в даташитах что обычно, схема подключения обвязки, режимы работы (напряжения, токи, температура), блок-схемы всего девайса или отдельных его компонентов (где триггеры как раз присутствуют), и как это всё будет читать программист без элементарных знаний по части электроники?

Элементарные знания желательно иметь, но достаточно совсем элементарных. Даже закон Ома далеко не всем нужен. Работал со мной программист, который себя позиционировал низкоуровневым, закон Ома не знал, но с работой справлялся нормально. Конечно, приходилось ему объяснять некоторые вещи, но на то он и программист.

Конечно. Я утрирую. Речь о том, что ту же задачу можно достичь с помощью контейнеров, получив ещё меньший оверхед.

Сам посуди. Гипервизоры — это виртуализация железа. Поверх него в любом случае нужны своего рода драйвера (хотя бы TCP/IP-стек, управление памятью и так далее), и каждый инстанс каждого приложения, работающего без ОС внутри виртуалки, будет вынужден таскать их с собой. Операционные системы какбэ не просто так придумали.

Ну или я совершенно не понял, что хочет itn.

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

А зачем тогда отдельный программист нужен, железячник и сам сможет пару инструкций ассемблера накидать или простую программу на С сделать, проще и быстрее будет чем такому сферическому программисту объяснять что-то. Обычно так и происходит

Под онтопик вменяемых бесплатных IDE нет вообще. Можно конечно и в вим писать асм и знать состояние регистров, стека, памяти и вообще всей железяки, но это хардор тот еще. Придется ставить венду.

+

Можно конечно и в вим писать асм и знать состояние регистров, стека, памяти и вообще всей железяки, но это хардор тот еще. Придется ставить венду.

Для языка ассемблера есть хоть чем-то полезная IDE?

Что вы об этом думаете? Насколько это хардкорно?

Разработка ОС - это крайне интересный раздел программирования.

как работают транзистор и диод, основы цифровой электроники - триггеры, шины и всё такое

ну и как работает этот, мемристор, например??

гы. есть такой Мараховский Л.Ф. Основы теории синтеза цифровых устройств на схемах автоматной памяти : монография.

так вот, там он пишет, что вы все дураки и не лечитесь, а я тут на белом коне тыгдым-тыгдым... начиная с триггеров, тактовых генераторов и синхронщины всё не туда пошло...

в общем, вводит новые блоки для асинхронных схем, начиная с триггеров и своих особенных автоматов с памятью.

всё у него круто получается, правда вывод — всю современную индус-трию надо нафиг переделать заново, асинхронно. ибо синтез с библиотеками элементов надо переписать заново, асинхронно.

всего-лишь, лолъ.

colorforth с асинхронщиной и зелёночипом (GreenArrays, Inc) рулит )))

как интересно ... где это использовать при программировании?

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

вот понадобилось тебе например производные посчитать или интегралы — а ты такой бац, физические законы приспособил.

и схема сама перепрограммировалась под новую конфигурацию, ога-ога. :-))

Для языка ассемблера есть хоть чем-то полезная IDE?

состояние регистров, стека, памяти и вообще всей железяки

Мониторинг всех частей железки в реальном времени присутствует в любой ide от производителя железок (мк) + дебаггер ессно. Некоторые из них даже бесплатные, но с ограничениями, например, на объем кода.

В итоге один хрен приходится во всё это лезть. Рано или поздно. В моём случае крайне редко.

Вендорские библиотеки и SDK бывают написаны через такую задницу, что их даже трогать неохота - пример Ralink. Контрпример - TI, у этих более-менее прилично.

vim + openocd/mspdebug + gdb + make = вполне удобоваримая замена для вендорской IDE, при условии что вышеуказанный софт поддерживает железо.

Что для ассемблера, что для си. А если на железке крутится линукс - то вообще похрену/

ТС, ты пробовал для начала микроконтроллеры с ядром ARM? Может ты про x86, но учитывая что вместо Linux можно работать напрямую на железе, то чем это не bare metal?

А зачем тогда отдельный программист нужен, железячник и сам сможет пару инструкций ассемблера накидать или простую программу на С сделать

Далеко не все железячники это умеют.