jcxz

Почему "с нуля"? У ТС-а уже есть своё ПО (в котором работает I2C-слэйв). Так что самое простое и удобное для отладки (при отсутствии готовых решений) - реализовать мастер в этом же самом ПО на этой же самой железке (пара ног свободных думаю найдётся?). И отлаживать мастер через те же механизмы, что и вся железка. И тогда ни на PС ни на каком другом МК ничего дополнительного писать не придётся. Тем более, что раз ТС сейчас как раз разбирается с I2C, то и написать мастер на той же периферии того же МК по "горячим следам" будет легко.

Разница в том что запрос на прерывание (если он был) продолжает храниться в pending-регистрах. И активируется сразу после размаскирования.

Быстрее. Только через ICER - это не запрет, а маскирование.

Существует. Запрещаете прерывания Вы в периферии (таймере). А если он уже сформировал запрос прерывания (ещё необслуженный), то этот запрос уже защёлкнулся в NVIC. И тогда прерывание произойдёт как только будет: снят глобальный запрет прерываний && снята маска прерывания с данного вектора NVIC && текущий приоритет прерывания понизится ниже чем у вектора этого таймера. Чтобы не произошло, нужно маскировать вектор прерывания через NVIC. Ну или очищать ждущее прерывание после его запрета в периферии. Т.е.: 1) запрет в периферии; 2) DMB; 3) очистка в NVIC.

Вангую у ТСа внутри version() и md5_checksum() есть объекты класса CString в локальной памяти (на стеке). И он возвращает указатели на них. От которых потом берёт c_str().

А если делать и не нужно было. А Вы притащили свой надувной матрац и угробили им кого-то, кто в этом даже не нуждался? PS: Хуже бездействующих, могут быть только инициативно-креативные дилетанты.

"Может"? Опять фантазируете о содержимом "чёрного ящика". Может != должно. Вы не знаете как этот ящик устроен внутри. А внутри может быть что угодно и URC могут генериться другими задачами, параллельными задаче парсера входных команд. Или приведите ссылку на документ где указано обратное. Для подобных рассуждений мне вполне достаточно моего опыта разработки для разных AT-командных модулей, в том числе и SIMCOM. И я на практике видел то, о чём пишу (URC может прийти в любой момент обработки команды). Также я умею читать документацию (в отличие от Вас видимо), в коей нигде не упоминается ни о какой мифической атомарности. Поздравляю вас с таким вселенским открытием. Хоть что-то прочитали. Вам осталось ещё научиться мануалы читать... Так где всё-таки про атомарность указано в описании AT-команд SIMCOM?

А при баге в этом самопальном чуде, все эти 4 атмосферы жахнут в лёгкие жертве пациенту.

Конечно! 1 день (разработка) + 1 день (сертификация).

И что? А как по вашему оно может выполняться?? До символа '\r' (или '\n') модуль выполнять ничего не должен. А значит он должен где-то накапливать чтобы выполнить потом. Или вы можете предложить другой разумный алгоритм? Думаете что эти байты накапливаются не в буфере, а в проводах UART-а и там ждут '\r' или '\n' чтобы сразу вылезти в модуль из проводов и атомарно выполниться? Вобщем ясно - конструктивно разговаривать Вы не умеете, аргументов привести не можете, конкретные вопросы игнорируете и всё сводите на детский уровень "дурак - сам дурак". Разговаривать с вами далее в таком русле не вижу никакого смысла. Имеющий уши уже давно услышал, имеющий голову - понял. PS: Мнимой атомарности нет даже при выполнении одиночной команды, не то что строки команд. Так что лепить их в строку - занятие бессмысленное, если затеяно ради этого.

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

Я ничего не фантазировал и не выдумывал по поводу того, что там делается в чёрном ящике. Я предполагаю что там делаться может что угодно (в том числе и длительное ожидание каких-то событий). И нигде не писал никаких фантазий типа: в отличие от Вас. Так что не надо перекладывать с больной головы на здоровую! PS: И всё-таки: продолжаем ждать от Вас - где именно, в каком документе сказано про атомарность выполнения команд, переданных одной строкой?

Не говорите ерунды - выполнение AT-команд это не "сохранение десятка переменных в оперативке". Странные у вас представления о работе GSM-модуля... И насчёт некой "атомарности" выполнения цепочек команд - это ничем не обоснованные фантазии. Или приведите документ где об этом сказано.

Ну если vid/pid нельзя менять - так не меняйте. Ставьте драйвер на какие ставится. Винда привязывает драйвер к устройству не только по VID/PID, но и по серийнику. А его можно сделать любым.

Почему думаете что 9600? Лучше попробовать перебрать все скорости. Мои например при переходе в командный режим, работают на 38400.