What is "firmware" (hopefully not as silly as it sounds)?

Okay, I understand that firmware is the low-level code that runs on a device, but it is not clear to me how the term “firmware” is being used in the documentation.

Presumably there will be some kind of code that the Partical will use to talk to “the cloud” (i.e. the Particle service, where-ever that is). I assume that will be updateable, and will need patches from time-to-time, or even a complete replacement if the device is going to be used in some way the Particle service was not designed for.

But is that what the documentation means by “firmware”? Or is firmware actually the code that I write to control the actions of the device when it is running? Is that the firmware?

In connection with this, the API allows me to upload code as a CPP file or a binary file. Do these both have the same effect? If I upload CPP, where does it get compiled - on the device, or in the cloud en-route to my device?

The documentation provides a lot of detailed information, which is great, but I’m missing the big picture - how does everything join together - my Particle account, the “cloud”, my device, the low-level device firmware (who maintains that?) and the code I write for the device, that gets compiled somewhere and linked into libraries somewhere (statically linked in the cloud before being uploaded as a binary file, or maybe they are on the device in the low-level firmware and linked dynamically).

I’ve not even tried the local IDE yet - just pressing buttons and seeing things work but not entirely sure how.

Any illumination on how it all hangs together without “magic” would be appreciated.

Okay, just found the firmware repository, with an explanation here:

So “firmware” is the system that runs on the device, talking to the hardware.

The API has an “upload firmware” section, where either source or compiled code can be uploaded:

https://docs.particle.io/reference/api/#flash-a-device-with-source-code

Is that really firmware? Or is it my CPP code running on the system? Or are they one and the same?

Actually in the terminology here there are two major categories of firmware:

  • “system firmware” which is like the OS of your device and
  • “application firmware” (aka “user firmware”) which is what you usually write and flash

On Particle Cores both are baked into one binary file always replacing both parts with each new app FW.
On the other devices the FW modules are seperated and can be flashed individually, but the app FW has to be compatible to the sys FW present on the device already. So if there is a new system release you can choose to keep your current “OS” but have to make sure your app always targets this version, or you upgrade your “OS” and just use the latest build target.

Just to clarify, the source is never flashed to the device, it’s always a binary.
But you can upload either a binary file or the sources to the cloud and the cloud either directly flashes the binary or first builds it from your sources and then flashes this to your device (or sends it back to you to do whatever you want with it).

I did suspect that may be the case. The firmware that the API deals with, is that just the application firmware?

There is presumably another level on the device to boot up and deal with loading the initial system - the boot code that just talks to a local WiFi or USB, without doing much else. That will be firmware too, but would presumably need to be kept a little more under lock and key to help prevent devices getting bricked by accident.

Looking through the firmware git repository guide, that seems to compile the user application(s) and the system, all as one big lump. Is that what always gets uploaded to the device - system and apps every time the app needs to be updated? Or can apps be uploaded without the system being sent too?

This is refered to by the term “bootloader” (also a firmware module)

See above again :wink:

Cool - that makes sense, thanks.

I guess I wouldn’t upload CPP code through the API automatically, unless I know it already compiles. And then I would not have as much control over the system it compiles with, so it may work today, and not tomorrow. But it sounds like a handy feature for rapid deployment.

I think you were adding answers to your reply as I was guessing at the same things :smile:

Before going into this you should have a play with https://build.particle.io
This will already answer some of your questions

That’s the “curse” of this community, it’s sometimes too responsive :sunglasses:

If it doesn’t build there won’t be a binary to flash, so you’re save.

Yes, I have had a play with that a few weeks ago (it was a Boxing Day project), creating a bit of code that flashes a message in Morse code when a message is entered into a simple PHP page. It all kind of just worked which make it a pleasure to use, but now I’m digging a little deeper to see just how it did work, and what I would need to keep under source control and how it would be built by other means if starting again.

1 Like

Unfortunately there is no source control (yet :weary: ), so you need to find a good way for yourself.