Arlleex

STM нормально никогда не делали особо. Они сделали в старших сериях чуть получше, ИМХО, но не идеально. Собственно, только поллить. Я делал и на прерываниях, и на прерываниях + DMA. Года четыре назад, когда первый раз писал драйвер I2C под STM32F4, нахлебался косяков в работе этого поделия, в том числе таких, при которых модуль повисал намертво до полной перезагрузки его через RCC-регистры. И никакие серии стоп- или -старт-бит не помогали, только сброс через RCC и полный реконфиг. А не так давно снова пришлось поддерживать I2C под этот камень, но тут я сделал немного по-другому: транзакции и управление состоянием автомата I2C по-прежнему в прерываниях, транзакции данными по DMA, но вся посылка (или некоторые ее части) обрамляется таймерным сторожем. На картинке пример. Так начинается транзакция. В момент (1) происходит запрос на формирование START-условия. Дальше, если тупо поллить, в программе будет бесконечный цикл ожидания установки флага, сигнализирующего о том, что условие сформировано на шине (но я не поллю). А если по прерываниям делать, то поллить не надо и мы влетаем (2) через какое-то время в обработчик, и делаем следующий шаг (3) в алгоритме I2C-автомата - отправляем аппаратный адрес микросхемы. Ну дык вот. Таймер у меня в момент (1) заряжается на интервал, который чутка больше по времени между событиями (1) и (2). Формирую START и запускаю таймер. В ISR I2C, как только обнаружил START-ack (бит SB регистровой модели I2C STM32F4), таймер останавливаю. Теперь надо отправить адрес микросхемы, но до этого рассчитываю интервал таймера на чуть больше времени передачи одного байта; отправляю адрес и запускаю таймер. И так по всему циклу автомата. Если хоть где-то выстрелит прерывание по таймеру, это будет значить, что произошла какая-то лажа на шине - в этом случае я сбрасываю транзакцию, уведомляю необходимые потоки RTOS об этом и перезапускаю периферию. А там что?

В свое время тоже пытался сделать обмен чисто на прерываниях, только окончание прошлой транзакции я оценивал по биту BUSY. Сейчас глянул в исходник - все на прерываниях, кроме злосчастного поллинга BUSY перед началом передачи. Западло, однако... P.S. Интересно снять осциллограмму в случае, когда выставляется STOP и сразу же осуществляется попытка передать START - возможно, контроллер I2C корректно обработает эту портянку и надобность в поллинге отпадет.

Использовал ADuM240/ADuM242 в своих проектах, полет нормальный. Правда, при монтаже, лучше их запаять и больше не лазить туда руками - а то у меня так парочка вышла из строя.

Что ж сразу не сказали, что симулятор использовали. Так до бесконечности можно гадать. Соберите в железе, ИМХО, будет все работать.

Ну чисто беглым взглядом в Datasheet (стр. 208): Не оно?

Настоятельно рекомендую потренироваться на доноре. Как правило, все идет как по маслу лишь когда рука набита, иначе - С нижним подогревом и паяльником с тонкопроволочной оплеткой очень даже неплохо получается, как тут уже писали.

Ну вот ассемблером я иногда, все же, пользуюсь. Редко, конечно, относительно основного кодирования, но, бывает. ИМХО, каждый работает с тем, с чем ему удобнее. Главное хорошо разбираться в своем же творческом беспорядке

Помнить, чем там отличается C++11 от C++14, и в свою очередь, чем от них отличается C++17... А через год, глядишь, и опять разбираться придется; либо, впопыхах впихивая новые фишечки, старое компилиться перестанет А тот же C99 уже как бэ не девочка и для разработки под МК его более чем хватает. Впрочем, дело вкуса.

Попутно вопрос тем, кто поддерживал HTTP на МК: протокол программировали сами или пользовались готовым стеком от, например, LwIP?

Я обычно заостряю внимание на сам факт необходимости в "человеке-оркестре". С ЗП вопрос, конечно, интересный. Ну а разве человек с четкой специализацией не должен разбираться в той массе технологий, с которыми, возможно, он не знаком еще даже? С теми технологиями, с которыми ему предстоит еще познакомиться, чтобы иметь принципиальную возможность откликаться на подобные объявления о работе? Как мне кажется, работодатель зачастую предполагает, что программист МК, это человек, который пишет что-то в регистры и иногда читает что-то из внешних микросхем. Ну, может лет 20 назад так и было. Логично, что ему кажется, что работа не шибко сложная и зарплату ему стоит платить на уровне дворника. Сейчас же программист МК уже по своей сути является человеком-оркестром - он, не сильно парясь, изучает различные технологии смежных областей информатики, систем телекоммуникаций - потому что надо. Потому что кого сейчас удивишь мигающим светодиодом, когда Китай штампует чайники с Wi-Fi-ем? А обывателю (да тому же работодателю) такие технологии уже изначально кажутся примитивными. Поэтому он требует бОльшего. А работодатель еще и доплачивать не станет, ибо "какой ты специалист, если за пять минут мне веб-морду не набросал; вон, гляди, китаец делает и не особо возится".

К сожалению, лично я вижу кардинальное снижение востребованности хороших узконаправленных специалистов. И в большинстве случаев нужны люди, которые "и швец, и жнец, и на дуде игрец". Далеко за примерами ходить не надо - почти каждое сообщение в разделе "Предлагаю работу" прекрасно отражает данный факт. Сам я отлично понимаю, что стать во всех специализациях профессионалом не хватит и жизни. Но изучать что-то новое, расширяя свой кругозор, сейчас куда важнее. А, ИМХО, программируя только микроконтроллеры и не понимая, как работает взаимосвязь с внешним современным миром (в том числе миром веб-технологий), особо не разгуляешься - современному программисту МК платят хорошие деньги вовсе не за "светодиодом помигать". Поэтому программист МК, кроме профессионализма в низкоуровневом слое, должен знать и понимать, как ему эту железку совместить с теми технологиями, которые есть в смежных сферах (в данном случае это веб-технологии). Не спроста же ведь специалисту, которому знакомы слова TCP/HTTP и т.д. не понаслышке, в карман прилетает больше, чем тому, кто об этом даже не хочет слышать. Поэтому приходится разбираться и с платами, и с программированием под МК, и с программированием под ПК (чтобы тестовые утилиты писать, прежде чем отдавать железку разработчикам прикладного ПО на ПК (если вообще этим самым программистом, опять же, не являешься ты сам)), и с веб-программированием хотя бы на начальном уровне, для того, чтобы "въехать" и чтобы, будучи потом (возможно) руководителем, не дать ездить по ушам ушлым "специалистам", высасывающим все деньги за десяток строчек кода в квартал Хороший специалист, ИМХО, и это тот, кто понемногу разбирается во всем (при этом не сильно углубляясь в подробности), но отлично разбирающийся в каком-то одном направлении. Для которого не составит большого труда досконально разобраться в чем-то новом для себя - вот это действительно важно.

Как раз сам начал изучать связку HTML/CSS/JS/Ajax для более комфортного ощущения себя в веб-дизайне (в том числе и для приложений на МК). Стоит один раз прошить МК из смартфона через браузер, как назад пути уже нет...

Случай действительно забавный, но реальный

Ну вот определитесь, что Вам нужно. А то до setjmp/longjmp так дойдем.

Еще раз: если аппаратура МК имеет физическую реализацию вектора прерывания, то Вы вправе делать с этим вектором что угодно и описывать его как заблагорассудится. Если вектора нет - Вы должны описать его как пустое пространство (например, с помощью директивы DCD 0) и не иметь попыток доступа к этому вектору любым способом, потому что это вызовет, скорее всего, какой-нибудь fault, эскалирующий до HF при возможности. Резюме: Вы можете сформировать программный запрос на любое прерывание, физически выведенное на NVIC.