Hi, I’m looking at porting the firmware to the ESP (Not the Oak) and wondering if other people have done similar stuff?
Maybe @eely22 can point out some of the things he had to do in porting the firmware for Bluz?
As mentioned on Slack, the ESP8266 has more contraints. But I would think you could at least port a subset of functionality?
Porting the FW to bluz wasn’t too terrible (though we aren’t quite finished yet!). We originally started before the HAL existed and that presented some challenges, but we made it work. The biggest issue we ran into initially was lack of RAM, the stack probably needs at least 10-12K for the encryption alone, though I have never directly tried to measure this. This made us wait and move to the new 32K RAM version of the nrf51822.
The biggest issue for us too was laying down the plumbing for data and the different configuration options, the HAL is sort of specific to using sockets and Wifi stuff like setup and credentials. We bypassed some of this stuff and used the socket abstraction to make it BLE underneath, but I would imagine this is easier when moving to another Wifi chip.
It is certainly possible to pick up the HAL and start moving it to the ESP. As others have suggested, though, it may be easier to wait for the Oak and modify their software once it is open source. I believe they are shipping soon so it shouldn’t be too long of a wait.
3 Likes
I’m a beginner when it comes to firmware but:
http://paste.ubuntu.com/12560590/ is failing with this error now.
The firmware code that’s done until now is here:
Taking a wild stab here is that there’s some include funkyness going on since if you do
make PLATFORM=newhal or make PLATFORM=gcc < which should work according to docs…
It blows up in the same direction
The newhal build has been fixed in develop and a new CI test added to the suite to ensure it stays buildable.
make[1]: Leaving directory '/home/karlsone/projects/particle/firmware/services’
make -C ./wiring
make[1]: Entering directory '/home/karlsone/projects/particle/firmware/wiring’
Building file: src/spark_wiring_wifi.cpp
Invoking: ARM GCC CPP Compiler
mkdir -p …/build/target/wiring/platform-11/src/
xtensa-lx106-elf-gcc -DSTM32_DEVICE -Dlx106 -DPLATFORM_THREADING=0 -DPLATFORM_ID=11 -DPLATFORM_NAME=esp8266 -DUSBD_VID_SPARK=0x1D50 -DUSBD_PID_DFU=0x607F -DUSBD_PID_CDC=0x607D -DPRODUCT_ID=11 -DPRODUCT_FIRMWARE_VERSION=65535 -DSYSTEM_VERSION_STRING=0.4.5 -DRELEASE_BUILD -Werror -I./inc -I…/hal/inc -I…/hal/shared -I…/services/inc -I…/communication/src -I…/communication/lib/tropicssl/include -I…/system/inc -I. -MD -MP -MF …/build/target/wiring/platform-11/src/spark_wiring_wifi.o.d -ffunction-sections -fdata-sections -Wall -Wno-switch -Wno-error=deprecated-declarations -fmessage-length=0 -fno-strict-aliasing -DSPARK=1 -DPARTICLE=1 -DSTART_DFU_FLASHER_SERIAL_SPEED=14400 -DSTART_YMODEM_FLASHER_SERIAL_SPEED=28800 -fno-builtin-malloc -fno-builtin-free -fno-builtin-realloc -g3 -gdwarf-2 -Os -std=gnu++11 -fno-exceptions -fno-rtti -fcheck-new -c -o …/build/target/wiring/platform-11/src/spark_wiring_wifi.o src/spark_wiring_wifi.cpp
In file included from …/hal/inc/inet_hal.h:35:0,
from ./inc/spark_wiring_platform.h:4,
from ./inc/spark_wiring_wifi.h:29,
from src/spark_wiring_wifi.cpp:26:
…/services/inc/static_assert.h:18:39: error: static assertion failed: spark_data_typedef_is_1_byte
#define STATIC_ASSERT(name,condition) static_assert(condition,#name)
^
…/system/inc/system_cloud.h:100:1: note: in expansion of macro 'STATIC_ASSERT’
STATIC_ASSERT(spark_data_typedef_is_1_byte, sizeof(Spark_Data_TypeDef)==1);
^
…/build/module.mk:209: recipe for target ‘…/build/target/wiring/platform-11/src/spark_wiring_wifi.o’ failed
make[1]: *** […/build/target/wiring/platform-11/src/spark_wiring_wifi.o] Error 1
make[1]: Leaving directory '/home/karlsone/projects/particle/firmware/wiring’
build/recurse.mk:11: recipe for target ‘wiring’ failed
make: *** [wiring] Error 2
Any ideas on that? It’s still on the copied template code.
C does not guarantee the size of an enum, except that it can hold a int type if needed.
It looks like the gcc version you are using for this platform (xtensa-lx106-elf-gcc) is not setup to minimize the size of enums the way the Particle version is.
Have you tried adding the -fshort-enums flag to gcc?
Alternatively there is a attribute packed thing you can do in the source.