What kinds of modifications does the client wish to make on their own? Simple ones like changing configuration setting variables, or more complex modifications that greatly change the product’s behavior?
Are you using these Photons in the Particle product console? If so, you’d have to mark the devices as development devices.
DFU is much more reliable than Y-Modem, as Y-Modem has to be used while the Photon is in listening mode and can be interrupted if the application makes use of serial in listening mode. DFU much less likely to be interrupted because the firmware does not run while the Photon is in DFU mode.
As far as simplicity goes, the Y-Modem flasher is included in Particle CLI, and dfu-util is it’s own separate binary.
How will the client be building the firmware? Web IDE, Workbench, Particle CLI, Locally with gcc-arm?
It might be easiest include the dfu-util binary with the firmware and provide a helper script that puts the Photon in DFU mode by setting the serial baud rate to 14400 and then flashes the firmware with dfu-util.
Also, which OS is the client using? The method of automatically putting a Photon into DFU works on macOS, Linux, or Windows.
I have developed firmware for clients who are competent with using the command line. I provide them with a copy of the firmware using GitHub. They can clone the repository to their computer with Git. They can make modifications the the firmware if they please, and use po-util to build the firmware locally and flash it with DFU.
DFU is much more reliable and simple than Y-Modem because it is standalone and can be used without installing Particle CLI first. You can put a Photon into DFU mode without touching the buttons from within a script to create a more pleasant DFU experience.
The client has a embedded engineer on board so they would be ok with programming via the CLI or even GCC-Arm.
The more I think about it I don’t really want them to hand over the code that is running on the devices but would rather supply them with the Binary with any changes they request. They could just flash the Binary via DFU using a panel mount USB port that is connected to a Photon’s USB port.
The products have panel mount USB ports like this which connects to the Photons USB port.
It gives you a certain amount of time to initiate the binary transfer and prints “C” while it waits for the transfer to begin.
If you do not transfer the file quick enough it will error out and you will need to hit “F” again to start a new binary transfer session. You can see what happens if you wait to long before sending the file in the image below:
@rickkas7 When transferring binary Files to a Photon via setting the USB serial to 28,800 Baud and then hitting F to enter YModem Binary Update Mode can you also upgrade to new Firmware versions without Wifi?
If I had a Photon running Firmware 7.0 with no Wifi access and I compile a new sketch using the new 1.0 firmware and transfer that over to the Photon using YModem will the Photon update the system firmware to 1.0 just as if you updated it using OTA via Wifi?
I think I just did exactly that but it had Wifi access so not sure if it updated to the new 1.0 Firmware with or without a WiFi connection.
Just trying to clarify since I was under the impression that with a Photon that did not have Wifi Acess and YModem was used for all future updates that I would have to stick with whatever Firmware version that was originally installed on the Photon and I would only be able to update the actual sketch only and not the firmware.