I’ve been thinking that photon is an open source project but looking at develop branch seems like it’s including a lot of .a without providing source codes. That includes WICED and FreeRTOS.
@mojtabacazi, you can download the WICED source code by registering an account with BROADCOM.
I don’t think the new license allows the raw source code to be publicly available but users can download from their side.
Oh Cool. Just registered on the website waiting for approval 
Any instruction on how to compile it for Photon?
That i have no clue
Multi-threading should come in the next few weeks so if you can wait…
It’s presently unclear if we can distribute the WICED sources - the license text in the source files is a permissive license that allows redistribution, yet the instructions I was given from Broadcom stated we can only distribute the headers.
Since we were already in a position where only the headers were needed, I’ve left it as is for the time being since it’s simpler for users to get started.
There isn’t any functionality to gain by installing WICED locally, but of course you do gain transparency. To build the wiced binaries, take a look at the scripts in “hal/src/photon” - wiced.sh/wiced.bat. These are using an internal app to build the libraries, but you should be able to easily change this to snip.scan or some other standard app.
@mdma what about FreeRTOS? That can be included in source form in your project right? FreeRTOS has a configuration header file and I would like to change the configuration later on to suit my needs.
If you start changing the system firmware then you’ll essentially be on your own since we can no longer roll out cloud updates to the device.
What changes do you have in mind specifically? We might be able to roll those in or provide some alternative approach.
@mdma My problem is that your code (bootloader, wiring, etc) made tons of assumption that are not always true. For example in Core, the way bootloader structured make it impossible to put the mcu in STOP mode ( not talking about sleep or standby mode). Another problem with core was that WiFi/Cloud stuff were blocking system where as you could easily achieve the same result by making all those non blocking.
In Photon, bootloader makes it impossible to use any interrupts (they are simply point to an inf-loop) including ADC /DMA. The other issue is WiFi functionality is tied to Paritcle Cloud. WiFi.ready() checkes WIFI/DHCP/Cloud where as it should only check the wifi, so user can detect each step. There are many more examples of false assumptions your code is making and since there is no clear documentation for it, every time I have to go through a guess game to figure out what the problem is.
I think it make more sense if you write some helpers that sits inside the RTOS vs building a new layer on top of it.
When we make assumptions that don’t work for you, please bring them to our attention. Then we can work to resolve the issue or provide a an alternative approach.
There’s some misunderstanding in your other points which I’ll try to rectify.
While the Core did prevent stop mode by setting the watchdog in the bootloader, that problem is rectified now if you flash a new bootloader, and it’s never been an issue with the Photon, so Stop mode is available there.
You can always set interrupts by pointing the VTOR to a new ISR table. This is what we do on the Photon to override interrupts that are already hooked by Broadcom’s WICED library. However this is overkill for user code, so we will be providing a system level API to allow you to hook arbitrary interrupt sources, such as ADC, TIM12_CC1 etc.
WiFi.ready() doesn’t check the cloud only WiFi. It is possible to compile firmware without any Cloud functionality, if that’s what you require. Asynchronous connection code cannot be easily worked into the Core where there is only one thread of execution. However, on the Photon, where we have multithreading support, we will be running all system code on a separate thread in the near future so all connection-related functionality will be asynchronous to application code.
Running as a helper inside RTOS isn’t possible due to the WICED library which itself wraps FreeRTOS / ThreadX to isolate user code from the underlying RTOS. You don’t mention specifically what you’re trying to achieve. Rather than requesting we restructure the system to meet your needs, please let me know what those needs are so we can accommodate them.
3 Likes
Oh I did not know that. Well, then does particle plans to provide us with APIs so that we can do multi-threading programming? I would like to create threads and signal them with semaphores and use mutexes. Anything that can allow me to do inter-task communication and synchronization.
Low-level concurrency primitives like Semaphores and mutexes can be very tricky to get right, so we are thinking of going with something higher-level, such as channels - https://github.com/ahorn/cpp-channel.
There are more things about Core bootloader, it alone is about 20KB in size, firmware will add ~70KB on top of that. All my code (which covers 90% of bootloader functionality and firmware) is ~30KB
Also if I update bootloader how do I know that it won’t break anything else in the new version?
For Connectivity code, it is actually possible to make it non-blocking using multiple state-machines. There is no need for multi threading. All my Cores are running like that.
For interrupts If I move VTOR alone it will disable all other interrupts others might be relying on.
I agree on WiFi.ready(). I was mistaken on that one.
Not if you first copy the ISR table so they are identical, and that you chain the ISRs so that the original ISR is called.
The Core bootloader is 10K in size with the latest build. You naturally reduce the size of the code by removing functionality. Your guess at 90% could be pretty arbitrary, but if that 10% happens to be some of the larger pieces of the puzzle, then it's easy to see how you get a reduction.
I agree that state machines can provide some level of interleaved execution, but it's a considerable rework of the internal codebase and the resulting code is pretty ugly and non-intuitive. And unless you rework that asynchronous state machine design all the way down to the cc3000 driver, some operations will block, potentially indefinitely, e.g. socket connect, socket read. A design on Active Objects is much easier to read, understand and debug.
It sounds like you have something working for you that fits your needs, so I'm puzzled at exactly what you're point is.
Well it worked on Core, but I needed rest of source for the Photon so I can run it on photon as well.
aaaand this brings us full circle!
The changes you’ve described are made less pertinent by advances with the Photon:
- code size reductions aren’t needed since we have much more storage on the photon compared to the core
- asynchronous communications will be available in a few weeks.
If you’re not using any of our stack, you can of course code bare metal and rewrite everything.
With the issues you mentioned (code size and asynchronicity) now moot on the photon, what will you gain by rewriting the firmware from the ground up?
I’m tried of debugging Someone else’s code, it took a day to port the code but then debugging and finding that the ADC IRQ causes system reset took 4days. I actually got it working but now I figured PWM is not available on D0, Also it cannot produce 500KHz/50% (or may be it can ?) on A4 (the only pin I have left).
What I’ll gain by rewriting is that I make sure it does what I need it to do and nothing extra which will reduce potential bugs. I decided not to go that path for now tho. BTW, Photon code is far better than Core.
I like Async WiFi operation but the fact is I have to wait for WiFi to turn off before start working, it causes lot of noise on analog signals.
And I appreciate your quick response. I’ll ask more question later 
Let me ask you these for now,
How can I implement Photon WiFi setup on iOS?
We have a Mobile SDK for iOS that exposes the setup functionality. ANNOUNCEMENT: Mobile SDKs beta release