Одно из традиционных развлечений с FPGA заключается в генерации видео-сигнала для VGA-мониторов. В этой заметке будет рассмотрено решение этой задачи на примере платы iCEstick и открытого стека разработки под нее в лице проекта IceStorm. Если у вас нет iCEstick, но есть другая плата на базе FPGA серии ICE40 от Lattice, например, TinyFPGA B2 или Nandland Go Board, они тоже подойдут и потребуют внесения минимальных изменений в коде проекта. Также сгодятся платы на базе других FPGA, однако они потребуют внесения более существенных изменений в код, особенно в части, касающейся PLL. Кроме того, потребуется установка соответствующего проприетарного ПО, например, Quartus для FPGA от Intel / Altera или Vivado для устройств производства Xilinx.
Одна из проблем с микроконтроллерами STM32 заключается в том, что большинство из них не имеют встроенного EEPROM. Исключением являются только микроконтроллеры серий STM32L0 и STM32L1 с ультра низким энергопотреблением. Это довольно странно после работы с AVR, где EEPROM есть у всех микроконтроллеров. Существует несколько решений, но в рамках этой заметки мы рассмотрим самое очевидное — использование внешнего EEPROM на примере чипа с I2C-интерфейсом 24LC64.
Благодаря наличию исключений, язык C++ позволяет разделить основную логику приложения и обработку ошибок, не мешая их в одну кучу. Что есть очень хорошо. Однако теперь по коду нельзя с уверенностью сказать, где может быть прервано его исполнение. Отсюда возникает опасность утечки ресурсов. Проблема эта решается при помощи деструкторов и идиомы RAII. Впрочем, придерживаться этой идиомы становится проблематично при использовании указателей. Особенно при использовании их не как членов класса, а просто как переменных в методах. На наше с вами счастье, в стандартной библиотеке языка есть умные указатели (smart pointers), придуманные именно для этого случая. Поскольку на C++ я пишу не регулярно, то иногда забываю некоторые нюансы использования умных указателей, в связи с чем решил вот набросать небольшую шпаргалку.
Уж не помню, каким именно образом, но однажды я наткнулся на замечательное видео Дмитрия Дементьева о том, как он делает печатные платы при помощи пленочного фоторезиста. Я взял на вооружение многие из описанных им методик, в частности, нанесение фоторезиста «мокрым» методом, использование ламинатора, а также канцелярских зажимов. Но больше всего в видео меня поразила лампа из ультрафиолетовых светодиодов с таймором. Такая лампа засвечивает фоторезист за 21 секунду, тогда как у меня при использовании настольной лампы с УФ-лампочкой на это уходит 15 минут, и это еще если фоторезист свежий. В общем, я захотел себе такое же устройство. Далее будет описан процесс его изготовления и полученные результаты.
Как вам может быть известно, современные браузеры помечают в адресной строке сайты, работающие по HTTP, как небезопасные. Есть также информация (мне, впрочем, неизвестно, насколько она достоверна) о том, что поисковые системы пессимизируют такие сайты в выдаче. Плюс к этому были выявлены случаи, когда операторы мобильной связи подмешивали рекламу в HTTP-трафик своих абонентов — естественно, на весь экран мобильного устройства и с поломанной версткой сайта. В общем, как ни крути, времена меняются, и мир переходит на HTTPS. Если у вас один домен, обычно не проблема купить сертификат для него прямо у вашего хостинг-провайдера. Но если сайтов много, или сайт один, но с большим числом поддоменов, цена на сертификаты или один wildcard сертификат выйдет просто неразумной. На помощь приходит сертификационный центр Let’s Encrypt, существующий за счет спонсоров и выдающий сертификаты бесплатно.
Ранее мы познакомились с несколькими отладочными платами на базе микроконтроллеров STM32 — это Blue Pill, платами серии Nucleo, и даже такой экзотикой, как Кракен. Все это здорово, но что, если нам захочется использовать микроконтроллер не в прототипе, а в полноценном готовом устройстве? Не вкорячивать же в него плату Nucleo! Поэтому сегодня мы разберемся, как работать с STM32 напрямую, то есть, прямо на макетной плате, на примере микроконтроллера STM32F103C8T6. Казалось бы, тема эта несложная, однако есть пара подводных граблей, про которые стоит знать.
Программисты, как правило, не очень любят писать тесты. Но куда сильнее они не любят писать документацию. Тесты хотя бы представляют собой программы, а документация — это что? Просто текст. Вот пусть кто-нибудь другой его и пишет, технические писатели например! Впрочем, если речь идет не о пользовательской документации, а об описании классов и методов, предназначенном для других программистов, тут откосить вряд ли удастся. К счастью, есть Doxygen, способный существенно помочь со столь неприятной для многих работой.
Помните, как когда-то мы писали простой TCP-сервер на C, а потом разбирали типичные ошибки? Описанный в этих статьях подход прекрасно работает, но только до тех пор, пока количество одновременно обслуживаемых соединений невелико — условно, пара сотен. Если же вам нужно обслуживать 10 или 50 тысяч соединений (так называемая проблема C10K), программу нужно писать совершенно иначе. Давайте разберемся, почему так, и как же нужно писать.
В прошлом посте, посвященном STM32, мы познакомились с платами Nucleo, программой STM32CubeMX, узнали, как программировать под STM32 в Linux, а также осилили базовые операции с GPIO. Сегодня же мы поговорим об использовании аппаратной реализации UART. В рамках данного поста мы будем использовать UART исключительно для обмена данными с компьютером. Однако с тем же успехом его можно применять и для взаимодействия с внешними модулями.
Ранее мы познакомились с IceStorm, открытым набором инструментов для разработки под FPGA серии Lattice iCE40, а также дешевой отладочной платой iCEstick на базе чипа ICE40HX1K. Кроме того, с использованием IceStorm, iCEstick и языка SystemVerilog нам удалось сделать электронные часы. Сегодня же при помощи тех же инструментов мы попробуем поработать со звуком. Однако на пути к этой благородной цели таится преграда, да не одна!