Кому в микроконтроллере жить хорошо?


    В каком году — рассчитывай, в какой земле — угадывай, задачился вопросами. Насколько ARM быстрее AVR? Какая разновидность протокола Modbus более «быстрая»? ASCII или RTU?

    Под «быстротой», в данном случае, будем понимать количество машинных циклов процессора необходимых для исполнения всех действий протокола.
    Исследование быстродействия будем проводить на, широко известной в узких кругах, библиотеке ModBus Slave RTU/ASCII, портированной на микроконтроллеры ATMega48 и STM32L052. Вывод информации будем осуществлять по протоколу Modbus в эмулятор панели Weintek. Тестирование будем производить на демонстрационном примере. Помимо результатов теста на панель выводятся состояния регистров Modbus: дискретных входов, дискретных выходов, регистров для чтения и регистров для чтения/записи. Также средствами панели производится подсчет количества ошибок обмена данными с микроконтроллером. Внешний вид тестового окна приведен на рисунке.



    Оценку быстродействия будем проводить измеряя время выполнения функции обработки сообщений протокола. Измерение времени выполнения будем проводить рабоче-крестьянским способом. Перед запуском функции обнуляем аппаратный таймер, частота счета которого равна тактовой частоте микроконтроллера, после выполнения функции считываем значения таймера и проводим обработку результатов измерений. Вычисляем минимальное, максимальное и среднее значение времени выполнения функции обработки сообщений протокола Modbus.

    while(1)
        {
        TIM6->CNT=0;
        ModBusRTU();
        //ModBusASCII();
        tcurent=TIM6->CNT;
        if(tcurent<tmin)tmin=tcurent;
        if(tcurent>tmax)tmax=tcurent;
        avg32=avg32-(avg32>>16)+tcurent;
        tavg=avg32>>alfa;
        ...
    

    Результаты исследований, сведены в таблицу. Исследование проводились при различных опциях библиотеки:

    • ModBusUseTableCRC — Использовать расчет CRC по таблице;
    • ModBusUseErrMes — Использовать сообщения о логических ошибках протокола;

    А также при различных стратегиях оптимизации компилятора.
    Библиотека ModBus Slave RTU/ASCII поддерживает, в некоторых случаях, важную функцию — пауза между получением запроса от Modbus Master и ответом Modbus Slave. Исследование проводились при значениях паузы 2 милисекунды и 0 (то есть без паузы), эти значения указаны в графе таблицы «Пауза П/П». В графе «Размер» указан размер модуля, который включает в себя обе функции обработки сообщений Modbus (ModBusRTU(), ModBusASCII()).



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

    Глубоко задумавшись над результатами исследований, можно сделать следующие выводы:

    1. AVR не такой уж медленный!!! В среднем он в полтора раза медленнее ARM при той же тактовой частоте. А в случае оптимизации по размеру (например варианты 13 и 15) практически приближается к ARM.
    2. Протокол ASCII, по сравнению c RTU, не только более медленный по скорости передачи, но и занимает гораздо больше ресурсов микроконтроллера.
    3. Использование сообщений о логических ошибках протокола, никак не влияет на быстродействие.
    4. Табличный метод вычисления CRC позволяет более чем в полтора раза снизить использование вычислительных ресурсов микроконтроллера.
    5. Использование паузы между приемом запроса и передачей ответа, позволяет не только избежать конфликтов на шине RS-485, но и уменьшить блокирующие действие функции обработки сообщений протокола Modbus.

    Какие выводы еще можно сделать?

    Проект на GitHub


    Скачать одним файлом



    UPD. Обновил проект на GitHub!
    Переписал функцию вычисления CRC по таблице, время выполнения функции сократилось на 32%
    Итоговое быстродействие Modbus RTU для наилучшего случая (вариант 8):
    AVR среднее-105; минимальное-99; максимальное-1924;
    STM32 среднее-86; минимальное-59; максимальное-1293;

    Снижение максимального времени выполнения
    STM32L052 — 124 такта
    ATMega48 — 102 такта

    Similar posts

    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 19

      +1
      Любопытно, а с чего имеет место быть такой чудовищный разброс между минимальным и максимальным значениями?
        0
        Имеется в ввиду минимальное и максимальное время выполнения.
        Минимальное время выполнения соответствует ветке кода — «вошли, проверили таймер, таймер не дотикал и вышли» или «вошли проверили прием, принятых данных нет и вышли „
        Максимальное время — завершение приема пакета запроса и формирование пакета ответа.

        +2
        AVR не такой уж медленный!!! В среднем он в полтора раза медленнее ARM при той же тактовой частоте.

        Так а с чего бы ему быть сильно медленнее при той же тактовой? Это ж не задача на числодробление, CRC считается на битовых операциях… я не очень хорошо помню, как там дела в AVR, но вроде в основном не хватает (по сравнению с ARM) четырехбайтных целых и быстрых делений-умножений, которые в вашей задаче особо без надобности?

          0
          В stm32L052 можно CRC считать через хардварный модуль и еще немного выиграть в скорости расчета и памяти на таблицах. Можно эффективно использовать DMA на прием и передачу и выиграть на процессорном времени. Ну и вишенка на торте, в stm32L052 есть у UART аппаратное обнаружение конца посылки для RTU и ASCII modbus.
          C использованием всей этой хардварщины интересно насколько эффективнее stm32 с точки зрения процессорного времени и памяти. Используя все эти плюхи я влез в 5 кБ прошивки (это правда с FreeRTOS уже вместе).
            0

            Резонно.

              0
              Именно. Автор сравнил теплое с мягким и сделал далеко идущие выводы. Понятно, что на битовых операциях с 8-битными числами ARM ничего особенного не покажет. Сила ARM — в более мощной периферии и на более навороченной арифметике. Это если сравнивать только примерно одинаковые контроллеры с близкими тактовыми частотами.
                +1
                По большому счеты правильное суждение, но не совсем правильное объяснение:
                Сила ARM — в более мощной периферии и на более навороченной арифметике

                ARM — это ядро, периферии там по большому счету нет. Сила ARM в гарвардской архитектуре ядре со всеми вытекающими. Математика это так же отдельные блоки, такие как DSP и FPU (DPU в более навороченных).

                периферия это уже к производителю МК, чего они уже там накрутят. Тот же STM далеко не лидер в наличии «интересной» периферии.
                  0
                  ARM в отрыве от конечной реализации — это нонсенс. А в конечной реализации от производителя хардварных плюшек в разы больше, чем у AVR. Разве что nrf518xx можно как-то сравнивать из известных мне, все остальные гораздо продвинутее, что хотя бы по даташитам видно, где самого ядра толком и нет.
              0
              АВР не медленный только когда достаточно 8 бит и нужен ногодрыг. Как только начинается числодробилка — на АВР жалко смотреть. Ну и ДМА само по себе очень сильно разгружает ядро от пересылок данных, тот же Модбас можно принять на СТМ32 кроме Ф1 серии полностью автоматически, с единственным прерыванием по настраиваемому таймауту после последнего бацта пакета. На АВР вы будете отвлекаться на каждый байт. А если одновременно работает десяток интерфейсов?
                0

                Я имел в виду — конкретно в реализации из поста, а не вообще.

              0
              Мне кажется тест необходимо было поделить по функциям (чтение дискретных сигналов и регистров).
              0
              наверное корректнее было бы сравнивать с stm8, потому как avr 8-ми битная
              ну и сам модбас оперирует байтами, и нет особых причин из за которых была бы большая разница
                0
                Тест не совсем корректный, т.к. не учитывает качество самого кода. Если под AVR написать на Ассемблере, а STM32 — на HAL, то AVR может оказаться быстрее. У меня вся библиотека модбаса для STM32 1,5...2 кБ ПЗУ (чтение, запись, эхо), здесь же 3...6 кБ, это явно с HAL.
                  +1
                  1) Для АВР, и для СТМ, компилировался один и тот же код
                  2) В модуле как-бы две библиотеки, RTU и ASCII
                  3) Каждая содержит модбас функции 1,2,3,4,5,6,15,16,22
                  4) Код модуля Модбас полностью отвязан от аппаратуры, и использует 3 функции для связи с системой ModBusSysTimer, ModBusPUT(), ModBusGET()
                  5) в СТМ ModBusGET() работает через ПДП

                  –2
                  Сравнивать Modbus RTU с Modbus ASCII нет смысла, первый настолько популярный, что я даже не знаю, как там работает ASCII, он как бы нафиг не нужен. Но точно знаю, разница там в пользу Modbus TCP. =)
                  Коммуникационные задачи должны выполняться отдельным процессором, особенно если этот процессор может выполнять кучу своих задач, которые нагрузят его так, что коммуникация развалится. Тут уже инженер должен решать — AVR сойдет или STM надо применить.
                    0
                    я даже не знаю, как там работает ASCII, он как бы нафиг не нужен


                    Гм, ну ладно. У всех свои миры )))
                    0
                    Как-то непривычно читать статьи без вводной части, хотя бы короткой.
                      0
                      Обновил проект!
                      Переписал функцию вычисления CRC по таблице, время выполнения функции сократилось на 32%
                      Итоговое быстродействие Modbus RTU для наилучшего случая (вариант 8):
                      AVR среднее-105; минимальное-99; максимальное-1924;
                      STM32 среднее-86; минимальное-59; максимальное-1293;
                      Снижение максимального времени выполнения
                      STM32 — 1417-1293=124 такта
                      AVR — 2026-1924=102 такта

                      Only users with full accounts can post comments. Log in, please.