Пишем загрузчик ПЛИС в LabVIEW. Часть 1

[@red_perez]

У большинства «нормальных» программистов, мягко говоря, неоднозначное отношение к технологии LabVIEW

Я на Лабьвью уже >20 лет работаю, ну да, соглашусь, отношение не всегда однозначное, однако бывают довольно хлебные места где этот редкий скилл очень даже востребован.

По сабжу добавлю 5 копеек, я за правило взял в случае применения Event структур делать программу по схеме — Producer-Consumer.
То есть Ивент генерит строго говоря одни ивенты, а обработка происходит в отдельной петле. Но это так — «бэст практис», чисто для поддержания разговора.

[@Shamrel]

Интересно было бы взглянуть на пример.

[@red_perez]

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

Это бест практис для интерфейсов, все что стоит внутри Event Structure затормаживает регистрацию следующего ивента пока старый не обработан полностью. Потому выносим из Event Structure все что возможно.
Иначе интерфейс тормозит и лагает.

[@Shamrel]

Согласен, красивое решение. Актуально, только если обработчик занимает много времени. В рассматриваемой задаче, даже непосредственно загрузка бинарника происходит за ~10 мс, потому усложнять не буду.

[@Iryaz]

Интересно, в программе на LabView можно выделять отдельные потоки для каждой операции?

[@red_perez]

Интересно, в программе на LabView можно выделять отдельные потоки для каждой операции?

Да, моя картинка сверху это такой случай 2 независимые петли While = 2 потока.

Если не ошибаюсь начиная с версии 2015 в цикл FOR встроена нативная многопоточность, по правой кнопке включаете configure iteration parallelism и там появляются дополнительные терминалы P,C которые позволяют разделить вычисления на разные потоки.

[@Shamrel]

Круто! Действительно есть такое. Не знал. Я недавно только поставил 18-версию. Когда-то давно работал много на 12-ой, там такого не помню.