Hi, I did prototype using esp8266 SoC now moving to Production , Currently we are facing some issues while using esp , like connectivity issue , data is not sending to server … etc . so we are afraid of putting esp in to mass production for building end-product .so as of now we are looking Stable , reliable wifi MCU so that’s why ended up here . I really liked Photon hardware selection , **cypress wifi with STM32 Processor .
So My question is
How many are used Photon in End-product (mass production ) how reliable is (please list some consumer products)
Would like to know the firmware development cycle .
If you have developed a prototype on a ESP8266 SoC then you can probably think about using a P1. The main issue for consumer products is the requirement for certification for radio emissions (EMR) - you get this if you use the P1 because it contains an antenna and is already certified. Not sure what else your product does but maybe you can avoid needing to spend on lab testing. There are various links to using P1 on the community and a good example is: https://www.sparkfun.com/products/13321
Alternatively, use the photon and that removes issues with the power supply as it will work off most 5V adaptors. It is larger and more expensive - but quicker to get a full prototype working. I currently have about 500 devices out in the wild (all photons) but looking at P1 and the new mesh devices when they arrive (soon hopefully). The Console and device management software are really things you need once you have more than a handful of ‘things’ working. Most of the processes (wifi setup, claiming) have been solved and you can draw on the experience of the community - people like @Scruffr who has never not been able to solve an issue I have had!
@ScruffR@armor Thanks for the awesome replay .can you please the explain the process of building firmware (which language should be used for mass production/better reliability ) and how we can setup the device claiming process . or please share particle doc for this.
From my experience the quickest and easiest route is to use the webIDE, there is no difference between a prototype software development language and production. The programming is in arduino like wiring which is C/C++ with a specific structure setup() function - performed once at power on and loop() function - performed thereafter. The source is compiled on the cloud into a binary that can then be flashed OTA to devices or downloaded via USB connection (with photon). Initially, you can claim devices using the webIDE or CLI. Your production claim process will depend upon the customer model. I don’t allow customers to claim devices, they use a webApp to interact with the Particle Cloud and do not see any of the authorisation processes. The Console (now) has lots of tools to help manage software versions and automatic OTA updates to the latest released version. Your first step is to buy a photon and open an account with particle cloud and get experimenting.
Addtionally to @armor’s description, you can also build the entire firmware (application and Device OS) locally with a standard STM32 gcc toolchain and even tweak things in the open source system firmware.
Not sure what you include in ‘provisioning’. My factory process is as follows:
photon is put in dfu-util mode and loaded with system firmware (2 parts) for the app firmware version and tinker with CLI
from CLI using a team user account Particle Setup is run - this claims to the account and allow connection to wifi and at the end device naming - device name is set to the product serial number
photon is put in dfu-util mode and loaded with application firmware - this is ‘product’ API enabled
device is now a ‘product’ it shows in the Console and also in the factory web app where they assign it to the customer account (the device may be assigned to an “under test” account or “not assigned” which happens if building to stock rather than order).
Photon should be able to do just about anything you could do with the ESP, but with more management possibilities. To get close to that with an ESP you would need to use something like Zernyth (not that I’ve tried it personally).
There’s no choosing. The Particle ecosystem uses an Arduino-like language, but is basically c/c++. So with that in mind, I guess “both”… Have a look at the docs, and the libraries (and their examples) in the Web IDE to get a feel for how the code looks.
I’m curious if you’re having range/rf/interference or server issues, both may not be fixed by changing to a different device. Also, I’d be worried if you have issues with the ESP, the code (or programmer) may be the issue. I’ve had ESP devices in service for years without issue, although ESP devices likely have a lower reliability issues.
I’m an SRE, so would caution, changing the device may not resolve your issues. Not that I don’t love the particle devices, I do, just don’t want to miss lead you.