Защо езикът Verilog за програмист на микроконтролер

Няколко пъти започнах да пиша тази статия и се отказах. Отказвам се, защото темата, струва ми се, е малко спорна. Велосипедът, който изобретих, може да изглежда смешен и абсурден за някого и изобщо не е напълно правилен. Въпреки това…

Като цяло ми се струва, че в областта на разработването на електронни устройства има, така да се каже, няколко малки пресичащи се свята. Например има разработване на устройства, базирани на микроконтролери и успоредно с това има разработване на устройства, базирани на FPGA. Принципите на работа на тези микросхеми са фундаментално различни, а принципите и методите на разработка, използваните езици за програмиране и отстраняване на грешки са абсолютно еднакви. Разбира се, изборът на елементна база силно зависи от поставената задача. Ясно е обаче, че тези светове, светът на микроконтролерите и светът на FPGA почти не се пресичат. Може би има нещо в пресечната точка на технологиите?

Аз самият като цяло предпочитам FPGA и дори участвам в блог за FPGA, но наскоро нашата компания се зае с разработването на устройство, базирано на микроконтролера STM32. Всъщност основните проблеми, които срещнахме не бяха чисто технически, а по-скоро организационни.

Факт е, че въпреки сключеното споразумение за разработване на устройството и въпреки наличието на повече или по-малко договорена техническа спецификация за устройството, се случи така, че всяка седмица клиентът идваше с нови идеи, изисквания, мисли и желания. Разбира се, можехме да ги пратим по дяволите, но решихме, че ще се опитаме да имаме търпение и все пак да изпълним проекта.

Основният организационен проблем е, че имаше много искания за промяна на алгоритъма за управление на контролера и те често бяха много противоречиви. Освен това самият клиент не беше сигурен как трябва да работи и дори не разбираше как работище провери всичко. По-точно би било да се каже така. Има ръководители, които искат да имат определен контрольор в своето звено. Самите мениджъри не знаят точно какви точно функции трябва да има контролерът и устройството, а изискванията трябваше да бъдат формирани от единствения инженер, който трябваше да провери работата на устройството. Инженерът няма собствена методика за проверка на работата на контролера, тъй като няма опит в работата с електронни устройства.

Ето един пример. В режим на готовност, когато контролерът просто чака да бъде натиснат бутона "Старт", нашият контролер трябва да включи помпата, която изпомпва течността за 10 секунди веднъж на ден. Това е вид защита срещу подкисляване на уплътненията на помпата. Когато питам; "как ще проверите тази функция" - те отговарят, че "няма начин". Лично аз съм шокиран. Разбира се, ние се опитваме да пишем програми „без грешки“, но мисля, че приемащата страна трябва по някакъв начин да сподели отговорността, да провежда свои собствени тестове и т.н.

След това ще премина към техническата страна на въпроса.

Решихме, че имаме нужда от собствени софтуерни тестове за микроконтролери.

Обикновено в света на софтуера има такова нещо като тестване на единици. И по принцип тази техника е до известна степен подходяща за програми за микроконтролери. Понастоящем програмите за микроконтролери често се пишат на обичайния език C, така че като цяло не би трябвало да има проблеми с модулните тестове. Въпреки че… не всичко може лесно да се провери чрез тестове на единици в микроконтролера.

Всичко, свързано с програмиране на вътрешни хардуерни устройства като таймери, DMA канали, серийни портове, прекъсвания и т.н. - има проблеми с това. Тук, за отстраняване на грешки, е време да вземете осцилоскоп и да видите какви сигнали на микроконтролера се получават на входовете и изходите. И като цяло мери колко време отнемаобработката на прекъсвания не е излишна. И е правилно.

Има още един нюанс с модулните тестове. Струва ми се, че конвенционалното тестване на софтуерни модули се управлява от данни. Е, обикновено програмата за тестване на единица захранва различни хипотези към входа на тестваната функция и след това проверява дали обработеният изход отговаря на изискванията. Всичко.

За електронно устройство, което действа като процесор на входни сигнали, концепцията за "времеви поток" е фундаментално важна. Well, that is, the requirements are usually the following: in the event of an emergency situation and the emergency sensorAis triggered, sequentially with an interval ofN1seconds, turn off the actuatorsB,C, and turn off the deviceDno later thanN2seconds but not earlier thanN3seconds, Something like this.

Ясно е, че за тестване на софтуерния алгоритъм за управление би било добре да се използва някакъв симулатор на сигнала, като се вземе предвид изтичането на времето. И такива инструменти са в арсенала ... на разработчиците на системи, базирани на FPGA.

Разработчикът на електронни устройства, базирани на FPGA, обикновено използва езика за описание на хардуера Verilog или VHDL. В същото време, в допълнение към кода за FPGA, е написан така нареченият testbench - това е нещо като unit-test за обикновен C програмист.

Използвам Verilog HDL. Програмата за изпитване е написана от самия програмист и в същото време се опитва да симулира всички възможни входни действия на FPGA чипа. Изходните сигнали се анализират от самия тестов стенд и се проверяват според очакванията. В същото време самият симулатор на Verilog следи изтичането на времето в системата.

Помислете за прост и напълно абстрактен пример за това какво прави FPGA програмист. Например, тук е модул, който описва прост двоичен брояч с асинхронно нулиране(sample.v):

Мисля, че всеки програмист ще разбере такъв код, дори и тези, които не знаят езика Verilog HDL. Има два входни сигналаresetиclk. И има изходен четирибитов сигнал [3:0]cnt. Винаги на границата на тактовия сигнал, стойността в брояча се увеличава. И винаги, когато едно се появи наreset, броячът се нулира.

Този модул е синтезиран, т.е. планира се да се компилира и зашие в FPGA.

Сега, например, програмист иска да провери производителността на своя модул. Той пише програма във Verilog, тестова стенда, която ще симулира входните сигнали за чипа (testbench.v):

Този модул не е синтезиран, не може да бъде компилиран и зашит в FPGA, но е необходим за симулиране на проекта. Обърнете внимание на линиите

Това е тестваният екземпляр на примерния модул, поставен в тестовия стенд. Получава се така:

Много е възможно да имаме критерий за ефективност на проекта. Искаме изходите на брояча винаги да са на нула по време на сигналаreset. Тоест можем да дефинираме сигнал за грешка в тестовия стенд:

Този сигнал може да бъде програмно наблюдаван или просто гледан с очите на изходните времеви диаграми.

Често използвам простия безплатен симулатор IcarusVerilog VerilogHDL. Лесен е за инсталиране и работа с него. Компилирайте и стартирайте симулатора:

Моят тестов стенд благодарение на $dumpfile("waves.vcd"); и $dumpvars(0,testbench); създава файл с вълнови форми waves.vcd. И тези времеви диаграми могат да се видят с друг чудесен безплатен инструмент GtkWave:

По този начин най-простото нещо, което програмистът на FPGA може да направи, е да напише тестова стенда на тествания модул и да генерира файлове с полученитевремеви диаграми и ги прегледайте, вижте дали правилният отговор идва от FPGA.

Сега ще ви кажа как можете да приложите подобна технология за тестване на микроконтролери.

Ако погледнете отново стенда за тестване на Verilog, ще забележите някои системни функции като $display(..) там.

Така. Оказва се, че за Verilog HDL симулатора можете сами да добавите системните функции, от които се нуждаем, на езика C. И тъй като има място за езика C, значи има място, където кодът на Verilog на тестовата стенда може да взаимодейства с кода C за микроконтролера.

Като цяло интерфейсът на симулатора Verilog към езика C се нарича Verilog Procedural Interface (VPI). Можете да говорите за това дълго време, това е голяма отделна тема. Можете да прочетете повече, например, тук.

Просто искам схематично да илюстрирам как това може да се използва. Проектът за микроконтролер може да се състои от много файлове. Нашата задача е да отделим действителния алгоритъм за управление от хардуерните характеристики на конкретен микроконтролер.

Да предположим, че проект за микроконтролер се състои от файлове:

Обработчиците на прекъсвания от входните линии на микроконтролера са описани във файла Interrupts.c. Те са нещо подобно:

Когато сигналът на входната линия на микроконтролера се промени, възниква прекъсване, той чете стойността на линията и тази стойност се прехвърля от функцията Algo_set_val () към алгоритъма за обработка. Целият алгоритъм за управление е описан във файла Algorithm.c.

Файлът Algorithm.c участва едновременно в проекта за микроконтролера и в проекта за VPI на модула Verilog.

Поне на времевите диаграми можете да видите как помпата е виртуално включена за 10 секунди всеки ден ...

Последната стъпка - стопкомпилирайте VPI модула за симулатора Verilog (лилав блок) и започнете да компилирате проекта за микроконтролер (оранжев блок).

Сега функциите на алгоритъма няма да се извикват от виртуални действия на симулатора Verilog, а от физически прекъсвания от входни линии и таймери.

За всеки случай отбелязвам още веднъж, че с помощта на нашата тестова стенда Verilog, разбира се, ние не проверяваме правилността на програмирането на регистрите на периферни устройства като DMA или таймери или GPIO. Тестваме само "контролния алгоритъм". Според мен това е много, много важно.

Някак така.

Hardcore conf в C++. Каним само професионалисти.