I build an example net/sockets/echo_server for NRF52811. When trying to build from "prj.conf overlay-802154.conf", I get errors:
/Users/vvzvlad/Documents/Projects/smarthome_ng/zephyrproject/zephyrproject/modules/hal/nordic/drivers/nrf_radio_802154/nrf_802154_config.h:158:37: error: 'NRF_EGU3' undeclared (first use in this function)
#define NRF_802154_SWI_EGU_INSTANCE NRF_EGU3
^
/Users/vvzvlad/Documents/Projects/smarthome_ng/zephyrproject/zephyrproject/modules/hal/nordic/drivers/nrf_radio_802154/nrf_802154_core.c:721:29: note: in expansion of macro 'NRF_802154_SWI_EGU_INSTANCE'
if (nrf_egu_event_check(NRF_802154_SWI_EGU_INSTANCE, EGU_EVENT))
Apparently, NRF_EGU3 is some kind of module or driver, but I don't see it on the list when I run menuconfig.
Hi @vvzvlad,
NRF_EGU3 is a label for a peripheral, namely Event Generator Unit, instance 3. As nRF52811 has only 2 EGU instances, it is not available in this chip.
The core reason we're seeing this error is that the nRF 802.15.4 radio driver we use in Zephyr is quite dated now, and has no yet support for nRF52811. So in order to build 802.15.4 samples for nRF52811, we'd need to update the driver first.
Another thing is, that even with the most recent driver, it will be tricky to fit this sample into the nRF52811. This chip has only 24k of RAM, while the sample built with 802.15.4 overlay requires over 50k for now. So the sample would require some serious trimming in order to fit in.
... So the sample would require some serious trimming in order to fit in.
Any chance this will be fixed at all ie do you know, by any chance, if there's a reasonable chance to trim down the size?
Hi @Boilerplate4u,
The radio driver update is already on its way (check #21835, this version has support for nRF52811).
As for the sample size though, I think it's something you need to venture on your own, I don't think there are any plans to trim the echo samples size any time soon. ninja ram_report utility should be a great help here. For instance, building for nrf52840_pc10056 shows, that the 802.15.4 subsystem doesn't have much RAM requirements on its own (radio driver is 289 bytes, and 802.15.4 L2 is 247 bytes).
Apart from the obvious subsystems to disable (shell, logging), the largest RAM consumer seems to be the networking layer - I'm pretty sure a lot of savings can (or actually has to be, as it over 30k lone) be achieved there - minimize the number of net packets/buffers/net_contexts or disable certain features (like nbr or net_mgmt). Basically, I believe a lot savings can be done here due to the networking stack configurability.
(radio driver is 289 bytes, and 802.15.4 L2 is 247 bytes)
Are you sure about these numbers? First, the L2 being smaller than the driver seems rather strange, but second: both are less than 300 bytes??
@tbursztyka Note, we speak about RAM here. The numbers I get:
hal 289 0.54%
nordic 289 0.54%
drivers 289 0.54%
nrf_radio_802154 289 0.54%
l2 247 0.46%
ieee802154 247 0.46%
drivers 1945 3.60%
ieee802154 1576 2.92%
This one is quite large, due to the fact that this module maintains it's own thread for operation.
For anyone interested, I attach the entire RAM report:
ram_report.txt
Note, we speak about RAM here.
Sure, still less than 300 bytes for L2 is lower than I thought. Nice.
For echo-* programs, we currently try to enable necessary bits and pieces that could be useful for app developers. We have tried to make the echo-* apps to work most of the available hw but as there are lot of small boards with limited RAM, no specific effort has been done to support every board out there.
@rlubos
For anyone interested, I attach the entire RAM report:
ram_report.txt
Rlubos - nice summary, thank you very much!