I would like to test my firmware on a linux machine before flashing it to a photon. I cloned the firmware code and checked out the branch latest since I want to develop firmware for a photon device. I then tried to compile with PLATFORM=gcc, but I ran into compilation errors (which I patch-hacked myself) and am now running into various link errors. Am I going about this right? Is PLATFORM=gcc supposed to compile the firmware for a linux PC or is it intended for something else? Am I trying this in the wrong branch perhaps?
Here are some of the compilation errors I ran into:
./inc/socket_hal.h:98:33: error: expected identifier before numeric constant
src/gcc/socket_hal.cpp:34:19: error: boost_socklen_t does not name a type
And the first link errors:
firmware/system/src/main.cpp:129: undefined reference to `wlan_connect_cancel'
firmware/system/src/main.cpp:148: undefined reference to `HAL_Set_Sys_Health'
I have gcc 5.1.0 and BOOST_LIB_VERSION 1_55 on ubuntu 12.04.
It would be cool if someone were to write a HAL that emulated a Photon or Core on a higher level system like Linux. I could imagine an API to pretend to be the hardware, even with graphics something like the Tinker app. But this is a very large undertaking. I don’t think it is practical to do what you are trying to do.
Flashing to a Photon is hardly a one-chance-only event. You can flash it, and flash it again, practically unlimited numbers of times. If you do end up bricking it, there are recovery methods for just about every software mistake you can make. I just debug in this way. I utilize Serial.print through the USB extensively to follow my program when it is hard for me to figure out what dumb mistake I made. It’s usually pretty effective.
I am not that worried about bricking the photon, and I will utilize Serial.print for debugging, but I’d like to be able to debug with gdb or a another real debugger on linux, if possible.
Oh, I don’t disagree with you. It would be a really cool thing to do, to debug your code in a real debugger. I’m just saying it would just be very hard to create the environment necessary to do it. It is a far more involved thing, than just fiddling with the build variables.
To give just one small example out of thousands as to why the code won’t just work on Linux: the firmware code peeks and pokes into specific memory locations in the ARM chip that are registers for various built in hardware components, like timers, UARTS and interrupt vectors, just to name a few. In order for that firmware to work in Linux, you would need to either intercept those calls at the hardware abstraction layer and write your own HAL, or implement some sort of threaded hardware emulator that operates on those memory locations. Both are doable. Both are a tremendous amount of work.
Another approach would be to find an open-source ARM emulator. However, that would be really hard to get set up completely.
Thank you for your comments, rvnash. You mention that compiling for a Linux target would require a new HAL implementation. Setting PLATFORM=gcc causes the code in hal/src/gcc to be compiled, which looks exactly like that - a HAL implementation for PC. Some of the compilation/link errors I got were in that HAL implementation so maybe it just needs some tlc…
Wow, is that right? I didn’t realize a HAL implementation is intended to exist for large scale OS’s. Thanks for the info. It would be nice to write and debug a program from the comfort of a real OS with well developed tools.