menzoda

Загрузчик может и сам себя обновить. Правда, возрастает риск, ведь при неудачном обновлении загрузчик сам себя и поломает же. Однако, у нас обновление загрузчика это чисто технологическая задача, не для конечных пользователей, поэтому мы спокойно используем именно этот вариант. Если даже что-то пойдет не так - то рядом будут специалисты, которые все восстановят. Пока сбоев не было.

Сумма по модулю 2 - это XOR. Если нужна однобитовая сумма, то сначала XORтье все байты данных друг с другом, затем биты получившегося результата.

Язык --это не законы физики (хотя и они могут пересматриваться), а очень динамичная штука, он живет, развивается. Можете посмотреть как говорили на русском и английском в 17 веке, в 14, в 10. Чем дальше, тем сильнее отличается язык. Поэтому закона как такового нет, общество само определяет язык - произношение, набор слов, правила грамматики, орфографии. Что раньше считалось правильным теперь таковым может не являться. Если один человек говорит "офтобус", то он неграмотен, если миллиард людей говорит "офтобус", то неграмотны те оставшиеся, кто говорит "автобус". То есть, если весь мир говорит таким образом, то это и есть правильно, точка.

Ну вы нашли о чем спорить! Чар или кар! Давайте лучше советы по собственно языку обсуждать.

У MDK и DS-5 один и тот же компилятор. Да и заявление "перестал давать эффективный код" слишком громко звучит. Уже сто раз сравнивали GCC, IAR и ARMCC, вывод один и тот же: примерно одинаково, на каких-то задачах один чуть лучше, на других - другой.

Если есть FPU, то умножать быстрее будет, иначе точно не скажешь - нужно тестировать.

Так тут ведь та же самая проблема будет.

Нет, зависит от архитектуры. Не учел. Представь такую ситуацию: функция get вызывается из фона, проверяется флаг busy. Так как он равен нулю, то осуществляется переход к return. Чтобы возвратить 64-битное значение нужно скопировать его из памяти в регистры R0 и R1. Копирование происходит по 32 бита. Одна часть скопировалась. Тут происходит прерывание в котором вызывается inc, которая увеличивает значение счетчика. Прерывание завершается и управление возвращается get, которая копирует оставшиеся 32 бита, потенциально изменившиеся в прерывании. В итоге получается хрень. Если используешь RTOS - применяй идущие в комплекте примитивы синхронизации. Если программка простая, без RTOS, то самый легкий и надежный способ - запрещать прерывания при чтении и изменении счетчика. static uint64_t counter; void inc(uint32_t value) { __disable_interrupt(); counter += value; __enable_interrupt(); } uint64_t get(void) { __disable_interrupt(); uint64_t copy = counter; __enable_interrupt(); return copy; }

Стандартное решение для простых задач: - Расчеты реального времени в прерываниях (ШИМ, модуляция, фильтрация и т.п.). - В фоне "super loop" с асинхронными вызовами. - Сведенный к минимуму функционал обслуживания асинхронных вызовов тоже в прерываниях.

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

Это уже обсуждали вот здесь. Можно хотя бы для приличия первые странички разделов поглядеть...

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

Добавлю. 1. Обработчик можно написать как на си, так и на ассемблере. На си это будет просто функция с таким же именем, не принимающая никаких параметров и ничего не возвращающая. 2. Как так без них работало? Без них ничего не может работать. 3. До входа в main происходит инициализация библиотеки времени исполнения (C Runtime Library), инициализация статических переменных, при необходимости копирование кода в область исполнения. 4. Лучше всего читать документы от ARM, потому что первоисточник. Необходимо заметить, что IAR использует свой ассемблер, поэтому некоторые конструкции могут выглядеть по-другому нежели в документах ARM. Синтаксис IAR'овского ассемблера можно посмотреть в соответствующем документе от IAR.

Наконец! Всем миром загрузчик помогали делать! Зато какой опыт! Уж это должно быть несложно - просто вызвать программный сброс. Главный вопрос сбросит ли он VTOR, вроде сбрасывает, но лучше уточнить, периферию то он точно сбрасывает. Цвет то на оперативку не влияет никак, а так я сам с классической темой сижу, только цвета стандартные - серо-мышиные, а не вырвиглазный зеленый.

Это идея. Ведь адрес вершины стека извлекается из первого вектора после сброса, а мы при переходе к основному ПО ничего не сбрасываем. Формально говоря, надо бы перед переходом самому извлечь это значение и записать в регистр SP, или можно это сделать в основном ПО в стартап-файле. Однако, не факт, что это является причиной ошибки. Сейчас адрес стека достается основному ПО по наследству от загрузчика. Какие могут быть потенциальные проблемы? Во-первых, загрузчик может использовать значительную часть стека и основному ПО достанется урезанный участок памяти, которого может не хватить, но так как твой загрузчик вообще не использует стек этим вариантом можно пренебречь. Во-вторых, проекты загрузчика и основного ПО могут иметь разное расположение стека: стек загрузчика может пересекаться с областью данных основного ПО. Таким образом основное ПО, работая с данными в RAM, может попортить себе этот неправильно заданный стек. Последняя ситуация более вероятна, но если это и она странно, что в отладчике всё работает. Тем не менее попробуй задать правильное значение стека перед переходом и посмотри что будет. Если не поможет то остается трассировать. Расставляешь на разных этапах загрузчика и основного ПО дерганье выводами МК, так же не забываешь про исключения (HardFault и иже с ним). Запускаешь и смотришь: ага, эта дернулась, значит загрузчик запустился, а эта не дернулась, значит в основное ПО не перешел, выходит проблема где-то между этими этапами. Постепенно передвигая дерганье ногами ближе к друг-другу определяешь место поломки, ну а дальше будет видно.