-
- Еще раз повторюсь. Очень ценю вашу заботу и поддержку. Спасибо, ребята! (но на этом не заканчиваем, продолжаем, продолжаем :))) - RxTx(17.05.2020 12:31)
- Всем спасибо, решено. - RxTx(16.05.2020 20:52)
- Что было-то? - NAUT(16.05.2020 21:12)
- Я пока что в командировке, так что "решено" это условно, временно.
Я к тому так написал чтобы не ломали голову из-за меня, как бы не
тратили энергию. Но если есть какие-то мысли, конечно пишите.
Приеду домой, буду разбираться, трассировать времянки итд. "Решено"
так: сделал код прерывания как можно более коротким, просто запись
в ring buffer. Об этом писал здесь: и один из UART'ов у меня уже
был так построен. Этот (отладочную консоль) я перевел, остался еще
один, RxTx(2428 знак., 17.05.2020 10:11 - 20:16, ссылка)
- Кстати в любой функции оперирующей с указателями на данные
доступными из нескольких потоков (тот же ring buffer) можно
запросто нарваться на перестановку порядка обращения к переменным.
И volatile не поможет: gcc все эти volatile аккуратненько вынесет в
конец функции и там запишет в том же порядке. Я на когда такое
впервые увидел, чуть не рехнулся пока баг разгадывал. Поэтому после
изменения указателей или после записи данных перед продвижением
указателя нужно обязательно fk0(383 знак., 17.05.2020 13:09)
- "нарваться на перестановку порядка обращения" и "запишет в том же
порядке". Ты уж определись. - SciFi(17.05.2020 13:18)
- volatile-указатели на данные записывались в конце функции, в том
порядке, как они писались в функции. Но данные писались независимо
в теле функции. Т.е. данные писались, указатели не двигались. А
потом на выходе подвинулись указатели, ровно так как они должны
были бы подвинуться пока писались данные. Идея в том, что gcc не
пишет volatile переменные, а пишет их значения в регистры (коих у
мипса дофига). А потом перед выходом эти регистры натурально
записывает в память. - fk0(17.05.2020 14:01)
- То есть забыли добавить volatile в объявление "uint8_t fifo[];"?
Расплата вполне заслуженная. - SciFi(17.05.2020 14:05)
- Если добавлять volatile для всей памяти -- это будет треш, угар и содомия (при просмотре дизассемблера -- крайне неоптимальный код). Так делать не нужно. Потом возникает другая проблема -- вся область памяти становится несовместимой (без постоянных reinterpret_cast'ов) с обычными указателями и всеми интерфейсами в программе. Вообще volatile не нужен. Достаточно вставлять memory barrier. В случае кольцевого буфера: после записи данных и перед измененим указателя записи, и fk0(392 знак., 17.05.2020 14:20, ссылка)
- То есть забыли добавить volatile в объявление "uint8_t fifo[];"?
Расплата вполне заслуженная. - SciFi(17.05.2020 14:05)
- volatile-указатели на данные записывались в конце функции, в том
порядке, как они писались в функции. Но данные писались независимо
в теле функции. Т.е. данные писались, указатели не двигались. А
потом на выходе подвинулись указатели, ровно так как они должны
были бы подвинуться пока писались данные. Идея в том, что gcc не
пишет volatile переменные, а пишет их значения в регистры (коих у
мипса дофига). А потом перед выходом эти регистры натурально
записывает в память. - fk0(17.05.2020 14:01)
- "нарваться на перестановку порядка обращения" и "запишет в том же
порядке". Ты уж определись. - SciFi(17.05.2020 13:18)
- Приоритеты -- ещё один повод, почему блокирующихся функций в
обработчиках быть не должно. С равноприоритетными прерываниями оно
не так страшно. Про шаговый двигатель я вынес для себя на всю
жизнь: не нужно его крутить по шагам. Нужно крутить фазу с
фиксированным временным шагом. Достаточно коротким, чтоб на низких
скоростях разницы не было, а на высоких автоматически получается
пропуск микрошагов (иначе контроллер не успеет). И здесь важно,
чтоб джиттер был fk0(36 знак., 17.05.2020 12:26)
- Шаговик это вообще у меня тотальная жопа реализации. Признаюсь. Ну
лично я так считаю. Я пытался этот блок переписывать чтобы он был
"простой и тупой" как микросхема, но каждый раз оказывалась
какая-нибудь да херня. Объясню в чем дело. Аппаратура при условном
"POWER ON' калибруется по концевику. (я гоню шаговик до концевика,
который калиброочно расположен строго в определенном месте). После
этого я возвращаюсь в исходный нуль. Я при работе никогда не могу
потерять RxTx(1486 знак., 17.05.2020 12:55 - 13:11)
- Управление шаговиком -- это достаточно развесистый конечный автомат
скорей полностью умещающийся в прерываниях. И получающий от
прикладного уровня комадны вроде "приехать в такую-то позицию",
"найти начальную позицию", "безостановочное движение с такой-то
скоростью"... И отдающий на прикладной уровень текущую позицию
(когда в движении), код ошибки и т.п. При этом этот автомат должен
сам следить ещё и за концевиками или датчиками положений. Вообще
удобней такой автомат fk0(3765 знак., 17.05.2020 14:08 - 14:43, ссылка)
- У ЛИ оно там --> - Vit(17.05.2020 14:13, ссылка)
- Отсюда запрос: а нет ли у милостивых пэров ссылок на реализацию
шаговиков? Либы, статьи? - RxTx(17.05.2020 12:56)
- Во какую мурзилку нарыл, сам еще не читал LightElf(33 знак., 17.05.2020 23:39, ссылка)
- Спасибо =) Это прекрасно! - RxTx(18.05.2020 00:00)
- Есть Бoмж(19 знак., 17.05.2020 22:17, ссылка, ссылка)
- Спасибо. Бум изучать - RxTx(17.05.2020 22:38)
- Во какую мурзилку нарыл, сам еще не читал LightElf(33 знак., 17.05.2020 23:39, ссылка)
- Управление шаговиком -- это достаточно развесистый конечный автомат
скорей полностью умещающийся в прерываниях. И получающий от
прикладного уровня комадны вроде "приехать в такую-то позицию",
"найти начальную позицию", "безостановочное движение с такой-то
скоростью"... И отдающий на прикладной уровень текущую позицию
(когда в движении), код ошибки и т.п. При этом этот автомат должен
сам следить ещё и за концевиками или датчиками положений. Вообще
удобней такой автомат fk0(3765 знак., 17.05.2020 14:08 - 14:43, ссылка)
- Шаговик это вообще у меня тотальная жопа реализации. Признаюсь. Ну
лично я так считаю. Я пытался этот блок переписывать чтобы он был
"простой и тупой" как микросхема, но каждый раз оказывалась
какая-нибудь да херня. Объясню в чем дело. Аппаратура при условном
"POWER ON' калибруется по концевику. (я гоню шаговик до концевика,
который калиброочно расположен строго в определенном месте). После
этого я возвращаюсь в исходный нуль. Я при работе никогда не могу
потерять RxTx(1486 знак., 17.05.2020 12:55 - 13:11)
- Переменные status и b объявлены как volatile. Добавляем тормозов на
основании каких-то странных суеверий, видимо. - SciFi(17.05.2020 11:19)
- Я не вылизывал код, сейчас некогда и незачем этим заниматься. В данном случае это лайфхак: 1. При оптимизированном коде переменная существует в стеке и ее можно посмотреть дебаггером. 2. (теория) Некоторые реализации uart/usart требуют обязательного а. считывания статус-регистра. б. считывания гарантированно ДО чтения дата-регистра. в. Читать надо один раз. Для того чтобы обеспечить именно эти гарантии а-ля asm (а не вообще всегда) и убрать нежелательные оптимизации и RxTx(341 знак., 17.05.2020 11:38)
- "В mainloop выгребаю из ringbuffer" - видимо без критической
секции, если во время выгребания придет прерывание и запишет в
буфер данные, то кирдык? запрещать прерывания надо бы на время
чтения - NAUT(17.05.2020 10:56)
- Не надо запрещать, поскольку именно эта схема "Один Писатель - Один
Читатель" с двумя изолированными и "догоняющими" друг друга readpos
и writepos переменными сравниваемыми в одном месте LockFree. RxTx(63 знак., 17.05.2020 11:15)
- Ну, кагбэ, вопрос "че делать, если в буфере нет места" - нужно
задавать до написания реализации ring buffer. Собственно вариантов четыре: LightElf(394 знак., 17.05.2020 21:47)
- п. 2) это естественное поведение кольцевого буфера, новое при невычитанном через N=длине кольца затрет старое. Возможен п. 5) - RESET. п. 6) Подлежит обсуждению - когда стратегия записи одна, а стратегия чтения другая. Теперь смотря что понимается под "атомарным инкрементом". Прерывание и main loop это не тру потоки, прерывание и весь код в нем (если без извратов) будет "атомарным". Выполнится целиком и возвратится в основной код. - RxTx(17.05.2020 23:21)
- Пункт 1 не вариант, пункт 4 тоже -- это говнокод. Пункт 3 -- черти
что, зачем оно может быть нужно? Реальны варианты 2 и 5. 5) вывод
блокируется до появления свободного места в буфере -- требует
примитивов синхронизации. Зачем в варианте 2 атомарный инкремент, и
инкремент чего? Указатель записи двигает только писатель, а
указатель чтения двигает только читатель. Противоположная сторона в
обоих случаях (читатель и писатель соответственно) только читают не
свой указатель fk0(1028 знак., 17.05.2020 21:57)
- Пункт 1) очень часто вполне пригоден, зря ты так. Например для тех
же логов. Буфер не бесконечен, а останавливать программу "пока
логгер не прочихается" - не самая красивая идея. Соответственно
именно для логов вариант 3) может быть полезнее, чтобы хоть
"последний выдох господина ПЖ" не потерять. В варианте 2 писатель
должен двинуть и read_index и write_index. И вот для того, чтобы
корректно двинуть read_index ему и нужен atomic_inc. Вариант 4 -
самый простой и тупой, но не LightElf(116 знак., 17.05.2020 22:13)
- Вот самое забавное, когда отлаживаешься (от слова лажа :) ) таки
надо вставать, пока логгер не прочихается. А то грозит тем что
строчка "ram test failed, reset" успешно не будет записана... - RxTx(18.05.2020 00:07)
- На это я пойтить не могу. Такие баги надо обрабатывать уже после
ресета. - LightElf(18.05.2020 00:25)
- На это я могу сказать - "Кокой унтюресный у тебя RESET. Ты правда
считаешь что RESET должен так работать, оставляя что-то там в
каком-то состоянии?" RxTx(47 знак., 18.05.2020 20:13)
- Хорошим тоном является выяснять причину Reset-а. Это почти не больно. Там спецуевый регистр присопливлен. - LightElf(30.05.2020 21:50)
- На это я могу сказать - "Кокой унтюресный у тебя RESET. Ты правда
считаешь что RESET должен так работать, оставляя что-то там в
каком-то состоянии?" RxTx(47 знак., 18.05.2020 20:13)
- На это я пойтить не могу. Такие баги надо обрабатывать уже после
ресета. - LightElf(18.05.2020 00:25)
- Если останавливать не вариант -- пункт 2. Ибо в варианте 1
непонятно что делать. Останавливаться и мигать лампочкой? С
пропусками -- это варианты 2 и 3. "Последний выдох" и "новые данные
затирают последние записанные" несколько противоречиво. Что имеется
ввиду? И сколько последних записанных? Последний байт, строку?
"Последний выдох" -- это по-моему именно вариант 2 (новые данные
затирают самые старые не обработанные). В варианте 2 писатель не
должен двигать fk0(895 знак., 17.05.2020 22:52)
- Согласен, чета я все смешал в кучу. Упущен существенный вопрос, что представляют из себя "новые данные". Ежели это просто очередной символ - то набор вариантов один. Ежели это как-то форматированный блок данных (например строки лога) - то варианты другие. По поводу ковыряний с индексами - согласен, тоже вариант. Особенно на современных процах - сделал индекс типа uint32_t и лишних битов хватит на любой разумный размер буфера. - LightElf(17.05.2020 23:55)
- Вот самое забавное, когда отлаживаешься (от слова лажа :) ) таки
надо вставать, пока логгер не прочихается. А то грозит тем что
строчка "ram test failed, reset" успешно не будет записана... - RxTx(18.05.2020 00:07)
- Пункт 1) очень часто вполне пригоден, зря ты так. Например для тех
же логов. Буфер не бесконечен, а останавливать программу "пока
логгер не прочихается" - не самая красивая идея. Соответственно
именно для логов вариант 3) может быть полезнее, чтобы хоть
"последний выдох господина ПЖ" не потерять. В варианте 2 писатель
должен двинуть и read_index и write_index. И вот для того, чтобы
корректно двинуть read_index ему и нужен atomic_inc. Вариант 4 -
самый простой и тупой, но не LightElf(116 знак., 17.05.2020 22:13)
- +1. Проблемы с детектированием наезда, на необработанные данные, обгона указателя чтения, можно решить, если использовать не указатели, а индексы -- тогда освободятся старшие биты, в которых можно хранить счётчик. Ну или если есть 64-битные атомики. А если потеря данных не допустима, то увы, нужен семафор и условная переменная. fk0(1191 знак., 17.05.2020 12:53, ссылка, картинка)
- Ну, кагбэ, вопрос "че делать, если в буфере нет места" - нужно
задавать до написания реализации ring buffer. Собственно вариантов четыре: LightElf(394 знак., 17.05.2020 21:47)
- Не надо запрещать, поскольку именно эта схема "Один Писатель - Один
Читатель" с двумя изолированными и "догоняющими" друг друга readpos
и writepos переменными сравниваемыми в одном месте LockFree. RxTx(63 знак., 17.05.2020 11:15)
- Кстати в любой функции оперирующей с указателями на данные
доступными из нескольких потоков (тот же ring buffer) можно
запросто нарваться на перестановку порядка обращения к переменным.
И volatile не поможет: gcc все эти volatile аккуратненько вынесет в
конец функции и там запишет в том же порядке. Я на когда такое
впервые увидел, чуть не рехнулся пока баг разгадывал. Поэтому после
изменения указателей или после записи данных перед продвижением
указателя нужно обязательно fk0(383 знак., 17.05.2020 13:09)
- скажет только под пытками. :-) - Лaгyнoв(17.05.2020 08:44)
- Сказал же! - "Код сгенерирован CubeMX" :) - VLLV(17.05.2020 09:02)
- Я пока что в командировке, так что "решено" это условно, временно.
Я к тому так написал чтобы не ломали голову из-за меня, как бы не
тратили энергию. Но если есть какие-то мысли, конечно пишите.
Приеду домой, буду разбираться, трассировать времянки итд. "Решено"
так: сделал код прерывания как можно более коротким, просто запись
в ring buffer. Об этом писал здесь: и один из UART'ов у меня уже
был так построен. Этот (отладочную консоль) я перевел, остался еще
один, RxTx(2428 знак., 17.05.2020 10:11 - 20:16, ссылка)
- Что было-то? - NAUT(16.05.2020 21:12)
- 1. IMHO, UART, таймеры, GPIO, *WDG - проще и практичнее
использовать LL HAL. Все равно, у вас смесь - инициализация - HAL,
непосредственно прием - используете регистры. На мой взгляд, если
уже использовать HAL - то использовать до конца. Другой вопрос, что
для простой периферии HAL избыточен. A.L.(282 знак., 16.05.2020 18:13)
- +1 последнее время с этой периферией работаю исключительно на уровне регистров - Aleksey_75(16.05.2020 19:25)
- Это прекрасно, я только что задавал вопрос, как быть, если
результат кодогенерации куба подводит... Я только не понял, зачем у
тебя из USART1 перекладывается в отладочный порт -- какой в этом
смысл? Loopback test? Вначале сделай простой цикл в main, без
прерываний. Вызывать блокирующуюся функцию ITM_SendChar в
прерывании -- вообще идиотизм. Во-вторых где гарантия, что у тебя
отладочный порт _быстрее_, чем UART? А то будет, что ты в
обработчике прерывания зависаешь fk0(437 знак., 16.05.2020 17:07)
- Полезно почитать эту статью. - RxTx(30.05.2020 17:40, ссылка)
- Еще значение имеет nested ли interrupts или нет. - RxTx(17.05.2020 10:20)
- Спасибо, Кирюнтик! =) Спектрумист спектрумисту помогает =) - RxTx(17.05.2020 09:47)
- Вызывать блокирующуюся функцию ITM_SendChar в прерывании - НОРМАЛЬНО, а вот если у кого-то отладочный порт получился
медленнее UART, то тот сам себе злобный Буратино - Vit(16.05.2020 19:02)
- Обработчики прерываний по несколько тысяч тактов нормально? Пешы из
чо! - fk0(16.05.2020 19:06)
- Ты в своём уме??? Разуй глаза и почитай сколько чего в том
инлайновом отладочном выхлопе, а не истери - Vit(16.05.2020 20:10)
- Я посмотрел, там цикл while (some reg & some flag) asm("nop") и
потом запись в регистр. Ключевое слово -- БЛОКИРУЮЩАЯ ФУНКЦИЯ. Она
блокируется на неизвестное время. - fk0(16.05.2020 21:20)
- эта где ? в ITM_SendChar()?? жесть какая - Aleksey_75(16.05.2020 21:31)
- Мопед не мой --> - fk0(16.05.2020 21:47, ссылка)
- ээээ, трешак!! я так понял эта функция заточена чтоб не
использовать прерывания, паэтому сидим и ждем, чем ниже битрейд тем
больше ждем )) - Aleksey_75(16.05.2020 22:12)
- Не вижу ничего страшного. Вот prinf() в обработчике это жесть Vit(376 знак., 16.05.2020 22:33)
- Сорян! эт же гниво с swo? fk0 Прав на все 100% там отправка по три
байта с фиксированной паузой, эта хня тормозит все и вся!!! Я раз
пол дня потерял с отладкой USB, только из за этого гнилого
дебага.... нах, нах ! Мои извинения fk0! В прерывании "это"
использовать низя никогда !!! - Aleksey_75(16.05.2020 23:08)
- fk0 прав в том, что нефиг при сравнимых или неудобоваримых скоростях юзать всякие вкрапления, в т.ч. и это. В твоём случае, вероятнее всего тем более. О USB, как я понял, речь была о принимающей стороне - смотрелке SWO. А для, например, UART такое, да в прерывании, - самое то!!! Юзаю сам и буду всем рекомендовать:) - Vit(16.05.2020 23:41)
- Сорян! эт же гниво с swo? fk0 Прав на все 100% там отправка по три
байта с фиксированной паузой, эта хня тормозит все и вся!!! Я раз
пол дня потерял с отладкой USB, только из за этого гнилого
дебага.... нах, нах ! Мои извинения fk0! В прерывании "это"
использовать низя никогда !!! - Aleksey_75(16.05.2020 23:08)
- Не вижу ничего страшного. Вот prinf() в обработчике это жесть Vit(376 знак., 16.05.2020 22:33)
- ээээ, трешак!! я так понял эта функция заточена чтоб не
использовать прерывания, паэтому сидим и ждем, чем ниже битрейд тем
больше ждем )) - Aleksey_75(16.05.2020 22:12)
- Мопед не мой --> - fk0(16.05.2020 21:47, ссылка)
- :) ...да их тут тысячи(C) - Vit(16.05.2020 21:22)
- А сколько по-твоему? Как я понимаю, там каждый сраный байтик
упхивается в 32-битный пакет и по однобитной шине медленно и
печально выдаётся наружу. Куда ещё валятся пакеты из остальных
источников данных, от отладчика, какая-нибудь трассировка и т.п. И
ещё нужно закодировать номер канала и таймштамп. Я думаю в первом
приближении там каждый байтик может превращаться аж в 8 байтиков.
Конечно можно было бы упаковывать по 4, но так не делается. И в
этой шине клок ещё может быть fk0(370 знак., 16.05.2020 22:16)
- SWO это отдельный пин. Debug ядра валит по SWD. - RxTx(17.05.2020 10:22)
- Тем нет штампа, по крайней мере по умолчанию. Байт с номером канала и числом байт, далее 1..4 байта данных. - Andreas(16.05.2020 22:40)
- Пока ты думаешь, оно используется. Быстро и удобно. Обычно, если
случайно не настараться:), оно отправляется на частоте ядра. В
некоторых камнях, к сожалению, клок заметно ниже - в EFM32GG было
раз в 12, что-ли, ниже. С чем связано - не знаю. - Vit(16.05.2020 22:28)
- Я так понял, что клок ограничивается и JLINK. В проце ставлю 16Мгц
клок SWO, но JLINK-OB на F072 все равно 250кГц как-то устанавливает
и быстрее не передает. - Andreas(16.05.2020 22:35)
- Есть мощное ощущение, что SEGGER'овцы ограничивают частоту именно в OB или EDU версии. - RxTx(17.05.2020 11:20)
- Конечно. В JLINK-OB на F072 и CDC есть - живет своей жизнью -
говнище редкое. Vit(108 знак., 16.05.2020 23:44)
- За неимением кухарки..... Зато домой удобно таскать - в мелкой
коробчонке питание, отладчик и уарт. А с глюками CDC не встречался,
по крайней мере на 115200. - Andreas(17.05.2020 00:26)
- эээ, а где там в CDC битрейд выставляется ?? - Aleksey_75(17.05.2020 00:47)
- в терминале:) - Vit(17.05.2020 00:52)
- т.е. со стороны хоста ?? ну да, ну и даже здесь он весьма условный - Aleksey_75(17.05.2020 00:54)
- в терминале:) - Vit(17.05.2020 00:52)
- эээ, а где там в CDC битрейд выставляется ?? - Aleksey_75(17.05.2020 00:47)
- За неимением кухарки..... Зато домой удобно таскать - в мелкой
коробчонке питание, отладчик и уарт. А с глюками CDC не встречался,
по крайней мере на 115200. - Andreas(17.05.2020 00:26)
- Эта тема вроде бы призвана решить вопросы с показательным дебагом!
А по факту она люто влияет на тайминг проги! Я для себя решил ,
луче отдать одну ногу поду tx любого свободного уарта и не сношать
себе моск! - Aleksey_75(16.05.2020 23:12)
- Я просто выкидываю без проверки и не имею проблем с таймингом. Если
что-то потеряется из дебага - не страшно. Мне понравилась
возможность вывести данные наружу без нарушения работы основного
консольного вывода и вообще без задержек в девайсе. Andreas(303 знак., 16.05.2020 23:36)
- Без подключенного отладчика иногда можно огрести стопор. В STM32
нарывался. Т.е. рулежка на /dev/null должна быть где-то на входе
Debug_Putсhar(). - Vit(17.05.2020 00:07)
- Ннне понял, откуда может быть ступор при выполнении
ITM->PORT[0].u32 = n; ? Если использовать ITM_SendChar , то да
возможно и можно огрести. - Andreas(17.05.2020 00:19)
- если отладчик не включил дебаг-модуль ядра и не настроил со своей стороны. тогда можно ожидать вечно. включить модуль дебага вааще (и без внешнего отладчика) можно для CM3, CM4 (скорее всего и CM7) при, собственно, включении DWT. далее, полагаю, понятно. это, конечно при ITM_SendChar без проверки на входе. - Vit(17.05.2020 00:43)
- Ннне понял, откуда может быть ступор при выполнении
ITM->PORT[0].u32 = n; ? Если использовать ITM_SendChar , то да
возможно и можно огрести. - Andreas(17.05.2020 00:19)
- Без подключенного отладчика иногда можно огрести стопор. В STM32
нарывался. Т.е. рулежка на /dev/null должна быть где-то на входе
Debug_Putсhar(). - Vit(17.05.2020 00:07)
- Я просто выкидываю без проверки и не имею проблем с таймингом. Если
что-то потеряется из дебага - не страшно. Мне понравилась
возможность вывести данные наружу без нарушения работы основного
консольного вывода и вообще без задержек в девайсе. Andreas(303 знак., 16.05.2020 23:36)
- Я так понял, что клок ограничивается и JLINK. В проце ставлю 16Мгц
клок SWO, но JLINK-OB на F072 все равно 250кГц как-то устанавливает
и быстрее не передает. - Andreas(16.05.2020 22:35)
- А сколько по-твоему? Как я понимаю, там каждый сраный байтик
упхивается в 32-битный пакет и по однобитной шине медленно и
печально выдаётся наружу. Куда ещё валятся пакеты из остальных
источников данных, от отладчика, какая-нибудь трассировка и т.п. И
ещё нужно закодировать номер канала и таймштамп. Я думаю в первом
приближении там каждый байтик может превращаться аж в 8 байтиков.
Конечно можно было бы упаковывать по 4, но так не делается. И в
этой шине клок ещё может быть fk0(370 знак., 16.05.2020 22:16)
- эта где ? в ITM_SendChar()?? жесть какая - Aleksey_75(16.05.2020 21:31)
- Я посмотрел, там цикл while (some reg & some flag) asm("nop") и
потом запись в регистр. Ключевое слово -- БЛОКИРУЮЩАЯ ФУНКЦИЯ. Она
блокируется на неизвестное время. - fk0(16.05.2020 21:20)
- и где там несколько тысяч тактов ? не очень понятно зачем нужна переменная status но компилер её думаю в любом случае оптимизирует - Aleksey_75(16.05.2020 19:24)
- Ты в своём уме??? Разуй глаза и почитай сколько чего в том
инлайновом отладочном выхлопе, а не истери - Vit(16.05.2020 20:10)
- Обработчики прерываний по несколько тысяч тактов нормально? Пешы из
чо! - fk0(16.05.2020 19:06)
- Возможно какие-нибуь ошибки приёма - Vit(16.05.2020 16:55, ссылка)