caxapa.ru :: Вызывать блокирующуюся функцию ITM_SendChar в прерывании - НОРМАЛЬНО, а вот если у кого-то отладочный порт получился медленнее UART, то тот сам себе злобный Буратино

Vit (16.05.2020 19:02, просмотров: 880) ответил fk0 на Это прекрасно, я только что задавал вопрос, как быть, если результат кодогенерации куба подводит... Я только не понял, зачем у тебя из USART1 перекладывается в отладочный порт -- какой в этом смысл? Loopback test? Вначале сделай простой цикл в main, без прерываний. Вызывать блокирующуюся функцию ITM_SendChar в прерывании -- вообще идиотизм. Во-вторых где гарантия, что у тебя отладочный порт _быстрее_, чем UART? А то будет, что ты в обработчике прерывания зависаешь

Вызывать блокирующуюся функцию ITM_SendChar в прерывании - НОРМАЛЬНО, а вот если у кого-то отладочный порт получился медленнее UART, то тот сам себе злобный Буратино

Ответить

- Обработчики прерываний по несколько тысяч тактов нормально? Пешы из чо! - 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)
      - :) ...да их тут тысячи(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)
        
        Эта тема вроде бы призвана решить вопросы с показательным дебагом! А по факту она люто влияет на тайминг проги! Я для себя решил , луче отдать одну ногу поду 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)
  - и где там несколько тысяч тактов ? не очень понятно зачем нужна переменная status но компилер её думаю в любом случае оптимизирует - Aleksey_75(16.05.2020 19:24)

ARM, RISC-V контроллеры