Лидеры

Дело в том, что результат оператора ! для нулевого аргумента четко определен в стандарте и это ровно единица типа int.

Так сохранятель в прошивке - тоже знает их положение. Единственное, чего у него нет: elf-образа. Чтобы разрисовать красиво. Но если ТС будет при каждой перепрошивке устройства сохранять в свою энергонезависимую память и elf - то у него будут все возможности отладчика. PS: Другое дело, что это - нафик не нужный сизифов труд. Многие годы уже сохраняю в энергонезависимую память стеки критических ошибок. В разных проектах. И ни разу мне не приходило в голову эмулировать "Call stack" отладчика. У меня уже лет 15 примерно так выглядит дамп ловушки критической ошибки: И мне его хватает для "раскрутки".

jcxz прав, EW430-8102 действительно позиционируется как 64-разрядная версия. Однако меня сильно заинтриговал тот факт, что компилятор у топикстартера компилирует нормально, а стало быть, патчер "iarpatcher32 v1.16" его ухитрился вылечить. А поскольку этот патчер я сама писала :), то равнодушно пройти мимо этого факта никак не могла. И вот что выяснила. Компилятор IAR EW430 v8.10.2 оказался из ряда вон выходящим - он позиционируется как 64-разрядный (и в соответствии с этим инсталлируется в "Program Files"), однако компиляторы с языков C/C++ (icc430.exe) и ассемблера (a430.exe) у него 32-разрядные. Такое я встречаю впервые. Однако это первая 64-разрядная версия для MSP430, а потому весьма вероятно, что что-то не успели к сроку доделать и закрутили в инсталлятор их 32-разрядные варианты. Именно поэтому компиляция у топикстартера идет (32-разрядный компилятор вылечился), но при отладке dll-модули (для каждого из отладчиков) требуют лицензию, поcкольку все эти dll - 64-разрядные. В этой ситуации я могу посоветовать вернуться на предыдущую версию из 7-ой серии (EW430-7211-Autorun.exe), которая еще на 64-разрядность не переходила, а потому нормально лечится. Однако можно и рискнуть - проинсталлировать EW430-7211-Autorun.exe, вылечить ее, а потом подпихнуть из нее отладочные dll-файлы в последнюю версию EW430-8102.exe (предварительно сохранив где-нибудь их оригиналы). Я же помочь в этом никак не могу, т.к. с MSP430 никогда не работала и отладчика для них у меня нет.

А какой толк от полученной каши в виде каких-то там дампов памяти? В МК понятно, взял и сохранил сколько нужно. Вот только получить такой же вид, как это делает IDE в момент отладки ПО, не так просто: IDE в отладочной сессии генерит себе кучу вспомогательной информации. Размотать Call Stack удаленно работающего бинарника без этой инфы занятие такое себе. В первую очередь надо определиться с тем, как полученные дампы рабочей области стека МК быстро и наглядно расшифровать.

Это вообще логический оператор. Из 0 в 1 получается через несколько приведений типов. Это называется "грязной лапой". А если речь про С++, то там вот так делают enum class cursor_mode : uint8_t { NO_BLINK=0, BLINK=1 };

поддержу AS55047 это же акселерометр если я правильно понял. Это медленное устройство и данные обновляются редко и закладывать жесткость в пределах цикла не оправданно.А исходя из того, что Вы собираетесь по 30мкс находиться в высокоприоритетном прерывании, это значит, что у вас опрос происходит с килогерцовыми частотами, а значит 10мкс туда-сюда для CS вообще не проблема. И как уже сказали, сидеть в прерывании 30мкс - не правильно. Жизнь полна сюрпризов, согласен, но я не встречал еще такой задачи, где бы обязательно нарушался базовый тезис о том, что прерывание должно быть как можно короче. Поэтому перетаскивайте всё в поток и не мудрите.

просто ограничения вида "семь красных линий. Все они должны быть строго перпендикулярны, и кроме того, некоторые нужно нарисовать зеленым цветом, а еще некоторые — прозрачным" без каких-либо объяснений откуда они берутся вызывают некоторые сомнения в общей адекватности