В электронике есть множество проводных полудуплексных асинхронных последовательных интерфейсов типа общая шина. Это 1-Wire, RS485, 10BASE2(thin Ethernet), LIN, K-Line , CAN, I2C, MIL-STD-1553, ARINC 429.
Во всех этих shared-bus интерфейсах так или иначе возникает задача сканирования шины.
Всем кто работал с i2c известна процедура сканирования шины. Там можно просто методом перебора просканировать шину. Так как длина адреса всего 7 бит, то можно просканировать шину просто за пару секунд.
Последнее время я сильно увлекся вопросом надежности софта для микроконтроллеров, 0xd34df00d посоветовал мне сильнодействующие препараты, но к сожалению руки пока не дошли до изучения Haskell и Ivory для микроконтроллеров, да и вообще до совершенно новых подходов к разработке ПО отличных от ООП. Я лишь начал очень медленно вкуривать функциональное программирование и формальные методы.
Все мои потуги в этих направлениях это, как было сказано в комментарии ради любви к технологиям, но есть подозрение, что сейчас никто не даст мне применять такие подходы (хотя, как говориться, поживем увидим). Уж больно специфические навыки должны быть у программиста, который все это дело будет поддерживать. Полагаю, что написав однажды программу на таком языке, моя контора будет долго искать человека, который сможет принять такой код, поэтому на практике для студентов и для работы я все еще по старинке использую С++.
Продолжу развивать тему о встроенном софте для небольших микроконтроллеров в устройствах для safety critical систем.
На этот раз попробую предложить способ работы с конкретными ножками микроконтроллера, используя обертку над регистрами, которую я описал в прошлой статье Безопасный доступ к полям регистров на С++ без ущерба эффективности (на примере CortexM)
Чтобы было общее представление того о чем я хочу рассказать, приведу небольшой кусок кода:
using Led1Pin = Pin<Port<GPIOA>, 5U, PinWriteableConfigurable> ;
using Led2Pin = Pin<Port<GPIOC>, 5U, PinWriteableConfigurable> ;
using Led3Pin = Pin<Port<GPIOC>, 8U, PinWriteable> ;
using Led4Pin = Pin<Port<GPIOC>, 9U, PinWriteable> ;
using ButtonPin = Pin<Port<GPIOC>, 10U, PinReadable> ;
//Этот вызов развернется в 2 строчки
// GPIOA::BSRR::Set(32) ; // reinterpret_cast<volataile uint32_t *>(0x40020018) = 32U
// GPIOС::BSRR::Set(800) ; // reinterpret_cast<volataile uint32_t *>(0x40020818) = 800U
PinsPack<Led1Pin, Led2Pin, Led3Pin, Led4Pin>::Set() ;
//Ошибка компиляции, вывод к которому подключена кнопка настроен только на вход
ButtonPin::Set()
auto res = ButtonPin::Get() ; 
Hello dear readers. In this article I will try to demonstrate how to run a Java Virtual Machine and Java applications on microcontrollers. This idea may sound quite outlandish by itself: why use Java on microcontrollers where each byte of RAM and each CPU cycle are precious commodity? There's nothing like native C for microcontrollers — even C++ is rarely used! Yes, I've heard that discussion (and took part in it) for many years. Well, I will try to explain «why», as well as «how», in this article. So, anyone who wants to understand how MCU implementation of JVM works; see an unusual approach to multi-platform project development; take part in Open Source project; or just have fun — welcome onboard, uJVM is ready to take off! People who are ready to criticize can stay near the runway and watch us climb (or crash) from a safe distance
Добрый день, уважаемыее. В этом цикле статей я попытаюсь рассказать Вам о Java Virtual Machine и запуске Java программ на микроконтроллерах. Тема достаточно спорная: Зачем Java на микроконтроллерах, где и так мало ресурсов? Лучше нативного кода написаного на чистом С, ничего нет, даже на плюсах мало кто пишет! И т.д. Сразу скажу, сам задавал себе эти вопросы и не один раз. Мой ответ такой: Кто хочет попробовать, на что способно железо; понять, как работает JVM; увидеть интересный подход к построению мультиплатформенного проекта; внести свой вклад в Open Source; или просто побаловаться — все на борт, корабль по имени uJVM отправляется в плавание! Те кто уже настроился критиковать, смотрите как «Титаник» отправился в путь, надеюсь на Вашу лояльность!
Ну а теперь к самому сложному и интересному. Если лень читать, то ниже (ближе к концу статьи) будет ссылка на видео, с результатом и объяснением всего, в том числе и того, что описано в первой части. Кому интересно, то Читать полностью »
Осень наступила, отцвела капуста, Уже почти середина зимы, а я только закончил с этим возиться. Но всё равно наступило время когда хочется поиграть во, что-нибудь старенькое, под шум метели за окном, например в Соника или червяка Джима. Внизу статьи видос с предварительными результатами.
Читать полностью »
В Linux есть стандартный интерфейс для работы с GPIO через sysfs. Документацию на него можно посмотреть тут.
Если кратко, то в папке "/sys/class/gpio" есть файлы «export» и «unexport». С помощью записи числа X в файл export можно открыть интерфейс в user space для управления GPIOX
# открыть интерфейс в user space для управления GPIO12
$ echo 12 > /sys/class/gpio/exportПосле открытия интерфейса появится папка /sys/class/gpio/gpioX/ в которой будут такие файлы как «value» или «direction», и путём записи «in» или «out» в файл «direction» и записи 1 или 0 в файл «value» можно управлять выводом GPIO напрямую через командную строку.
# настроить GPIO на вывод
$ echo "out" > /sys/class/gpio/gpio12/direction
# установить 1 на выводе GPIO
$ echo 1 > /sys/class/gpio/gpio12/valueЧтобы команда «echo X > /sys/class/gpio/export» приводила к созданию папки «gpioX», в ядре должен быть зарегистрирован драйвер контроллера GPIO, открывающий интерфейс к линиям GPIO.
Так получилось, что я работаю над портированием coreboot для кастомной платы на базе процессора Intel Haswell i7 [Для тех, кто не знает, coreboot это open source проект по созданию BIOS с открытым исходным кодом (https://www.coreboot.org/)]. В мой процессор встроен южный мост LynxpointLP в котором есть 94 линии GPIO. И я захотел открыть их в sysfs…
Читать полностью »
Данная статья посвящена разработке GPIO (General-Purpose Input/Output) модуля ядра Linux. Как и в предыдущей статье мы реализуем базовую структуру GPIO драйвера с поддержкой прерываний (IRQ: Interrupt Request).
Подбирая девелоперскую плату для опытов, выбор пал на достаточно навороченную модель от китайского производителя T-Chip. Реализуют продукцию они под маркой Firefly. Специализируются на платах с системами на чипе от RockChip. RK3288 — самое производительное 32-битное решение от этой китайской компании. SoC от RockChip и Allwinner выгодно отличаются от чипов Broadcom в RaspberryPi не только лучшими характеристиками, но и технологией производства — 28nm против 40nm. Но конечно и стоят в данном случае китайцы дороже. Ещё более крутую 64-битную систему RK3399 не выбрал, в том числе потому, что есть основания полагать, что она уже существенно горячее. В то время как RK3288 под нагрузкой не сильно греется, даже без использования каких-либо радиаторов.
Страница продукта. Основные аппаратные параметры девайса: 4 ядра ARM Cortex-A17 1,8 ГГц (некоторые источники настаивают, что тут Cortex-A12 или A15, но это не особо важно), 2 ГБ DDR3 dual-channel, накопитель 16 ГБ eMMC, гигабитный Ethernet.
Покупал на Ebay, это оказалось чуть ли не единственным местом, где эти платы можно заказать в Россию. Интернет магазин самого китайского Firefly в Россию не высылает. Не высылает в Россию и Indiegogo. Что забавно, в списке стран для отправки, у этих странных людей якобы есть даже ныне не существующие государства :). Продавец с Ebay прислал плату в хорошей комплектации — плата, блок питания (нужен 12V 1,5A, прислали как и положено с запасом — 2A), платка с антенной, акриловые панели корпуса с крепежом. Адаптер правда под американскую розетку, но ведь все должны иметь походный переходник :).
Читать полностью »
В статье предложена организация взаимодействия функциональных блоков в объёме кристалла СБИС, а именно: процессорных ядер, контроллеров DMA и мостов системных шин с периферийными блоками, такими как: контроллеры GPIO, SPI, I2C, UART, таймеры и широтно-импульсные модуляторы – ШИМ. Рассмотрен набор сигналов и протокол обмена стыка простого исполнителя – локального системного интерфейса, реализующего взаимодействие перечисленных блоков кристалла. Приведены примеры синтезируемых моделей контроллера GPIO и регистрового файла, поддерживающие описанный интерфейс.
Читать полностью »
