For the time being, it’s Photon only. It’s not clear if there’s enough flash storage on the core to include a RTOS.
On the photon, please note that the RTOS isn’t directly exposed as an API. If there are features you need form the RTOS, please let us know and we’ll wrap up a high-level API for it.
It will be awsome to have all functionality of WICED declared in wiced_rtos.h.
But I think, I can use this functinality directly for local builds.
The user firmware is dynamically linked, so we must hand-pick all the functions that are available. Let me know what functions you need, or more specifically what the use-case is (what you want to achieve) and I’ll look into expanding our API to make that possible.
I want to move away from round-robin scheduling to thread-based. It’s more expensive for controller but much more flexible and better for future system development.
I think next methods will be sufficient:
typedef void (*ThreadHandler)(void *);
typedef void (*TimerHandler)(Timer *);
// Thread
BOOL ThreadCreate(Thread *thread, int priority, String name, Function function, void *parameter);
BOOL ThreadDelete(wiced_thread_t* thread);
BOOL ThreadJoin(wiced_thread_t* thread);
BOOL Delay(int milliseconds); // Delay this thread, not other
// Counting Semaphore
BOOL SemaphoreCreate(Semaphore *semaphore);
BOOL SemaphoreDelete(Semaphore *semaphore);
BOOL SemaphorePut(Semaphore* semaphore);
BOOL SemaphoreWait(Semaphore* semaphore);
// Recursive Mutex
BOOL MutexCreate(Mutex *mutex);
BOOL MutexDelete(Mutex *mutex);
BOOL MutexLock(Mutex *mutex);
BOOL MutexUnlock(Mutex *mutex);
// Queue
BOOL QueueCreate(Queue *queue, String name, int messageSize, int queueLength);
BOOL QueueDelete(Queue *queue);
BOOL QueuePushMessage(Queue *queue, void* message, int timeout_ms);
BOOL QueuePopMessage(Queue *queue, void* message, int timeout_ms);
BOOL QueueIsEmpty(Queue* queue);
// Timer
BOOL TimerCreate(Timer *timer, int period_ms, TimerHandler handler, void *arg); // arg should be stored in timer object
BOOL TimerDelete(Timer *timer);
BOOL TimerStart(Timer *timer);
BOOL TimerStop(Timer *timer);
BOOL TimerIsRunning(Timer *timer);
Also will be necessary to provide system thread priorities (for networking, user tasks and timer events) as well as maximal possible thread priority.
With the SmartMatrix library on the Teensy I’m using a low priority interrupt to prepare data for refreshing the matrix in the background without having the user call a refresh() function. I’m going to try to port this over to the Photon in a few weeks and using a thread instead of a low priority interrupt seems a better way to go.
+1 for an API that would let me do that.
Any updates on bringing 0.4.0 to the Core?
I’m working on it this and next sprint. As soon as version selection is available in the WebIDE I’d love to get out a pre-release and ask the community to help test so we can resolve any issues prior to release.
Hello wonderful Particle developers!
The firmware has already come a long way since the prerelease of 0.4.0 was published back in May.
The original instructions mentioned that the develop branch should be used. This worked while the firmware was in prerelease, but now we have had several releases, it makes more sense to use branches that follow releases rather than those that follow daily development.
Consequently, we now have the latest branch which contains the latest released firmware. Here’s how to decide which branch to use:
use latest (by default) for development against latest stable released code. The features here have gone through our release process.
use develop if you want the bleeding-edge experimental changes to the codebase, with the caveat that these changes may have only had minimal testing. Since the develop branch is updated more frequently than releases are made, you should rebuild system firmware each time you pull changes from this branch to be sure the system firmware is kept up to date.
I urge anyone currently using the develop branch to opt for stability and switch to the latest branch. 
I hope that’s clear - feel free to ask questions if not!
Cheers,
mat.
What would be cool is if the particle-cli would allow to build against the develop/latest branch.
Just to be super clear Photon_043 is the latest stable release (at this time) and has gone through the release process. Would you say that is correct?
Sorry to always be looking for a more explicit answer
Yes, that’s correct although those branches are intended for the compile server and may not be around forever. Please use the 0.3.4-rc2 tag which marks the current release.
I was talking with @nexxy specifically about this yesterday! 
While make is good for builds, it's not appropriate as our top-level entrypoint - things like checking prerequisites are especially tricky.
With the cli, we could compile locally using an extension of the current command, something like:
particle compile photon --local myappdir
This will also open the door to local library management....much excite!
We’ve had a few issues lately with builds not working or having different behavior, which can be attributed directly to using a different version of the compiler than we tested on.
The latest build now checks the compiler version and stops the build if it is older than the minimum required. You’ll find the minimum required version listed in the build docs.
Hi,
I have updated all this, and switched to “latest” branch, but I am having build problems. The culprit seems to be the checkin “disable LTO since it causes linker errors on 2015 q2 ARM GCC 4.9.3. Fixes #471.”.
I got linker errors around isatty etc. Reverting that commit fixes the build issue.
Is anyone else also seeing this problem?
I get:
/usr/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/lib/armv7-m/libg_nano.a(lib_a-writer.o): In function `_write_r':
writer.c:(.text._write_r+0x10): undefined reference to `_write'
/usr/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/lib/armv7-m/libg_nano.a(lib_a-closer.o): In function `_close_r':
closer.c:(.text._close_r+0xc): undefined reference to `_close'
/usr/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/lib/armv7-m/libg_nano.a(lib_a-fstatr.o): In function `_fstat_r':
fstatr.c:(.text._fstat_r+0xe): undefined reference to `_fstat'
/usr/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/lib/armv7-m/libg_nano.a(lib_a-lseekr.o): In function `_lseek_r':
lseekr.c:(.text._lseek_r+0x10): undefined reference to `_lseek'
/usr/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/lib/armv7-m/libg_nano.a(lib_a-readr.o): In function `_read_r':
readr.c:(.text._read_r+0x10): undefined reference to `_read'
/usr/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/lib/armv7-m/libg_nano.a(lib_a-isattyr.o): In function `_isatty_r':
isattyr.c:(.text._isatty_r+0xc): undefined reference to `_isatty'
collect2: error: ld returned 1 exit status
When I try to build my firmware after updating this morning. I am running Ubuntu 14.04 using the terry.guo gcc-arm-embedded ppa for the compiler.
You mentioned you updated this morning - which branch was that? Those errors mean that something is trying to read/write to standard input/output.
Please try removing the build/target directory and compile again.
I successfully did clean build of latest, so it’s not a general problem with the build but possibly something in your environment. Any other details you can share that might help us resolve this?
I am on branch “latest”. The way my code compiles, it always uses a clean version of your firmware. It always builds everything from a clean slate.
My code compiles fine if I revert this commit:
commit ed45a2c411e79437390adfa6f37d706f74ec79d8
Author: Matthew McGowan mat.mcgowan+github@gmail.com
Date: Mon Jul 13 22:42:07 2015 +0200
disable LTO since it causes linker errors on 2015 q2 ARM GCC 4.9.3. Fixes #471.
M modules/photon/user-part/makefile
I am using snprintf() a number of times in my code. I notice that the original bug is sprintf related.
Adding COMPILE_LTO=y fixes the problem for me. When I compile it that way my firmware all works.
Yes, then prices and I are exactly seeing the same. I assume that adding COMPILE_LTO=y is the same as not writing COMPILE_LTO=n (I have no idea what LTO is). I am using the recommended compiler. I did a clean rebuild and also removed the whole directory and checked out again - just to be sure. I guess it is related to the usage of snprintf.
I’m guessing it’s the user-part module that is failing to build?
I’ve added sprintf and snprintf to our build integration tests, but I’m unable to reproduce the error.
Related digression 
The problem we have is that some bugs appear with LTO enabled, and others appear with it disabled! Can’t win either way! 
With LTO enabled we’ve seen crashes - probably due to issues in our code or in the WICED library but it takes time to hunt them down, so quicker to disable the flag until we have time to investigate.