MX_Master

WASM подходит только для трудоёмких вычислений, и не более того. Ибо у него нет прямой связи c графикой, деревом элементов и т.п. Все связи только через JS. Это узкое горлышко сделано для безопасности и оно не позволяет сильно разгуляться. Что касается убыстрения веб графики, придётся играть по правилам веб графики. Рисование мульёна треугольников из массива лёгкой задачей для веб графики не является. Особенно, если результат хочется приемлемо покрутить в браузере телефона.

Понимаю, что просьба была о примерах веб-морд. Но как вебмастер-любитель, хочется посоветовать юзать связку websocketd и любых STDIN/OUT программок. Стессна, если бэк крутится под настольной ОС. Если же бэк крутится на МК.. помню как-то давно делал правки в LWIP для поддержки веб-сокетов. Связка работала быстро. Файлы веб-морды были тупо захардкоржены в С код. Делать так, канеш, нежелательно, уж лучше рядом на SPI флэшке их положить. Если нужно что-то активно считать именно веб-мордой, то, какое-никакое решение - WASM. Яваскрипту лучше волю не давать. Если бэк крутится, скажем под Linux, лучше все тяжёлые расчёты вынести в отдельную консольную программку (скажем на С). Она будет общаться с веб мордой посредством websocketd. Чтобы рисовать графики и прочее красивое, готовые (JS) библиотеки повсеместно есть в тырнетах. Но, в любом случае, перед началом рисования (или переделки) любой веб-морды, желательно изучить HTML/CSS/JS хотя б на троечку (из пяти).

В мануале на A83T есть описание нужных регистров. Для H3/H5 адреса те же. На linux-sunxi есть инфа о том, чем собирать, как запускать + примеры. На github тоже есть примеры. Пример использования по назначению - crust firmware, не по назначению - мой генератор/счётчик сигналов.

Доки на это дело временами есть в тырнетах. Поэтому нет ничего странного в том, что можно юзать отдельное ядро управления спящим режимом для чего-то другого.

allwincnc.github.io Allwinner H3/H5/H6 + Armbian + rt-preempt linux kernel + LinuxCNC + ногодрыг на свободном RISC ядре Чуть позже хочу замутить такое же на RK3399. Там свободных (cortex A/M) ядер заметно больше. Возможны, даже варианты.

Ethernet MAC имеет доступ не ко всем доменам ОЗУ. Могу ошибаться, но, возможно, RX/TX буферы находятся в недоступном домене. ЗЫ рабочий пример (создан на скорую руку) - https://gitlab.com/MX_Master/STM32H7_Nucleo-H743ZI_Ethernet_LwIP

Вот и я не увидел, а в структуру таки массив не внесли Я лентяй ещё тот. Собсна, как и многие другие. Однако, все согласятся с тем, что изучать доки гораздо приятнее, когда рядом есть хотя б какой-то пример. Пример может быть хорошим или плохим. Но благодаря ему понимание логики работы устройств приходит быстрее Второй плюс кода из под кубика - готовый набор макросов для правки регистров. Ими я пользуюсь с удовольствием. А вот тяжеловесных кубовых функций я стараюсь избегать. Единственное, место, где они остаются - в начальной инициализации. Ибо скорость старта устройства не так важна, как скорость в работе. Но иногда, даже в простых кубовых функциях бывают ошибки. На одну из них я и попался Причём, ошибка неявная, пока глыбже в код не нырнёшь, непонятно /** * @brief ETH Init Structure definition */ typedef struct { uint32_t AutoNegotiation; uint32_t Speed; uint32_t DuplexMode; uint16_t PhyAddress; uint8_t *MACAddr; uint32_t RxMode; uint32_t ChecksumMode; uint32_t MediaInterface; } ETH_InitTypeDef;

Разобрался. Оказыцца, в новый кубик за 2 года завезли новых багов 2 года назад кубик делал так /* ETH init function */ static void MX_ETH_Init(void) { uint8_t MACAddr[6] ; heth.Instance = ETH; heth.Init.AutoNegotiation = ETH_AUTONEGOTIATION_ENABLE; heth.Init.PhyAddress = PHY_USER_NAME_PHY_ADDRESS; MACAddr[0] = 0x00; MACAddr[1] = 0x80; MACAddr[2] = 0xE1; MACAddr[3] = 0x00; MACAddr[4] = 0x00; MACAddr[5] = 0x00; heth.Init.MACAddr = &MACAddr[0]; heth.Init.RxMode = ETH_RXINTERRUPT_MODE; heth.Init.ChecksumMode = ETH_CHECKSUM_BY_HARDWARE; heth.Init.MediaInterface = ETH_MEDIA_INTERFACE_RMII; /* USER CODE BEGIN MACADDRESS */ /* USER CODE END MACADDRESS */ if (HAL_ETH_Init(&heth) != HAL_OK) { _Error_Handler(__FILE__, __LINE__); } } А сейчас вот так static void MX_ETH_Init(void) { /* USER CODE BEGIN ETH_Init 0 */ /* USER CODE END ETH_Init 0 */ /* USER CODE BEGIN ETH_Init 1 */ /* USER CODE END ETH_Init 1 */ heth.Instance = ETH; heth.Init.AutoNegotiation = ETH_AUTONEGOTIATION_ENABLE; heth.Init.PhyAddress = DP83848_PHY_ADDRESS; heth.Init.MACAddr[0] = 0x00; heth.Init.MACAddr[1] = 0x80; heth.Init.MACAddr[2] = 0xE1; heth.Init.MACAddr[3] = 0x00; heth.Init.MACAddr[4] = 0x00; heth.Init.MACAddr[5] = 0x00; heth.Init.RxMode = ETH_RXINTERRUPT_MODE; heth.Init.ChecksumMode = ETH_CHECKSUM_BY_HARDWARE; heth.Init.MediaInterface = ETH_MEDIA_INTERFACE_RMII; /* USER CODE BEGIN MACADDRESS */ /* USER CODE END MACADDRESS */ if (HAL_ETH_Init(&heth) != HAL_OK) { Error_Handler(); } /* USER CODE BEGIN ETH_Init 2 */ /* USER CODE END ETH_Init 2 */ } Ошибку видно?

Года 2 назад экспериментировал с голыми (raw) Ethernet фреймами собственного типа (ethertype=0x80AB) на связке STM32F407VET6 + LAN8720. Всё работало как часы. Портировал недавно тот же код на связку STM32F207VCT6 + DP83848. На этой связке те же самые фреймы теперь отбрасываются в мусор. Очевидно, что их отбрасывает какой-то фильтр. Не могу понять только какой именно. Сквозь фильтр прекрасно просачиваются ARP, UDP, TCP пакеты с любым MAC (destination) адресом. Broadcast тоже пролетают на ура. А вот фреймы неизвестных типов (ethertype=0x80AB), даже с точным МАС адресом STM'ки, отбрасываются. Стессна, если в MAC регистрах включить PromiscuousMode или ReceiveAll , все фреймы приходят на ура. Можно, канеш, фреймы фильтровать и в коде, но интересно разобраться какой именно фильтр мешает. Если кто-то сталкивался с подобным поведением, дайте, пожалуйста, в нужную сторону пинка Попробую завтра что-нибудь ещё. Но было бы интересно выслушать пару советов.

Вариант с подменой адреса reset вектора гениален Спасибо, друзья. Бум пробовать... ЗЫ помониторить правку флэша из оригинала тоже не помешает

В контексте задачи можно оригинал разместить и с 0x08000000, а загрузчик в другом месте. Главное, чтобы первым стартовал именно загрузчик (:

Никогда ещё не дизассемблировал бинарники от STM32, с чего можно начать?

Название темы, канеш, непонятное. Не знаю как точно назвать. ДАНО: есть готовый бинарник прошивки под STM32F207VCT6, исходников нет. По таблице векторов прерываний видно, что базовый адрес флэхи = 0x08000000. ЗАДАЧА: хочу разместить в начале флэхи (0x08000000) свой загрузчик, а следом за ним разместить 2 прошивки - оригинал и свою версию. В зависимости от настроек, загрузчик должен передавать управление одной из них. Свой проект можно собрать, указав линкеру смещенный адрес флэхи. А как быть с уже собранным оригиналом? Есть ли какой-то способ найти в бинарнике все адреса с флэхи и махнуть их на другие?

Всё придумано до меня, для настольных ПК. Я лишь пытаюсь запустить сие на мобильных процессорах, вынося всякие ногодрыги в аппаратную часть МК. Получается, канеш, с горем пополам. Но, на мой взгляд, это лучше чем телебонькать пины обычным процессором. Если делать полностью своё ЧПУ (что займёт не один год), можно смело юзать и MP1. Его ресурсов, при грамотном подходе, более чем достаточно.

Там кроме собственно LinuxCNC ещё и обычная ОС, типа Ubuntu/Debian, давит на проц. Большинство интерфейсов у LinuxCNC - OpenGL'евые. А этого добра в MP1 нет (OpenGLES не в счёт), так что графика тоже падает на проц. Ну и частенько используются Python скрипты, чему процессор никак не рад. Всё переписывать и оптимизировать - дело неблагодарное. В данный момент использую алвинеры H3 + внешнюю F429. Присматриваюсь постепенно к RK3399. Там внутре 2 многоядрёных проца, один из которых можно в теории заточить под bare metal.