Hey there! If you’re trying to set up your Raspberry Pi to connect to the Particle Cloud for the first time and have gotten stuck, make sure you peruse the various development resources that we have available to help get you un-stuck!
Here they are again, for easy access:
Some links are 404. I was particularly interrested in the Raspberry Pi tutorials; but I can’t reach it.
“The page you requested doesn’t exist or is private”
Thanks for the heads up! It should be fixed.
I have doubled checked and all of the links are working again!
@will Where can we find the documentaion to build the Rasberry Pi security camera you guys showed in the beta sign up emails? That is what I really want to build.
This is an awesome effort, and I will use it a lot.
I had hoped this would be a bare-metal OS for the Pi and not simply a software package for Raspbian.
I am in a position where deploying Linux machines everywhere is not a real option, and deploying the same number of Particle devices IS an option.
I would probably ultimately deploy many hundreds (possibly thousands) of Photons, if they supported Enterprise Wi-Fi.
With the Pi, there is (likely) no license agreement to prevent Particle from allowing the use of EAP-TLS, but as I said, deploying that many Linux machines can’t happen where I am.
I know that bulk Linux administration isn’t too difficult; I could do it. My employer doesn’t have the skill set to make it happen, nor the will to gain the skill set in a support capacity.
So close, yet so far…
This is only the beta. Many more features are soon to come, including a setup wizard that creates ready to use SD cards and more remote management tools.
That is good to know. Like I said, I will make use of this tool, without question. I just can't deploy it widely.
Unless the future includes a bare-metal "OS" for this platform, it is another excellent platform that I must, sadly, rule out.
Given the likelihood that Broadcom is to provide a data sheet to Particle for the Pi's CPU, I am not going to hold my breath for a bare metal implementation.
What benefits do you see in a bare metal OS for Raspberry Pi? The fact that particle-agent runs on Raspbian as a daemon, means that you can use a Pi for multiple processes. Additionally, you can call bash scripts on the Pi from within your firmware, so a full OS is a plus here.
As the Pi is a Linux computer it is very different from a Photon or an Electron. It's greatest difference is the same that it shares with Arduino, the fact that a Raspberry Pi is more suited to more computational tasks, hence it being a "microprocessor", and not a "microcontroller".
The main purpose of Particle providing Particle Firmware on Raspberry Pi is to provide users who are familiar with Particle the ability to use the Raspberry Pi like a Photon, connecting to the Particle Cloud, having Cloud Variables and Functions, and OTA updates. Likewise, Particle is trying to branch out to users familiar with Raspberry Pi, showing them what they can achieve with the Particle platform.
It would not be a full Linux installation. A tiny computer like the Pi or the Edison are truly amazing. Linux comes with a large support requirement when deployed en masse.
And not just administration; security, continual patches, whole Linux subsystems that must run and which may expose various things on the network.
The Photon devices already connect securely to a secure infrastructure, and do not expose services to the network by default. A bare metal Raspberry Pi OS would have similar advantages.
You are correct that full Raspbian has advantages. It also has many serious disadvantages to a large enterprise.
What if the setup wizard for creating SD cards provided an option to disable these services?
I don't think you understand how my employer's security people think. [Edited to remove potential insult.]
Not only would they need to be disabled, they would need to not exist on disk. The Linux kernel would need to not exist on disk in any recognizable form. (It's something that needs constant maintenance, upgrades, and patching) The ability to prevent the installation or use of ANY Linux software that is not approved would need to be present. The ability to audit and account for every use of any service hosted by the device is required.
Windows 10 IoT core could work, but it doesn't support enterprise Wi-Fi yet, either. At least we have the tools and skills to audit, administer, and manage Windows stuff.
An easier way to say it, perhaps, is that Particle on Linux on Raspberry Pi is more to worry about from a security standpoint than Particle on Raspberry Pi alone would be.
I wouldn’t even care if the Pi were severely under clocked in such a scenario; let me use Ethernet, enterprise Wi-Fi, and Bluetooth and I’d be very happy with such a device.
Like I said earlier, I am not holding my breath for a bare metal implementation. Broadcom and the Raspberry Pi Foundation would likely thwart any such efforts at every turn.
I don’t know why enterprise Wi-Fi is such a problem for the entire ecosystem of non-Linux IoT devices. The only non-Linux device I know of that supports it is the ESP8266 and its support is so new that it isn’t documented sufficiently enough to easily discover how to use it.
Lots of us need enterprise Wi-Fi, and need to avoid Linux whenever possible. I think I work for one of the few large enterprises that moves quickly enough to encounter this functionality gap, because it seems to surprise some folks. Oh well.
Hey! I have started playing lately with Ansible, for network management and orchestration of the linux servers I work with, and it looks pretty promising.
Would such a tool help you in your scenario?
Cheers,
Gustavo.
Not a lot. I know how to use Ansible, but I am not the person that would manage a horde of Linux machines on my network, so my ability doesn't help at all.
The real issue is with security. There is zero, or very close to zero chance that anyone could convince the security teams within my organization that Linux is secure enough to be deployed in any significant numbers.
Windows and Linux both have their security issues, and I am not trying to say that one is safer or more secure than another. I am saying that the skill set held by employees in my organization favors Windows over Linux by a ratio at least 500 to 1. More, if you want to count the ratios of installed non-desktop systems.
We have the Windows skills and procedures to triage any major issues with Windows. We do not have the skills and procedures to handle even 10 Linux machines in a production role.
Linux just isn't feasible for me in a wide deployment.
A solution that is a Wi-Fi enabled microcontroller, like the Photon, is much, MUCH easier to present to security and administration. The firmware for a Photon can be understood by a single skilled person, in its entirety. Try saying that about Windows OR Linux.
Particle's cloud code is less transparent, and an enterprise agreement with Particle would make sure that liability is properly handled, however that would go, depending on a bunch of stuff I have little understanding of, so that eliminates that issue.
Thank you for the attempt. 
You are welcome. Here's another thought:
Do you think a bare metal OS will have to start with someone porting the freeRTOS to the Pi?
Seems like someone did some work on this area, not sure to what extent, though.
I don’t know how to write something for a pi with no OS.
I’ll bet it’s easier than people reflexively assume, though, especially if you’re porting something already written for an ARM micro.
@will
I haven’t had a change to sit down and really look at the guy code yet but was wondering, theoretically could this install on a C.H.I.P by Next Thing? I have a project that I am currently using Amazon IOT but would much rather use the particle cloud.
Hey there @Tomforti – you theoretically should be able to since they’re both running Linux. That being said, the pinout for the Particle agent will be incorrect, so you won’t be able to toggle or interact with the GPIO or hardware peripherals as is. Forking the agent and adapting to C.H.I.P. shouldn’t be too hard, though, if you are interested in submitting a pull request.