STM32F4Discovery+LabWindowsCVI. Урок 1. Часть 0. Введение


Многие начинающие или даже имеющие за плечами большой опыт программирования программисты микроконтроллеров сталкиваются с проблемой написания более менее рабочего оконного приложения для управления микроконтроллером с ПК и отображения телеметрии. В большинстве случаев для этого нужно изучать языки программирования высокого уровня, такие как С++ и C#. Процесс изучения этих языков может привести программиста, который всю жизнь программировал только на С в ступор, потому что они очень сильно отличаются от обычного С, а изучение этих языков займет у него очень много времени.
Именно для таких людей компания NationalInstruments выпустила программу LabWindowsCVI, в которой весь код пишется на простом С и человек, который программировал только на С очень легко в ней разберется…
В этом топике хочу представить вам цикл уроков по программированию LabWindowsCVI с использованием отладочной платы STM32F4Discovery…

В процессе работы мы напишем простое приложение :

С помощью этого приложения мы сможем:
- -Управлять состоянием светодиодов;
-Управлять яркостью синего светодиода;
-Получать значения угловых ускорений со встроенного акселерометра;
-Изменять значения на выходе ЦАП и изменять его с помощью АЦП.
Видео, демонстрирующее работу приложения представлено ниже:
Спасибо за внимание!
- 0
- 05 января 2018, 23:53
- zzzkorn
NashionalInstrumentsОно, все-таки, National Instruments)
Ну и система называется LabWindows/CVI, а не LabWindowCVI.
-Получать значения угловых скоростей со встроенного акселерометра;Акселерометр измеряет ускорения.
Хотелось бы надеяться, что в последующих частях будет текст, а не чистый видеоурок.
Я затрудняюсь определить, это сарказм в сторону содержания видео или констатация факта «ютуб не работает»?
7 дней вполне хватит пользователю, чтобы «поиграться», если данная программа заинтересует его, он вполне сможет найти лицензию. Будет ли она легальная или нет, это уже совсем другой вопрос.
У меня между установкой ПО и его первым запуском для пробы вполне уходит месяц и более. Потому как сейчас я занимаюсь своими делами, увидел пост, скачал поставил и дольше решаю свою задачу. А когда с ней закончу возьмусь посмотреть что это такое, и опять же это будет не 8 часов в день, 40 в неделю,… Это будет пол часа-час, когда будет возможность. МУспею ли я поиграть с программой за 0-7 часов?
В общем, не состоятельная лицензия для любителей, даже и рассматривать не стоит.
В общем, не состоятельная лицензия для любителей, даже и рассматривать не стоит.
Qt + MinGW, бесплатно, удобно, куча примеров и даже книг. Сигнально-слотовая система похожа на прерывания МК :-) Программирование относительно простое, накидал элементы интерфейса, и дальше с ними как с объектами периферии МК работаешь, язык тот же С++ с небольшими особенностями Qt. Довод автора что С++ прям на голову сложнее С как-то сомнителен, почти любой более менее сложный проект использует элементы С++, даже Ардуинщики на нем работают :-)
Полноценный С++ — это пиздец, причем полный. Но кьют действительно простой и что весьма немаловажно — не требует знания С++ глубже чем С.
Но если целиться только под винду — я бы взял что-нибудь, на чем хелловорлд не весит 30 метров. C# ныне неплохой выбор. Delphi, Lazarus, Pure Basic как по мне тоже заслуживают внимания.
Но если целиться только под винду — я бы взял что-нибудь, на чем хелловорлд не весит 30 метров. C# ныне неплохой выбор. Delphi, Lazarus, Pure Basic как по мне тоже заслуживают внимания.
Никто не заставляет писать на полноценном С++. если разбираться в чужих исходниках, то да, рехнуться можно. А если для себя утилитки писать, то достаточно «Си с классами». Со временем, и на другой уровень перейти можно будет.
Но вот конкретно под Windows, конкретно Qt, я бы не посоветовал. Уж слишком чужды они друг другу и жутко тормознуто всё работает. На одном и том же железе из одних исходников собранный проект на линуксе работает нормально, а на винде тормозит жутко. Минимум один порядок разница.
Для винду лучше взять C# будет. Имеется бесплатная версия IDE, как от мелкомягких, так и сторонние (если мелкомягкие прикроют халяву). Да и без иде можно, компилятор вшит в систему.
Но вот конкретно под Windows, конкретно Qt, я бы не посоветовал. Уж слишком чужды они друг другу и жутко тормознуто всё работает. На одном и том же железе из одних исходников собранный проект на линуксе работает нормально, а на винде тормозит жутко. Минимум один порядок разница.
Для винду лучше взять C# будет. Имеется бесплатная версия IDE, как от мелкомягких, так и сторонние (если мелкомягкие прикроют халяву). Да и без иде можно, компилятор вшит в систему.
А если для себя утилитки писать, то достаточно «Си с классами».Это уже не столь простая вещь. Начиная с «правила трех», которое на самом деле «пяти с половиной».
Вот пользоваться в С++ чужими, грамотно написанными и хорошо спроектированными библиотеками действительно несложно. Qt — хороший пример такой библиотеки.
P.S. Тормозов за кьютом не замечал, но речь и не об этом.
Си надо обязательно знать, и именно ИЗНАЧАЛЬНО, ну т.е параллельно с асмом. Си без знаний неких понятий (хотя бы начальных) асма — это просто не логично.
Но, ВНЕЗАПНО, мне кажется, что все же будущее за C++ в MCU. С++ щас очень стремительно развивается и становится более и более удобным именно для MCU, это конечно же пока только эксперименты (если говорить о %-ом соотношении кода, к коду на чистом Си), но, это направление — весьма перспективное.
Судя по тому, какой хаос происходил (да еще и происходит) в последние годы с самими некими общими ПРАВИЛАМИ ПРАВИЛЬНОГО ПИСАНИЯ на Си ПОД MCU и с его библиотеками для MCU ARM Cortex-M — это кажется, конечно, фантастикой… Но будущее видимо все же за C++. В любом случае, библиотеки CMSIS описания ресурсов периферии будутписаться генерироваться на Си, т.к. это не более, чем дефайны или константы описания hardware name_space (адресов_регистров/позиций_битов/масок и т.п.), которые должны будут подключаться уже к либам на C++.
Да, видимо произойдут потрясения в отрасли и для кого-то личные драмы и трагедии, как при переходе с асма на си в МК. Появятся два вида проггеров для МК: application уровень (дебилоиды на C++, с точки зрения тех, кто «пишет периферию» на православном Си), ну и эти самые пейсатели на Си (драйверов и т.п. периферийного). Но пусть уж лучше здесь (в МК/MCU) будет С++ ГЛАВНЫМ, но не скриптовые языки или интерпретаторы (жаба/C#). No Pasaran, Kamerades!!! Это я вам говорю, как MCU-Nazy!
Но, ВНЕЗАПНО, мне кажется, что все же будущее за C++ в MCU. С++ щас очень стремительно развивается и становится более и более удобным именно для MCU, это конечно же пока только эксперименты (если говорить о %-ом соотношении кода, к коду на чистом Си), но, это направление — весьма перспективное.
Судя по тому, какой хаос происходил (да еще и происходит) в последние годы с самими некими общими ПРАВИЛАМИ ПРАВИЛЬНОГО ПИСАНИЯ на Си ПОД MCU и с его библиотеками для MCU ARM Cortex-M — это кажется, конечно, фантастикой… Но будущее видимо все же за C++. В любом случае, библиотеки CMSIS описания ресурсов периферии будут
Да, видимо произойдут потрясения в отрасли и для кого-то личные драмы и трагедии, как при переходе с асма на си в МК. Появятся два вида проггеров для МК: application уровень (дебилоиды на C++, с точки зрения тех, кто «пишет периферию» на православном Си), ну и эти самые пейсатели на Си (драйверов и т.п. периферийного). Но пусть уж лучше здесь (в МК/MCU) будет С++ ГЛАВНЫМ, но не скриптовые языки или интерпретаторы (жаба/C#). No Pasaran, Kamerades!!! Это я вам говорю, как MCU-Nazy!
- well-man2000
- 06 января 2018, 23:46
- ↑
- ↓
Хотя, братия-ткачи/ремесленники (см. историю Англии начала-середины XIX века), «быдло» уже тута и они уже за нашей спиной.
Cortex-M7 уже почти смыкается с Cortex-A… А технологии-то растут каждый год. Хе-хе, а это што азначает — «быдло» c Unix и ПО под него для говнокодеров уже пачти тута. Enemy At The Gate!!!
А Arduino? Пацанчики-дебилы и прочие креаклы — ее уже в пром.автоматику суют, да по факту там она уже и есть везде, где мелочь пузатая и бабло жалеют, т.е. малый/средний индустриально-пром. бизнес.
Ну а про ESP8266/ESP32, т.е. умный_чайник у полнаго чайника — я уже вам рассказывать не буду, так чо? все бежим, и срочно учим lua? ЖDDD
Cortex-M7 уже почти смыкается с Cortex-A… А технологии-то растут каждый год. Хе-хе, а это што азначает — «быдло» c Unix и ПО под него для говнокодеров уже пачти тута. Enemy At The Gate!!!
А Arduino? Пацанчики-дебилы и прочие креаклы — ее уже в пром.автоматику суют, да по факту там она уже и есть везде, где мелочь пузатая и бабло жалеют, т.е. малый/средний индустриально-пром. бизнес.
Ну а про ESP8266/ESP32, т.е. умный_чайник у полнаго чайника — я уже вам рассказывать не буду, так чо? все бежим, и срочно учим lua? ЖDDD
- well-man2000
- 07 января 2018, 00:23
- ↑
- ↓
>быдло» c Unix и ПО под него для говнокодеров
Да, некоторые скажут, что чистый x-nix — это не TRUE Real Time и т.п. Я, честно говоря, все это слышал еще в конце 90-х и начале 2000-х, как мантры. Хотя, типо — это все происходило в пром.автоматике, т.е. у всех в мечтах QNX обязательно, но на худой конец — MS DOS с резидентн.программами и программой с общим циклом. Потом почему-то резко появилась венда в пром.автоматике, Trace mode и даже ethernet, который, ваще-то, был в 1000-10000 раз быстрее RS-485, но, тем не менее, не отвечал аксиомам требований Real Time (типо, всем условиям Real Time отвечают только два типа сетей: Token Ring и FDDI, ха-ха, которые уже не производятся х.з.сколько лет). Так вот постепенно, все это говно и проникло в пром.автоматику. Так же произойдет и здесь с Real Time — все будет работать из под x-nix.
Да, некоторые скажут, что чистый x-nix — это не TRUE Real Time и т.п. Я, честно говоря, все это слышал еще в конце 90-х и начале 2000-х, как мантры. Хотя, типо — это все происходило в пром.автоматике, т.е. у всех в мечтах QNX обязательно, но на худой конец — MS DOS с резидентн.программами и программой с общим циклом. Потом почему-то резко появилась венда в пром.автоматике, Trace mode и даже ethernet, который, ваще-то, был в 1000-10000 раз быстрее RS-485, но, тем не менее, не отвечал аксиомам требований Real Time (типо, всем условиям Real Time отвечают только два типа сетей: Token Ring и FDDI, ха-ха, которые уже не производятся х.з.сколько лет). Так вот постепенно, все это говно и проникло в пром.автоматику. Так же произойдет и здесь с Real Time — все будет работать из под x-nix.
- well-man2000
- 07 января 2018, 01:12
- ↑
- ↓
От вида прилождения вытекли глаза. Это точно 2018 год, а не конец 90-х, Delphi, адовые библиотеки кастомных контролов и засилие вырвиглазных скинов к MIDI-плеерам?
За это ещё и денег платить надо?! Точно? А не пользователям доплачивают за то, что они смотрят на ЭТО?!
За это ещё и денег платить надо?! Точно? А не пользователям доплачивают за то, что они смотрят на ЭТО?!
Вы видимо очень уникальный человек… по одному скриншоту можете оценить программу и вынести обличающий приговор. Думаю множество людей по всему миру, которые пользуются продукцией NI с вами не согласятся.
Миллионы мух не могут ошибаться.
Да, когда программа не уважает системные цвета и системные контролы где это возможно (понятно, что в системе нет контрола «оссцилограф») — это приговор.
То, что люди, работающие с железом, вынуждены страдать, потому что железячники не умеют программировать вообще и пользовательские интерфейсы в частности (что может наблюдать каждый, кто использует почти любой принтер на рынке например — драйвера принетра с настройками зачастую выглядят так же не-системно), и уже давно являются заложниками стокгольмского синдрома — для меня не новость. Ну да, если мне по работе вот такое, как тут на скриншоте, надо будет наблюдать каждый день (и альтернативы не будет, потому что это единственный интерфейс к уникальной железке, которая мне нужна) — то я тоже через годик буду считать, что всё в порядке, хороший интерфейс. А что делать? Это защитный механизм психики.
Да, когда программа не уважает системные цвета и системные контролы где это возможно (понятно, что в системе нет контрола «оссцилограф») — это приговор.
То, что люди, работающие с железом, вынуждены страдать, потому что железячники не умеют программировать вообще и пользовательские интерфейсы в частности (что может наблюдать каждый, кто использует почти любой принтер на рынке например — драйвера принетра с настройками зачастую выглядят так же не-системно), и уже давно являются заложниками стокгольмского синдрома — для меня не новость. Ну да, если мне по работе вот такое, как тут на скриншоте, надо будет наблюдать каждый день (и альтернативы не будет, потому что это единственный интерфейс к уникальной железке, которая мне нужна) — то я тоже через годик буду считать, что всё в порядке, хороший интерфейс. А что делать? Это защитный механизм психики.
(что может наблюдать каждый, кто использует почти любой принтер на рынке например — драйвера принетра с настройками зачастую выглядят так же не-системно)Там все хуже. У эпсонов сервисный софт выглядит еще отвратительней юзерского) И очень похож стилем на прогу в статье, кстати. По крайней мере, тот, с которым я работал.
Продукция NI — это прежде всего измерительное оборудование за многие килобаксы, к которому прилагается какой-то софт.
Не скажу, как этот софт в связке с родными системами, но полагаю, любят его именно за то, что наваять нужное на нем могут специалисты в совершенно других областях — скажем, ядерные физики. Но когда попадается самостоятельный софт, сделанный на лабвью — что-то типа SinaProg — это обычно ужас.
Не скажу, как этот софт в связке с родными системами, но полагаю, любят его именно за то, что наваять нужное на нем могут специалисты в совершенно других областях — скажем, ядерные физики. Но когда попадается самостоятельный софт, сделанный на лабвью — что-то типа SinaProg — это обычно ужас.
Скорее всего это автор постарался с украшательствами, а не сам LabWindows.
И, справедливости ради, я такое встречал на любых языках, далеко не только на дельфи.
И, справедливости ради, я такое встречал на любых языках, далеко не только на дельфи.
На Дельфи когда появились кастомные контролы и темы это было просто очень можно. Году этак в 1998-ом.
Сейчас даже программы с уникальным интерфейсом типа Адоб Лайтрума стараются выглядеть может и не как принято в системе, но аккуратно.
Сейчас даже программы с уникальным интерфейсом типа Адоб Лайтрума стараются выглядеть может и не как принято в системе, но аккуратно.
Да, в дельфи это особенно удобно. Но в те времена часто баловались даже не кастом-контролами, а просто раскрашиванием их в вырвиглазные цвета. А на всем этом серые кнопочки, потому что они стандартными средствами не красятся!
Но сейчас тоже сложно найти что-то с нативным интерфейсом. Всякие кьюты под него только косят с разной степенью успешности.
Но сейчас тоже сложно найти что-то с нативным интерфейсом. Всякие кьюты под него только косят с разной степенью успешности.
Комментарии (35)
RSS свернуть / развернуть