STM32 новичку в ARM что к чему

[jcxz]

[uquote="pvit",url="/forum/viewtopic.php?p=3447077#p3447077"]Не везде надо, но если флаги взводятся по прерываниям, то внутрь while(flag) вставляется wfi. Напоминаю, я не ратую за поллинг, а формализую условия, где он может прокатывать.[/uquote]
Не везде надо, но считаю хорошим тоном наличие даже если не нужно. К тому же эта же idle-задача у меня занимается подсчётом загрузки CPU. А это уже нужно везде.
Внутрь while можно вставить только если флаг один. А их как правило далеко не один нужен. И вот тут уже начинаются проблемы на ровном месте.

[uquote="pvit",url="/forum/viewtopic.php?p=3447077#p3447077"]Значит с большой вероятностью у вас больше 2 задач. Например третья парсит протокол во фреймах (если они не заворачиваются полностью в DMA, как отсчеты АЦП).[/uquote]
Я же говорил о случае суперцикла. Какие там задачи? Всё в одной большой куче. Разделение на задачи/ISR - это уже нормальный подход.

[pvit]

[uquote="jcxz",url="/forum/viewtopic.php?p=3447136#p3447136"]Какие там задачи?[/uquote]
Логические.

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

[jcxz]

[uquote="a5021",url="/forum/viewtopic.php?p=3447078#p3447078"]Как часто? Со скоростью "несколько десятков МГц" / 8 ? А не слишком ли это дофига даже для ваших фантастических примеров?
Пусть эта "быстрая" через DMA работает и будет помедленнее. Умельцы тут на форуме динамическую индикацию демонстрировали. Молотит через SPI+DMA во весь опор, не то, что без прерываний, а и вовсе полностью аппаратно. Говорю же, как процесс организовать.[/uquote]
Ну вот в одном из моих проектов есть FOC (векторное управление моторчиком) с частотой ШИМа (и прерываний) == 20кГц. И кроме него в проекте ещё куча периферии, с которой одновременно идёт работа: две группы АЦП-каналов (скан (сэмплирование = почти 900кГц) и инжектированные (частота много меньше), на паре каналов DMA), 3 UART-а (1 из них через DMA на 921600бод), гироскоп на I2C (2 DMA) 400кГц, 2-3 слэйва на SPI (2 DMA) SCLK=30МГц, датчики Холла со своей кучкой прерываний, радиоприёмник (пара таймерных прерываний). Всё это прекрасно работает одновременно.
А теперь расскажите как Вы всё это разложите в Ваш суперцикл?? Учитывая что для FOC нужны такие довольно тяжёлые вычисления на каждом периоде ШИМ, для интерполяции д.Холла нужны тоже непростые вычисления (не реже частоты главного ШИМ), для обработки данных гироскопа нужна тоже довольно тяжёлая математика.
Куда Вы всунете WFI чтобы не потерять данные и успеть всё обработать?
И это ещё относительно простой проект. Есть и более сложный - там примерно то же самое, но периферии ещё больше - добавляются несколько каналов CAN, Ethernet-драйвер с работающим поверх него TCP-стеком, HTTP-сервером, SNTP- и прочей кухней; кучка датчиков температуры с ШИМ-модулированным выходом и драйверами под них на прерываниях и пр.. И HTTP у меня вполне себе нормально работает даже когда моторчик крутится и векторное управление работает. На суперцикле Вы бы уже давно приплыли.

[uquote="a5021",url="/forum/viewtopic.php?p=3447078#p3447078"]

У меня то WFE во всех проектах есть. А куда Вы его будете в свой суперцикл впендюривать, позвольте узнать?

В начало или конец, а что?
Давайте я проведу вам маленький ликбез, а то чувствую, вы еще долго в глупостях упражняться будете. Картина с этими событиями такая: если прерывание разрешить в периферии, но не разрешить в контроллере прерываний NVIC, то каждый раз, когда периферия будет "генерировать" прерывание, вызова обработчика происходить не будет, но будет взведение флага в регистре NVIC->ISPR. Вот этот регистр и надлежит мониторить на предмет смены значения. А мониторить его не просто, а очень просто:[/uquote]
Вы приведите пример своего суперцикла, в котором "WFE в начале или конце". И если сами не можете понять, то наглядно покажем Вам какие баги будут в Вашем суперцикле. Какая разница где Вы там флаги собираетесь опрашивать - в NVIC или в конкретной периферии, ущербен сам подход. Он обладает огромными недостатками, в том числе - огромными затратами на обработку одного события во много раз превышающими те 12 тактов что так боитесь.
Итак вот ваш цикл:
while (1) {
__WFE();
if (flag0) {...}
if (flag1) {...}
if (flag2) {...}
...
if (flagN) {...}
}
Вы как бы совсем не видите тут проблем и недостатков?
А расскажите как нам, сколько тактов потребуется CPU если он находится внутри WFE и тут пришло событие flagN?
А что будет если пришло такое событие, процессор пошёл выполнять эту портянку, дошёл до flag2, и тут случилось flag0? Что будет?
А что будет если скажем одно из событий требует реакции за время не более 1/20кГц (FOC), а в это время мы надолго застряли с обработкой HTTP-запроса?
Вы как бы совсем не видите очевидных вещей??? Тогда видимо абдуринизация зашла уже слишком далеко и уже ничем не помочь.....

[uquote="a5021",url="/forum/viewtopic.php?p=3447078#p3447078"]

Предположим - Ethernet-фрейм. Который в себе содержит IP, содержащий в себе TCP, содержащий в себе... ну вот тут суперцикл и приплыл.....

Без разницы, что он там в себе содержал. Обработка точно такая же, как и для любых данных, принятых по любому интерфейсу.[/uquote]
А сколько эта обработка времени займёт? А что будет с другими событиями от другой периферии, которые не могут ждать пока в ответ на GET-запрос Вы упакуете gzip-ом отправляемый файл? Не задумывались?

Добавлено after 8 minutes 37 seconds:
[uquote="arkhnchul",url="/forum/viewtopic.php?p=3447084#p3447084"][uquote="jcxz",url="/forum/viewtopic.php?p=3447071#p3447071"]Десятки источников прерываний - обычная ситуация в любом более-менее серьёзном устройстве сложнее абдурины.[/uquote]к слову, большая часть промавтоматики, на которой заводы работают, имеет примерно три источника прерываний - АЦП, таймер и изменение уровня на ноге aka EXTI. Ну пусть еще RXNE для модбаса.[/uquote]
Ни в одном из проектов над которыми я работал последние >10лет, не было менее 10 источников прерываний. А обычно - гораздо больше. Мало источников было только в проектах на DSP, но там другая специфика.
И то что Вы пишете - это наверное справедливо было устройства для позапрошлого века. В современных устройствах заказчик хочет кучу плюшек сразу. Если это счётчик электроэнергии, то это уже только UART-ов будет штук 5: оптопорт, RS-485 (1 или 2), GSM, ZigBee, PLC, радиомодуль, сервисный порт (каждый UART - 3 источника прерываний), ... не считая прочих Ethernet и др. И кучка других прерываний от FRAM/FLASH, вычислителя параметров сети и кучки других датчиков.

PS: У меня складывается впечатление что тут мало кто работает с серьёзными проектами. А больше с игрушками только и мигалками.....

[Reflector]

[uquote="a5021",url="/forum/viewtopic.php?p=3447078#p3447078"]Картина с этими событиями такая: если прерывание разрешить в периферии, но не разрешить в контроллере прерываний NVIC, то каждый раз, когда периферия будет "генерировать" прерывание, вызова обработчика происходить не будет, но будет взведение флага в регистре NVIC->ISPR. Вот этот регистр и надлежит мониторить на предмет смены значения. А мониторить его не просто, а очень просто:[/uquote]
И чем такой подход лучше? Допустим прочитали ISPR, там выставлен 10 флаг и сразу после чтения выставляется 9-й, следовательно нужно выполнить 10 проверок, потом обработку, еще 9 проверок и только потом мы доберемся до функции, в которую с прерываниями(за счет большего приоритета) могли бы попасть через полтора десятков тактов, а то, что флаги проверяемые в конце связаны с не самыми частыми событиями еще не означает, что реагировать на них можно медленнее, бывает и наоборот.

Добавлено after 6 minutes 25 seconds:
[uquote="jcxz",url="/forum/viewtopic.php?p=3447169#p3447169"]Итак вот ваш цикл:
while (1) {
__WFE();
if (flag0) {...}
if (flag1) {...}
if (flag2) {...}
...
if (flagN) {...}
}[/uquote]
У него там else if, так что если считать более частые события более приоритетными, то по крайней мере в худшем случае не придется ждать пока не отработают обработчики всех флагов.

[ARV]

Размер ваших писек надо измерять в парсеках, профессионалы хреновы.

[dosikus]

ARV, костюм Д'Артаньяна примеряешь?

[jcxz]

[uquote="Reflector",url="/forum/viewtopic.php?p=3447180#p3447180"]У него там else if, так что если считать более частые события более приоритетными, то по крайней мере в худшем случае не придется ждать пока не отработают обработчики всех флагов.[/uquote]
А я тут пытаюсь вразумить его не о времени реакции на событие, а о затратах процессорного времени на обработку одного события. a5021 боится 12 тактов на вход в прерывание, забывая что его цикл на обнаружение одного такого события в среднем будет тратить время равное половине времени выполнения этого цикла.
Что (при достаточном количестве обслуживаемых событий) намного превысит все входы/выходы в прерывания.
А ещё, при таком построении, проснувшись из WFE от события в конце цикла и двигаясь по нему до его флага флагN, если в этот момент произойдёт событие флаг0, который уже прошли, то после обработки флагаN, он спокойно уйдёт в сон на WFE не обработав флаг0. И потеряв его.

[arkhnchul]

[uquote="jcxz",url="/forum/viewtopic.php?p=3447169#p3447169"]В современных устройствах заказчик хочет кучу плюшек сразу.[/uquote]ну не "в современных", а "в несерийных, которые понадобились конкретному заказчику". Тот же счетчик расхода зачастую представлен одинарным модулем на DIN рейку с индикацией в виде одного светодиода и rs485 для всего остального. Конечно, такую фиготень у вас никто не станет заказывать - можно просто пойти и купить то же самое с П/ПИ/ПИД регуляторами или простыми частотниками.
[uquote="jcxz",url="/forum/viewtopic.php?p=3447169#p3447169"]каждый UART - 3 источника прерываний[/uquote]терминология, етить ее. Каждый UART - один источник, выставляющий разные флаги.

[a5021]

[uquote="pvit",url="/forum/viewtopic.php?p=3447098#p3447098"]Я не знаю универсальных метрик.[/uquote]
"У меня для вас плохие новости (С) pvit" Сначала вы с уверенностью говорите странные вещи, а потом выясняется, что в их основе лежит "незнание универсальных метрик". Есть просьба, в след. раз вы уж постарайтесь свои доводы строить на том, что знаете, а то ерунда получается.

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

Да-да. Главное замысловатой воды побольше. Авось прокатит.

Ну вот на ревью за выкрутасы с поллингом в main loop и будет много неприятных открытий.

Вам мало тех глупостей, что вы здесь по неосмотрительности наговорили? Считаете, что нужно еще подбавить?

[jcxz]

[uquote="arkhnchul",url="/forum/viewtopic.php?p=3447298#p3447298"]а "в несерийных, которые понадобились конкретному заказчику". Тот же счетчик расхода зачастую представлен одинарным модулем на DIN рейку с индикацией в виде одного светодиода и rs485 для всего остального.[/uquote]
Именно в серийных. С серией в несколько тыс.шт в месяц. И современных.
Работал в этой области несколько лет, на нескольких линейках устройств, которые уже серийно производятся/продаются. И никогда не слышал что "нам такая плюшка не нужна", а только "нам бы ещё так и ещё в горошек и с бантиком".
И RS-485 даже для счётчиков на подстанции - это уже прошлый век. Сейчас хотят беспроводку (ZigBee, RF, ...) или резервирование связи (два Ethernet-порта для создания кольца) или два интерфейса во внешний мир (GSM+Ethernet или возможность ретрансляции с них на все другие счётчики в группе) чтоб две независимые организации могли независимо одна от другой подключаться к счётчикам или возможность через наш счётчик опрашивать (иметь доступ) другие приборы на данном объекте через единый канал связи или.... или и то и другое и третье. Поэтому каждый интеллектуальный прибор учёта - это целый куст различных интерфейсов/каналов связи с возможностью ретрансляции между ними.

[uquote="arkhnchul",url="/forum/viewtopic.php?p=3447298#p3447298"]терминология, етить ее. Каждый UART - один источник, выставляющий разные флаги.[/uquote]
В зависимости от МК это может быть как единый вектор прерывания, так и несколько разных векторов или быть конфигурируемо.
И флаги, индицирующие причину прерывания, могут также находится в разных регистрах одного периферийного модуля.

[pvit]

[uquote="a5021",url="/forum/viewtopic.php?p=3447393#p3447393"]"У меня для вас плохие новости (С) pvit" Сначала вы с уверенностью говорите странные вещи, а потом выясняется, что в их основе лежит "незнание универсальных метрик". Есть просьба, в след. раз вы уж постарайтесь свои доводы строить на том, что знаете, а то ерунда получается.[/uquote]
Попробуйте объяснить человеку с черно-белым зрением, что такое цвет. Когда у вас не получится, будет ли это означать, что вы глупы?

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

[a5021]

[uquote="Reflector",url="/forum/viewtopic.php?p=3447180#p3447180"]И чем такой подход лучше?[/uquote]
Я ж вроде сказал уже, что нет переключения контекста. Есть и еще небольшие тонкости в виде отсутствия необходимости работы с неоптимизируемыми volatile.

Допустим прочитали ISPR, там выставлен 10 флаг и сразу после чтения выставляется 9-й, следовательно нужно выполнить 10 проверок, потом обработку, еще 9 проверок и только потом мы доберемся до функции, в которую с прерываниями(за счет большего приоритета) могли бы попасть через полтора десятков тактов, а то, что флаги проверяемые в конце связаны с не самыми частыми событиями еще не означает, что реагировать на них можно медленнее, бывает и наоборот.

Проверка одного флага это четыре команды. Вот такой код:

Спойлер

Код: Выделить всё

for (;;) {
    while (DEFAULT_ISPR_STATE == NVIC->ISPR[0]) {
      //
    }
    /* 1 */ if (NVIC_GetPendingIRQ(DMA1_Channel2_3_IRQn)) {
      // SPI1 data arrived
      NVIC_ClearPendingIRQ(DMA1_Channel2_3_IRQn);
      // ...
      continue;
    /* 2 */ } else if (NVIC_GetPendingIRQ(DMA1_Channel4_5_IRQn)) {
      // USART1 data arrived
      NVIC_ClearPendingIRQ(DMA1_Channel4_5_IRQn);
      // ...
      continue;
    /* 3 */ } else if (NVIC_GetPendingIRQ(DMA1_Channel1_IRQn)) {
      NVIC_ClearPendingIRQ(DMA1_Channel1_IRQn);
      // ...
      continue;
    /* 4 */ } else if (NVIC_GetPendingIRQ(I2C2_IRQn)) {
      NVIC_ClearPendingIRQ(I2C2_IRQn);
      // ...
      continue;
    /* 5 */ } else if (NVIC_GetPendingIRQ(I2C1_IRQn)) {
      NVIC_ClearPendingIRQ(I2C1_IRQn);
      // ...
      continue;
    /* 6 */ } else if (NVIC_GetPendingIRQ(TIM16_IRQn)) {
      NVIC_ClearPendingIRQ(TIM16_IRQn);
      // ...
      continue;
    /* 7 */ } else if (NVIC_GetPendingIRQ(ADC1_IRQn)) {
      NVIC_ClearPendingIRQ(ADC1_IRQn);
      // ...
      continue;
    /* 8 */ } else if (NVIC_GetPendingIRQ(EXTI0_1_IRQn)) {
      NVIC_ClearPendingIRQ(EXTI0_1_IRQn);
      // ...
      continue;
    /* 9 */ } else if (NVIC_GetPendingIRQ(TIM1_BRK_UP_TRG_COM_IRQn )) {
      NVIC_ClearPendingIRQ(TIM1_BRK_UP_TRG_COM_IRQn );
      // ...
      continue;
    /* 10 */ } else if (NVIC_GetPendingIRQ(RTC_IRQn)) {
      NVIC_ClearPendingIRQ(RTC_IRQn);
      // ...
    }

  }

Разворачивается в последовательность однотипных блоков вида:

Спойлер

Код: Выделить всё

    107              /* 8 */ } else if (NVIC_GetPendingIRQ(EXTI0_1_IRQn)) {
   \                     ??main_8: (+1)
   \   0000006E   0x6837             LDR      R7,[R6, #+0]
   \   00000070   0x097F             LSRS     R7,R7,#+5
   \   00000072   0x4027             ANDS     R7,R7,R4
   \   00000074   0xD001             BEQ      ??main_9
    108                NVIC_ClearPendingIRQ(EXTI0_1_IRQn);
   \   00000076   0x2720             MOVS     R7,#+32
   \   00000078   0xE7E5             B.N      ??main_5
    109                // ...
    110                continue;
    111              /* 9 */ } else if (NVIC_GetPendingIRQ(TIM1_BRK_UP_TRG_COM_IRQn )) {
   \                     ??main_9: (+1)
   \   0000007A   0x6837             LDR      R7,[R6, #+0]
   \   0000007C   0x0B7F             LSRS     R7,R7,#+13
   \   0000007E   0x4027             ANDS     R7,R7,R4
   \   00000080   0xD001             BEQ      ??main_10
    112                NVIC_ClearPendingIRQ(TIM1_BRK_UP_TRG_COM_IRQn );
   \   00000082   0x0107             LSLS     R7,R0,#+4
   \   00000084   0xE7DF             B.N      ??main_5
    113                // ...
    114                continue;
    115              /* 10 */ } else if (NVIC_GetPendingIRQ(RTC_IRQn)) {
   \                     ??main_10: (+1)
   \   00000086   0x6837             LDR      R7,[R6, #+0]
   \   00000088   0x08BF             LSRS     R7,R7,#+2
   \   0000008A   0x4027             ANDS     R7,R7,R4
   \   0000008C   0xD0C3             BEQ      ??main_0
    116                NVIC_ClearPendingIRQ(RTC_IRQn);
   \   0000008E   0x2704             MOVS     R7,#+4
   \   00000090   0xE7D9             B.N      ??main_5

Чуть больше сорока команд придется выполнить ядру, чтобы доковылять до обработчика десятого флага. Много это или мало? Тут, как посмотреть. С учетом, что в конце списка должны находится самые "терпеливые" обработчики, время ожидания обработки в районе микросекунды не такая уж большая плата. Упоминавшийся тут исключительно для красного словца последовательный порт, принимающий данные на скорости 921600 бод, поднимает флажок приема байта примерно каждые 10 микросекунд. Два порта, работающие на такой скорости, с обработчиками событий на 9 и 10 позициях в очереди, не должны испытывать проблем со скоростью реакции на поступающие данные. С выдуванием из мухи слона здесь у вас определенно проблема.

Противоположная ситуация со скоростью и латентностью у верхних обработчиков в списке. Верхние обработчики вчистую выигрывают у прерываний по скорости реакции. Дело может доходить до того, что поллинг уже закончит обработку, в то время, как прерывание еще даже не начнет выполняться. Почему этого не понимают корифеи высоконагруженных систем, для меня загадка.

Вашего мнение о том, в чем я разбираюсь а в чем нет, мне очень не хватало.

Фраза вида: "Когда в проекте больше 1 человека, то на QA проверяют, чтобы код НЕ зависел от квалификации пишущего." является эпитафией вашему авторитетному мнению, уж не знаю, хватало вам этого или нет. Вы можете и дальше нести пургу, но я из нее самовыпиливаюсь.

У него там else if, так что если считать более частые события более приоритетными, то по крайней мере в худшем случае не придется ждать пока не отработают обработчики всех флагов.

Да не понимает он, как работает контроллер прерываний. Вы, получается, тоже. Если __WFE() наверху цикла, то пока все флаги в регистре не будут сброшены, слипа происходить не будет. Цикл будет крутиться до тех пор, пока все обработчики не отработают. События там не теряются. Глупые выдумки вследствие низкой квалификации.

Вы как бы совсем не видите очевидных вещей??? Тогда видимо абдуринизация зашла уже слишком далеко и уже ничем не помочь..

Почитайте все-таки что-нибудь про контроллер прерываний. Там, глядишь, вас и "абдуринизация" меньше преследовать будет.

[jcxz]

[uquote="a5021",url="/forum/viewtopic.php?p=3447446#p3447446"]Чуть больше сорока команд придется выполнить ядру, чтобы доковылять до обработчика десятого флага. Много это или мало? Тут, как посмотреть.[/uquote]
И...? Открыть даташит с растактовкой умеете чтобы посчитать сколько тактов потребуется чтобы доковылять до конца списка? ISR уже давно отработает и выйдёт, а Ваш код ещё даже не доковыляет. А сколько теперь тактов будет тратиться на поиск источника прерывания если их хотя-бы пара десятков?
Да и источники прерываний в средних МК Cortex-M как правило занимают много больше чем 1 регистр как тут у вас. А если в NVIC не один регистр с флагами источников прерываний, а например 4?

[uquote="a5021",url="/forum/viewtopic.php?p=3447446#p3447446"]Верхние обработчики вчистую выигрывают у прерываний по скорости реакции. Дело может доходить до того, что поллинг уже закончит обработку, в то время, как прерывание еще даже не начнет выполняться.[/uquote]
Вы нас тут за дурачков то не держите - хватит ахинею нести. Ваш способ обладает латентностью никак не зависящей от позиции в списке, а только - от числа источников в списке. Хоть в верх своего цикла поставьте хоть в хвост - максимальная латентность всегда будет одинакова. И она будет многократно выше латентности стандартного ISR. Хоть немного матчасть поучите прежде чем позориться.
Если до сих пор не догадались, даю наводку: пришло событие от обработчика в самом хвосте, начали ковылять к нему, проковыляли самый верхних флаг, и тут бах - нежданчик - пришло событие от него! А мы его уже проковыляли. И теперь ему судьба ждать пока мы проковыляем все остальные, обработаем тот кто пришёл первым и поковыляем заново - с начала.
И вот вопрос - сколько придётся ждать этому самому верхнему событию? А теперь если подумаем и учтём ещё время обработки того события, что первым пришло? Тут совсем швах!
И Вы так и не ответили - а как же будете обрабатывать какое-то тяжёлое событие, типа разбора Ethernet-фрейма? А если примерно в одно время с ним придёт ещё и событие о завершении приёма пакета от например гироскопа, и нужно для него довольно тяжёлую математику с фильтрами выполнить? А если тут же ещё и прерывание от ШИМа - и для него посчитать. И пока всё это будете обрабатывать - сколько данных от UART-а на 921600 потеряется?

[uquote="a5021",url="/forum/viewtopic.php?p=3447446#p3447446"]Да не понимает он, как работает контроллер прерываний. Вы, получается, тоже. Если __WFE() наверху цикла, то пока все флаги в регистре не будут сброшены, слипа происходить не будет. Цикл будет крутиться до тех пор, пока все обработчики не отработают. События там не теряются. Придумки от неграмотности.[/uquote]
Да понятно что никто кроме Вас и не понимает. И разработчики чипов все как один - идиоты. Насовали во все МК каких-то ненужных прерываний. И не знали что без них будет и быстрее и лучше.
Упёртый Вы наш, покажите в своём цикле куда впендюрите WFE? А если прерывание случится между чтением регистра флагов прерываний и последующей командой WFE что будет? не задумывались? Правильно - ляжете спать, а событие будет потеряно.
А если таких регистров не 1, а скажем 4? Совсем швах будет!
Вы как видно даже понятия не имеете например об атомарности операций. Рано вам взрослым дядям тут что-то советовать. Почитайте учебники.

[Reflector]

[uquote="a5021",url="/forum/viewtopic.php?p=3447446#p3447446"]Я ж вроде сказал уже, что нет переключения контекста.[/uquote]
Возьмем простенькую задачу, допустим по USART приходит байт раз в 100us, при этом иногда в качестве реакции на него нужно выполнить достаточно тяжелую работу длительностью 1ms. Что будешь делать, заблокируешь свой суперлуп на 1ms и потеряешь десяток байт?

[a5021]

Вы невнимательны. Вся обработка ведется в айдле. Я уже говорил об этом. Вот псевдо-код, который я приводил самым первым:

Код: Выделить всё

  while (DEFAULT_ISPR_STATE == NVIC->ISPR[0]) {
    // делаем то, что мы должны делать в свободное время
    // например, сортируем и обрабатываем принятые данные
    // небольшими порциями, чтобы надолго не отвлекаться
  }

максимальная латентность всегда будет одинакова

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

[Reflector]

[uquote="a5021",url="/forum/viewtopic.php?p=3447553#p3447553"]Вы невнимательны. Вся обработка ведется в айдле. Я уже говорил об этом. Вот псевдо-код, который я приводил самым первым:[/uquote]
Ок, внутри этого айдла начала выполнение функция длительностью 1ms, через 100us приходит очередной байт, чтобы его не потерять нужно прервать работу этой функции, перейти к коду опрашивающему кучу флагов, принять байт и вернуться чтобы закончить начатую работу, причем провернуть такое нужно неоднократно. Или как?

[a5021]

Я теряю терпение. Ну русским языком же написано, что "небольшими порциями, чтобы надолго не отвлекаться". Я пишу уже третье сообщение, чтобы донести до вас эту простую вещь.

[Reflector]

[uquote="a5021",url="/forum/viewtopic.php?p=3447573#p3447573"]Я теряю терпение. Ну русским языком же написано, что "небольшими порциями, чтобы надолго не отвлекаться". Я пишу уже третье сообщение, чтобы донести до вас эту простую вещь.[/uquote]
Т.е. моя простенькая задача оказалась слишком сложной для твоего подхода? Спасибо за терпение, больше вопросов не имею

[a5021]

[uquote="Reflector",url="/forum/viewtopic.php?p=3447578#p3447578"]Т.е. моя простенькая задача оказалась слишком сложной для твоего подхода?[/uquote]
Слишком сложным оказалось переводить по три раза с русского на русский одно и то же предложение. Хуже всего, что это еще и никак не помогло в итоге.

[WiseLord]

небольшими порциями, чтобы надолго не отвлекаться

В этом случае сравнительно простая, но длинная по времени задача может усложниться из-за её дробления. Придётся как-то сохранять её состояние, чтобы, временно вернувшись к циклу чтения флагов, и снова назад, восстановить его.

Возможно, где-то такой подход и хорош, но всё же... Потратить 12 тактов (вроде столько упоминалось) на переключение контекста, это дешевле, чем обработать даже три флага (если считать каждую операцию в приведённом ассемблерном листинге выполняемой за один такт) в названном так "суперцикле". Плюс не нужно усложнять задачу - делать её "дробимой" на кусочки. В случае прерываний это просто не нужно.