Перейти к содержанию
    

Arlleex

Свой
  • Постов

    5 697
  • Зарегистрирован

  • Посещение

  • Победитель дней

    12

Arlleex стал победителем дня 25 января

Arlleex имел наиболее популярный контент!

Репутация

122 Очень хороший

2 Подписчика

Контакты

  • ICQ
    Array

Посетители профиля

17 365 просмотров профиля
  1. Обычный микроконтроллер. В каждом первом программаторе с али МК и внешняя I2C/SPI Flash🙂
  2. IAR вроде так и остался при своем. Т.е. генерит варнинг и пустой код. На LLVM сделан Keil, вернее его ARM Compiler 6 основан на LLVM, а от нативного ARMCC они отказались года 4-5 назад))
  3. Я говорю про начальные условия (состояния регистров), при которых будет работать формирование импульса заданной ширины в One Pulse Mode. Привел цитату из RM. Естественно, сами компараторы срабатывают по ==.
  4. Да, все соответствует в т.ч. моему описанию выше. Ширина импульса будет равна ARR - CCR (при OCxFE == 0) или ARR - начальный CNT (при OCxFE == 1). Задержка до начала импульса будет равна CCR - CNT или 3 такта соответственно. Проблема в том, что это точно будет работать при запуске от внешнего триггера, но не факт (я не проверял), что при ручном запуске таймера.
  5. Вообще все эти RCREG4; или (void)RCREG4; или через вызов фиктивной функции - сугубо на усмотрение конкретного компилятора И языка программирования. Си-шный стандарт сразу говорит, что понятие "доступа" в отношении к volatile-объектам отдается на усмотрение реализации: ISO/IEC 9899:201x: Открыл референс на свой компайлер и читаю: В Си строчка RCREG4; является выражением и это выражение должно оцениваться компилятором. А оценка невозможна без доступа. А вот в C++ доступ к volatile в этом отношении несколько другой: он вполне вправе считать, что такое выражение не имеет смысла, о чем может выкинуть варнинг "Expression has no effect". Так что все несколько запутано и нужно проверять конкретно "у себя". А еще ссылка по теме, кому интересно: https://embeddedgurus.com/stack-overflow/2010/03/reading-a-register-for-its-side-effects-in-c-and-c/. Тут подверждается, что даже "правильная" для конкретного языка C/C++ конструкция - не гарантия.
  6. Вы не правильно понимаете суть замысла бита OCxFE. А суть очень проста. Есть таймер. У него есть режим активации (например, включения счета) от внешнего события. Также предусмотрен режим генерации PWM, а режим одновибратора есть частный его случай (генерация одного периода). В CCR записывается задержка до формирования первого фронта импульса, а в ARR - значение, при котором будет сформирован второй (задний) фронт импульса и выключится таймер. Так вот, для того, чтобы эта шайтан-машина работала правильно, начальные условия должны удовлетворять CNT < CCR <= ARR. Отсюда видно, что с момента получения сигнала включения таймера от внешнего триггера до генерации первого фронта должно пройти минимум CCR + (5, вроде, по документации) циклов синхронизации. А теперь представьте ситуацию, когда импульс должен начать формироваться максимально быстро после получения триггера запуска таймера. Никаких задержек в виде отсчета CCR до первого фронта импульса не должно быть. Поэтому: при установленном OCxFE таймер при получении триггера старта немедленно (а если точнее, всего лишь строго 3 цикла) формирует первый фронт на выходном пине (как будто произошло событие равенства CNT == CCR). Затем, при достижении счетчиком CNT значения CCR, ничего не происходит. А потом счет доходит до ARR, ножка формирует второй фронт и таймер выключается. P.S. Если у Вас вопрос только в том, почему требуется запись в CCR == 1, то я выше привел требование документации насчет запуска режима OPM для генерации импульса:
  7. Тогда рекомендую поставить Win10 IoT. Там под корень выпилены виндовые магазины, службы не пойми чего, и т.д. Чистая голая винда для работы без лишних приложений.
  8. Вот с их сайта😉 Device_limitations_of_GD32F45x_F40x_Rev1.2.pdf
  9. Понял. Спасибо. Это, правда, требования к преобразователям, но все равно интересно почитать.
  10. Вы пытаетесь поженить теплое с круглым.
  11. Я про конкатенацию ## и получение на основе одних макросов - других. Это работает как текстовая замена с определенными правилами разворачивания макросов. И ничего другое, в том числе, enum-ы, туда не применимо. То, что Вы показали - является тривиальным примером однократной текстовой замены, все остальное делается компилятором, а не препроцессором. Но в общем к процессу именований это не относится)) Коллеги. Я лишь хочу отметить, что вот каждый из вас хоть и считает "правильно вот так, а вот так - хуже или вовсе плохо", а тем не менее - у всех свое. Да, в чем-то есть одинаковости, но по сути - каждый пишет как ему удобнее, с выработанным стилем. Вот привели примеры гугловских или своих кодстайлов - ну а какой от них толк, если весь остальной мир (включая писателей стандартных библиотек) - пишет по-другому? Ведь один фиг мы пишем проекты не на 100% состоящие из только наших исходников. Много заимствований - и во всех свои стили. И получается чистый зоопарк - тут кэмлкейс, там - функции с большой буквы через _, здесь - префиксы у переменных, а у четвертых постфиксы у типов. КОШМАР.
  12. Почему невозможны - вполне возможны🙂 В том то и прикол - что очень даже возможны и компилятор этому не препятствует. struct TimeMs { int counter; }; TimeMs TimeMs {10}; // -> запросто Правда, если ниже объявления объекта нужно будет обратиться к типу, то это уже проблема: надо приписывать ключевое слово struct. Возможно, разница именований действительно имеет смысл. Тогда почему библиотекари стандарта пишут все с маленькой буквы? Всякие std:: и т.д. - все это с маленькой буквы. Им, получается, можно?🙂
×
×
  • Создать...