Category: it

дыбр, изорнет-поверх-усб

внезапно узнал, что для сабжа есть примерно ТРИ стандарта.
в принципе предсказуемо для любого порождения консорциума, где в главарях интел с микрософтом, но.

первое, самое на слуху, RNDIS - частично проприетарно
Ethernet Control Model (ECM), Ethernet Emulation Model (EEM) - вроде открытые.
Network Control Model (NCM) - еще один.

а еще есть кучка проприетарной хрени с проприетарными вендор специфик (проверил три разные вифи-усб свистка - там еще страшнее).

собственно вопрос. уже самому стало интересно влезть поглубже и разобраться, что проще/удобнее/стандартнее, ECM, EEM, NCM? какие плюсы-минусы? перспективы поддержки итп?

делать буду переходник на клиенте (усб-раб) с усб на стандартный тцп-ип стек, плюс возьму стандартную реализацию dns/dhcp и простого вебсервера для управления железкой (итого, усб-клиент будет симулировать сеть, в которой есть вебсервер с управляющими страницами).

идею симулировать страдж девицу при аккуратном рассмотрении отверг -- проблемы и с внезапным кешированием на стороне ос, и с поддержкой, например, фат12/16/24 и длинных имен. там оно уж очень криво.

Упоринос

Любопытно. а кто-нибудь уже пробовал сделать нечто подобное влоб, или аналог но немного иначе?

прошивка для какой-нибудь типовой stm32f4discovery. зашиваем в плату, подключаем по микро-усб к компу.

комп видит усб-сетевушку, за ней сеть с дхцп и вебсервером. дхцп помогает компу настроить ип и увидеть вебсервер. заходим на вебсервер и видим веб-интерфейс к управлению какой-нибудь железкой.

минусы решения: очень упорото
плюсы: потенциально, не требует ни драйверов, ни настройки, ни стороннего софта.

Малоногие ARMы

Странный вопрос.
Кто-нибудь игрался с АРМами в малоногих, но паяемых на коленке корпусах?
soic-8, tssop-14 или даже wlp-16?

wlp-16 реально на коленке лутом развести, или не стОит?
"stm32G0" в корпусах типа соик8 обещают, но еще не. или уже?
какие засады с errata, gcc, программаторами?

хочется вообще забыть про малоногие attiny, и что-то типа "измерять одно напряжение, рулить одним ключом, хвастаться о результате по uart/spi/i2c" делать на том же компиляторе, тех же библиотеках, с тем же программатором что и для многоногих stm32f4.

что посоветуете? ну и чтоб без привязки к виндоус. или с этим сейчас уже всё неплохо, и проприетарных программаторов/сред, работающих только под виндоус уже не надо?

ps: на данный момент активно работаю с stm32f407 и капельку с stm32f10x, (g++, lto, opencm, st-flash полностью устраивают. )

pps: капелька оффтопика.
1. c++ на stm32f4 или на иных эмбеддед кто-нибудь использует? плюсы, при грамотном применении, позволяют и объявлять переменные где удобнее, и безопаснее/проще/удобнее делать инициализацию глобальных сущностей типа "uart3" или "timer5". если не злоупотреблять затейливым наследованием и потоками, то кодогенерация практически не отличается от классического С, но добавляется много доп.проверок совместимости типов, булевский тип, итп. вроде сахар, но время и силы экономит.
2. "LTO" (оптимизация во время линковки) кто-нибудь использует? если аккуратно соблюдать Стандарт языка, то побочек от нее нет, а вот код становится и компактнее и быстрее. компактнее - иногда вчетверо при слишком дряном исходнике.
3. на свежих gcc (новее 7.х) сочетание stm32f4 + g++ + LTO -- падает на этапе линковки с внутренними ошибками этого самого линкера. грустно. Кто с этим сталкивался? на работе интернет ограничен, попробую дома воспроизвести баги.

Телеметрия в броузере

Коллеги, вопрос в формате "как это правильно делается?"

Есть экспериментальная штуковина (на батарейке) с богатым внутренним миром, и в поле действия вайфай-роутера. Её внутренние состояния и всякие параметры хочется видеть в окне броузера на контупере в поле действия того же роутера. Я знаю про модули Х-to-WiFi -- вопрос не о модулях. Вопрос такой: как правильно это делается, чтобы не возиться на стороне контупера с веб-программированием, виртуальными ком-портами и прочим расово-чуждым айти? Проект предельно железный, внутри штуковины только FPGA (без контроллеров), телеметрия нужна лишь для экспериментов. Скорость и дальность неважны. Например, FPGA шлёт данные в порт модуля (I2C или SPI), модуль шлёт пакеты с данными по некому айпи, а дальше как можно это в броузере увидеть (без украшательств), и лог посмотреть и сохранить? Или не в броузере?

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

ESP32 wired ethernet promiscuous mode

Господа и дамы, получится ли встроенный esp32-ethernet порт (не WiFi!!!) запустить в "promiscuous mode", чтобы сделать на этом чуде что-то похожее на wireshark?

Если кто-то считает, что да, может он тогда кинуть в меня примером кода для приема пакета в этом режиме? Мне нужно получить все пакеты, независимо от целевого IP.

Ожидаемая средняя скорость приема данных - около 100кбайт/с.

В интернетах полно всякого, рассчитанного хотя бы на IP, но тут как раз надо уровнем ниже.

Как правильно эмулировать EEPROM во флеш STM32?

Обычно занимают лишь одну страницу флеша, что кажется расточительным, особенно когда прошивка занимает 8кБ, а флеша 128кБ! Инициализирую так:
typedef struct{
	user_conf all_stored;
	char struct_end[0] __attribute__ ((aligned(FLASH_BLOCK_SIZE))); // this pointer provides size of structure multiple of page size
} flash_storage;

#define USERCONF_INITIALIZER  { \
	.userconf_sz = sizeof(user_conf)	\
    ,.id = "identifier" \
	,.dist_min = LIDAR_MIN_DIST			\
	,.dist_max = LIDAR_MAX_DIST			\
	}

static const flash_storage Flash_Storage __attribute__ ((aligned(FLASH_BLOCK_SIZE))) = {
	.all_stored = USERCONF_INITIALIZER
};

static const user_conf *Flash_Data = &Flash_Storage.all_stored;

И gcc помещает этот блок перед другими константами серии text. А мне нужно, чтобы он был последним и я мог использовать всю свободную память.

Ткните, пожалуйста, в примеры кода, где это реализуется правильно. Может, надо в линкере какую-то секцию указать и эту переменную с нужным смещением из линкера размещать?

P.S. Если кто знает ответ, можно себе увеличить карму на SO.

Schematics: The Heroin Of Electronics Design

Доклад "Schematics: The Heroin Of Electronics Design" от Dave Vandenbout на KiCon 2019 заслуживает внимания. Вероятно не все видили этот пост от ramlamyammambam. Использовать Питон для создания принципиальной схемы с помощью утилиты skidl это свежо.



MQTT/UDP Revisited

С наступающим, коллеги.

Я вернулся к теме MQTT/UDP.

Первый пост со срачем тут: https://ru-radio-electr.livejournal.com/1468452.html
Пост на Хабр чуть подробнее тут: https://habr.com/post/429714/

С прошлого раза есть вот какой прогресс:

Главное - я написал (правда, пока send only) реализацию для ПЛК. Тестировалось на ОВЕН ПЛК110.60 М2. Точнее, тестируется непрерывно. Когда я понял, что язык ST это почти Паскаль, снизошло просветление и понимание, что в языке есть указатели. С ними удалось прорваться. :)

Второе - теперь есть реализация на Lua. Удалось, наконец, установить на одну из машин Lua с работающим UDP. Остальное банально. :) Теперь бы надо эту Lua версию перегнать на NodeMCU, кажется, на нём сетевой стек какой-то сумчатый, придётся наверняка что-то переделать. Но пока до этого руки не дошли.

Третье - версию под Питон я портанул на Питон 3, который вовсе не то же самое, что Питон 2. :)

Ну и, наконец, я привёл в порядок программу Traffic Viewer, с её помощью можно наблюдать, что бегает в сети в формате MQTT/UDP. А поскольку она Явская, она работает и под Линуксом, и под Мак ОС. Как-то так это выглядит:

2018-12-28_00-37-06

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

Репозиторий на https://github.com/dzavalishin/mqtt_udp

Напомню, что это самый простой в мире протокол для обмена регулярными данными (опрос датчиков) с реализациями на Java, Python 2/3, Lua, C, CodeSys ST.

Если кому окажется полезным, буду рад.

stm32f4, выдача пачки импульсов

что-то я туплю.

есть проектик, пока что макет на stm32f4discovery. потом будет тот же камень ,но с более вменяемым обвязом. точнее, пачка похожих проектиков.
и вот понадобилось мне странное - выдать заданное количество импульсов заданной длительности с заданными интервалами.
точнее, импульсы можно тупо по 1мкс фиксированно, их число влезает в 15 бит а число заведомо влезает в 30 бит.

на данный момент плотно подсел на opencm3, что в комплекте с "-flto всегда и везде, и в либах и в проекте" даёт хороший запас и по производительности и по памяти.

а сегодня-и-впятницу внезапно застрял. протратил уже 17ч рабочего времени на вроде бы ерунду. явно где-то совсем детская ошибка (типа обращения к незатактованной гпио ножке).

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

нужно вроде бы несложное -- выдать пачку "тактирующих" импульсов, тупо одинаковых, на 1-4 ноги. импульс, например, 1мкс, пауза - например от 1 до 8к мкс, число импульсов в пачке задается менее чем 30-битным, а скорее даже менее чем 15 битным числом.

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

Кто-нибудь реализовывал AVR444?

Дошли в кои-то веки руки поковырять управление бесколлекторником.

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

Что я понял из кода к аппноуту:

Изначально на этапе "слепой" раскрутки все таймерные прерывания отключены, таймер 0 гонит ШИМ аппаратно на ногу OC0B,
задержки коммутации - на опросе флага переполнения таймера 1.
После раскрутки разрешается прерывание OCIE1A, что и должно обеспечить переход к рабочему циклу (в котором прерывания по очереди разрешают друг друга):
 TCNT1 = 0;
 TIMSK1 = (1 << OCIE1A);


Но вот в чём странность - в OCR1A при этом ничего не пишется. Единственное место, где происходит запись в этот регистр - это прерывание переполнения таймера 0 (а оно на данный момент ещё запрещено).

Если ориентироваться на дефолтное значение после сброса (то есть ноль), тогда получается, что прерывание сработает только при следующем переполнении таймера 1 (и симуляция это подтвердила), но это ведь аж 65 мс (в то время как межкоммутационные интервалы при слепой раскрутке - от начального 20 мс до финального 5,5 мс).

Вот и зудит вопрос: то ли в аппноуте косяк, то ли пауза после раскрутки - это так и должно быть? Под нагрузкой затормозиться же успеть может. А если я в своём коде "по мотивам" уберу эту паузу, вставлю инициализацию OCR1A на основании последнего интервала раскрутки - никаких внезапных граблей не прилетит?

И ведь не гуглится нихрена. Или я не знаю, какие ключевые слова использовать, чтобы нужное найти вместо мусорной кучи простых упоминаний. Судя по встреченным упоминаниям AVR444 - люди как-то его реализуют (причём, довольно массово) и ничего не упоминают про такой нюанс.