Пара раз начинал писать эту статью и бросал. Бросал вследствие того что тема, как мне думается, пара спорная. Изобретенный мною велосипед может кому-то показаться забавным и нелепым и по большому счету не совсем корректным.

Однако…По большому счету, мне думается, что в области разработки электронных устройств существует как бы пара мало пересекающихся миров. К примеру, существует разработка устройств на базе микроконтроллеров и параллельно существует разработка устройств на базе ПЛИС. Принципы работы этим микросхем принципиально отличаются и совершенно верно так же отличаются методы и принципы разработки, применяемые отладки и языки программирования.

Само собой разумеется, выбор элементной базы во многом зависит от поставленной задачи. Но и без того ясно, что эти миры, мир и мир микроконтроллеров ПЛИСов практически не пересекаются. Возможно на стыке разработок что-то имеется?
Смотрите кроме этого: Проект open source GPU на Kickstarter

На Kickstarter недавно стартовал интересный проект. Его цель — создать открытый [тут каждый абсурд маркетологов] и современный графический процессор. Под современностью создатель подразумевает совместимость с OpenGL и D3D.

Упоминается реализация всего этого на языке Verilog, т.е. подразумевается, что готовая плата будет выполнена на базе FPGA. С одной стороны, это разрешит скоро взлететь и в возможности перейти на заказные чипы, с другой — до этого перехода соотношение цена/уровень качества возможно не на высоте. Не смотря на то, что душу обладателя таковой карты будет греть открытость исходников.

Сам я, в общем, больше предпочитаю ПЛИС а также участвую в блоге о ПЛИС, но, сравнительно не так давно наша фирма взялась за разработку устройства на базе микроконтроллера STM32. Фактически главные неприятности, каковые мы встретили были не совсем технические, а скорее организационные.Дело в том, что не обращая внимания на заключенный соглашение о разработке устройства и не обращая внимания на наличие более-менее согласованного ТЗ на устройство так оказалось, что каждую семь дней клиент приходил с новыми идеями, требованиями, пожеланиями и мыслями.

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

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

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

Я в шоке. Мы, само собой разумеется, стараемся писать программы «без неточностей», но думаю принимающая сторона то же как-то обязана дробить ответственность, проводить собственные опробования и т.д…Потом перейду фактически к технической стороне дела. Мы сделали вывод, что нам необходимы собственные какие-то тесты ПО микроконтроллера.

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

Не смотря на то, что… не все возможно легко проверить юнит тестами в микроконтроллере. Все что связано с программированием внутренних аппаратных устройств наподобие таймеров, каналов DMA, последовательных портов, прерываний и без того потом – с этим имеется неприятности. Тут для отладки в пору брать осциллограф и наблюдать какие конкретно сигналы микроконтроллера получаются на входах-выходах.

И по большому счету померить какое количество по времени идет обработка прерывания – дело не лишнее. И это верно.Имеется еще один нюанс с юнит тестами. Как мне думается, простое юнит-тестирование ПО ориентированно на эти.

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

Ну другими словами требования в большинстве случаев такие: при происхождении срабатывании и нештатной ситуации аварийного датчика A последовательно с промежутком в N1 секунд отключить аккуратные устройства B, C, а устройство D отключить не позднее N2 секунд но не раньше N3 секунд, Что-то наподобие этого.Ясно, что для проверки метода управления программно прекрасно бы применять какой-то симулятор сигналов с учетом течения времени. И такие средства имеется в арсенале… у разработчиков совокупностей на ПЛИС.Разработчик электронных устройств на базе ПЛИС в большинстве случаев применяет язык описания аппаратуры Verilog либо VHDL.

Наряду с этим, не считая кода для ПЛИС пишутся так именуемые testbench – это и имеется что-то наподобие unit-test для простого программиста на Си.Я использую Verilog HDL.Программу тестбенч пишет сам программист и наряду с этим старается симулировать все вероятные входные действия на микросхему ПЛИС. Выходные сигналы анализируются самим тестбенчем и проверяются в соответствии с ожидаемыми.Наряду с этим, сам симулятор Verilog смотрит за течением времени в совокупности.Разглядим несложной и совсем слишком общий пример, что делает программист ПЛИС.К примеру, вот модуль, что обрисовывает несложной бинарный счетчик с асинхронным сбросом (sample.v):module sample( input wire reset, input wire clk, output reg [3:0]cnt );always @(posedge clk or posedge reset) if(reset) cnt Думаю таковой код осознает любой программист, кроме того и не опытный языка Verilog HDL.

Имеется два входных сигнала reset и clk. И имеется выходной четырехбитный сигнал [3:0]cnt. Неизменно по фронту тактового сигнала значение в счетчике возрастает. И неизменно при появлении единицы на reset счетчик обнуляется.Данный модуль синтезируемый, другими словами его планируется откомпилировать и зашить в ПЛИС.Сейчас, к примеру, программист желает проверить работоспособность собственного модуля.

Он пишет программу на Verilog, тестбенч, что будет имитировать входные сигналы для микросхемы (testbench.v):`timescale 1ms / 1 msmodule testbench();reg tb_rst, tb_clk; wire [3:0]value;always #5 tb_clk = ~tb_clk;initial begin $dumpfile(waves.vcd); $dumpvars(0,testbench); $display(starting testbench!!!!); tb_rst = 1; tb_clk = 0; #10; tb_rst = 0; #73; tb_rst = 1; #11; tb_rst = 0; #134; tb_rst = 1; #57; tb_rst = 0; #200; $display(finished OK!); $finish; endsample my_sample_inst( .reset(tb_rst), .clk(tb_clk), .cnt( value ) );wire fail; assign fail = (tb_rst value!=0 );endmodule Данный модуль не синтезируемый, его нельзя откомпилировать и зашить в ПЛИС, но он нужен для симуляции проекта. Обратите внимание на строчки sample my_sample_inst( .reset(tb_rst), .clk(tb_clk), .cnt( value ) ); Это в тестбенч засунут исследуемый экземпляр модуля sample.

Получается вот так:Весьма быть может, что у нас имеется критерий работоспособности проекта. Нам необходимо, дабы на протяжении сигнала reset выходные сигналы счетчика были неизменно в нуле. Другими словами мы можем в тестбенче выяснить сигнал неточности:wire fail; assign fail = (tb_rst value!=0 ); Данный сигнал возможно программно мониторить либо глазами на выходных временных диаграммах.Я довольно часто использую несложной вольный симулятор VerilogHDL IcarusVerilog.

Его и трудиться с ним. Компилирую и запускаю симулятор:Мой тестбенч благодаря строчкам программы $dumpfile(«waves.vcd»); и $dumpvars(0,testbench); формирует файл с временными диаграммами waves.vcd.

И эти временные диаграммы возможно взглянуть посредством другого превосходного свободного инструмента GtkWave:Так, самое простое, что может сделать программист ПЛИС – это написать к тестируемому модулю тестбенч и сгенерировать файлы оказавшихся временных диаграмм и разглядывать их, наблюдать верный ли отклик идет от ПЛИС.Сейчас поведаю, как возможно похожую разработку тестирования применить к микроконтроллерам.В случае если обратите внимание еще раз на Verilog тестбенч, то увидите в том месте кое-какие системные функции наподобие $display(..).Так вот. Выясняется, для симулятора Verilog HDL возможно самому дописывать необходимые нам системные функции на языке Си.

А раз появляется место для языка Си, то появляется место, где код Verilog тестбенча может взаимодействовать с Сишным кодом для микроконтроллера.По большому счету, интерфейс симулятора Verilog к языку Си именуется Verilog Procedural Interface (VPI). Говорить про него возможно продолжительно, это громадная отдельная тема. Возможно больше почитать, к примеру, вот тут.Я же желаю легко схематично проиллюстрировать, как это возможно использовано.Проект для микроконтроллера может складываться из многих файлов.

Отечественная задача отделить фактически метод управления от аппаратных изюминок конкретного микроконтроллера.Предположим, проект для микроконтроллера складывается из файлов:Main.c Dma.c Serial.c Interrupts.c …. Algorithm.c Обработчики прерываний от входных линий микроконтроллера обрисованы в файле Interrupts.c. Они являются что-то наподобие этого:void EXTI9_5_IRQHandler(void) { Int val; disableGlobalInterrupts(); EXTI_ClearITPendingBit(EXTI_Line6); val = GPIO_ReadInputDataBit(MY_PORT, MY_SIGNAL);Algo_set_value( val ); enableGlobalInterrupts(); } В то время, когда сигнал на входной линии микроконтроллера изменяется, то происходит прерывание, в нем производится чтение значения на линии и это значение передается функцией Algo_set_val() методу обработки.

Целый метод управления обрисован в файле Algorithm.c.Файл Algorithm.c в один момент участвует в проекте для микроконтроллера и в проекте для VPI модуля Verilog.Так, разрабатывая «метод управления» мы по большей части компилируем VPI модуль вместе с Algorithm.c для Verilog симулятора. Вызывая в тестбенче Verilog нами определенную новую системную функцию $int() мы имитируем происхождение прерывания микроконтроллера в некий момент времени.

Совершенно верно так же, внутренние переменные метода возможно просматривать и передавать тестбенчу Verilog посредством новой нами определенной системной функции $getpin(..). Получается, что отечественный Verilog тестбенч может имитировать течение и входные воздействия времени для метода управления микроконтроллера.Любопытно, что мы приобретаем в собственный распоряжение временные диаграммы входных откликов и воздействий. Их возможно продемонстрировать клиенту с целью ознакомления – для их просмотра употребляется программа GtkWave.

Клиент собственными глазами сможет разглядеть, как входные действия от разных датчиков будут откликаться его методом управления. Клиент обязан заметить все вероятные комбинации действий от входных сигналов и все отклики «тёмного коробки» называющиеся микроконтроллер.По крайней мере, на временных диаграммах возможно заметить, как виртуально включается насос на 10 секунд раз в день…Последний этап – перестаем компилировать VPI модуль для Verilog симулятора (фиолетовый блок) и начинаем компилировать проект микроконтроллера (оранжевый блок).Сейчас функции метода будут вызываться не из виртуальных действий симулятора Verilog, а из физических прерываний от таймеров и входных линий.На всякий случай еще раз увижу, что посредством отечественного Verilog тестбенча мы само собой разумеется не контролируем правильность программирования регистров периферийных устройств наподобие DMA либо таймеров либо GPIO.

Мы тестируем лишь «метод управления». На мой взор и это весьма и крайне важно.Ну вот как-то так.

Случайная статья:

• Android. пятничный обзор софта 6
• Как найти человека в инстаграме?

Направления в программировании — Вопросы и Ответы #5

Похожие статьи:

• Какой язык программирования выбрать для создания приложений на android?

  Вы являетесь активным пользователем совокупности Android и вас впечатляет практически каждое приложение, созданное под эту оболочку, но в каждом из них…

• Как на макбуке поменять язык?

  Язык клавиатурного ввода есть главным инструментом сотрудничества человека с компьютером, а функцию переключения с одного языка на другой на протяжении…

• Рюкзак для программиста

  Главным рабочим инструментом увлечённого своим делом программиста есть ноутбук. Ты не привязан к конкретному офисному столу, да и по большому счету к…