Come hangout with me and chat @zephyr if you're in the Austin, TX area: https://www.zephyrproject.org/what-to-expect-at-the-zephyr-project-meetup-june-25-2026-in-austin-texas/

#zephyr #embedded

And now I have a choice to make... do I rewrite the stm32c5x.c handling of flash erase for #Zephyr to properly account for the EDATA flash (starting at 0x0840 0000), or just "lose" 64K of flash on the chip?

So weird that ST submitted the code originally (2025-12-16) but it doesn't fully support this part of the chip? That's a lot of storage on an embedded chip to leave on the table.

I'm just trying to figure out if there's more that needs to be done than just passing LL_FLASH_ERASE_EDATA_AREA instead in erase_page()?

I think the root of the problem is that I'm not sure how Zephyr deals with multiple different flashes on the same SOC? EDATA is different with either 1.5K or 2K page sizes (versus 8K), depending on some register bits (EDATASEL), so while it's contiguous with the rest of the flash, it isn't the same.

This may be why it isn't supported... because Zephyr doesn't seem to have a really clear way to implement this.

Gonna stew on this. Right now, I can burn other flash for configuration storage, but I resent having that much space wasted for no reason.

Генерация тестовой документации с ИИ

Всем привет! Продолжаю цикл статей про применение ИИ в тестировании. В первой я рассказывала о том, зачем мы пошли в пилот по применению ИИ в тестировании. Во второй — как собирать контекст. В третьей — как тестировать требования, когда контекст уже готов. Сегодня про следующий этап: генерацию тестовой документации : тест-кейсы, чек-листы, матрица покрытия и т.д. Небольшой спойлер: в конце статьи вас ждет ссылка на репозиторий с инструкциями и промтами.

https://habr.com/ru/companies/rgs_it/articles/1047704/

#ии #тестирование #ai #тесткейсы #чеклист #тестовая_документация #zephyr

HAPS: Гелий, планер и стратосферная базовая станция 6G

Надвигающийся стандарт сотовой связи 6G принесет нам много новинок, которые я уже разбирал подробно. Лично для меня самой внезапной оказалась концепция HAPS. Напомню, что HAPS расшифровывается как High Altitude Platform Station — высотные платформенные станции. Своей сутью это летающие базовые станции, которые могут надолго зависать над определенным районом и обеспечивать его связью. Плюсов от такого подхода прилично. Судите сами. Мы можем оперативно развернуть связь в любой точке земного шара. В горах, на море или там, где произошло стихийное бедствие и наземная инфраструктура связи погребена под руинами. Если сравнивать с космической связью (тем же Старлинком) то HAPS находятся куда ниже низкоорбитальных спутников. Формально в документах Международного союза электросвязи HAPS — это станция на объекте на высоте 20–50 км. На практике большинство сценариев смотрит в сторону стратосферных высот около 20 км: выше погоды и коммерческой авиации, но на порядок ниже спутниковых орбит. Напомню, что типовая LEO-орбита порядка 500 км. А это значит, что мы можем себе позволить меньшие задержки и меньшую мощность передатчика в сотовом телефоне. Получается, одни плюсы. Только вот есть несколько вопросов. А как к HAPS подвести канал связи? А как туда подвести питание? А как создатели 6G вообще себе представляют атмосферный объект, который днями висит на месте и не падает? Что ж, давайте разбираться!

https://habr.com/ru/companies/beget/articles/1047508/

#HAPS #HTA #LTA #беспилотник #дрон #6G #3GPP #Zephyr #StarLink #Loon

An abandoned 1960s Ford Zephyr, left forgotten at the front of an abandoned house. Ireland 🇮🇪

https://lostpod.space/w/mvDcRmfDHQpRXzhof31RLG

Synaptics Astra SRW1500 Cortex-M52 Edge AI MCU features Ethos-U55 NPU, Wi-Fi 6/7, Bluetooth 6.0, 802.15.4 connectivity

https://fed.brid.gy/r/https://www.cnx-software.com/2026/06/10/synaptics-astra-srw1500-cortex-m52-edge-ai-mcu-features-ethos-u55-npu-wi-fi-6-7-bluetooth-6-0-802-15-4-connectivity/