I was hoping to use a photon as my Mqtt pub sub message handler and once a json payload had come in push it to the arduino to perform an action of some sort…
I’m doing a uni project where I’d like people to be able to send a pic from there phone and have it displayed on a screen but also a geofencing component if they enter or exit certain zones the screen and some servos update with notification information… Running in the background I’d also like to have weather on another screen and power some LEDs…
So far I’m thinking of using a particle for the messaging and a teensy to handle the interactions… I’m wondering if I should have one microcontroller per action type… I.e. leds on one… Servos on one… Screens on another or is it possible to multitask something in that way? One of the hurdles is handling passing a payload between the photon and the teensy or a pi or something. And the other is the consideration would it be easier to have a broker kind of device to handle incoming and outgoing messaging and then have separate controllers manage their own smaller tasks rather than trying to multitask
Or would good code setup help I.e. state machines and things
Coming from oo web programming land and .net I’m trying to get my head around project structure and code styling
Well, we all end up going different directions. There are so many choices and combinations of choices that everyone does whatever best matches their needs and wants.
Since you are doing a uni project, I would suggest starting to do just one thing.
Once you get that working, do another. After that, you can integrate them together. One of the biggest dangers is trying to do too much at once and not getting anything completed. (For this same reason, I have a bunch of ideas I am setting aside for now.)
What I strongly suggest is to set yourself a clear objective goal. With a clear goal, you can set out your requirements. Based on those requirements, you can focus on searching for the specific hardware and building a system that meets your needs.
When you have a goal in mind along with some rough requirements, this forum can help out in validating if you are on the right track.
In summary, you choose your path, we will give you some guidance to help keep you on the path, but you will still have to do the work (and we need you to help us help you).
Splitting the project up in “selfcontained” sections is a good advice.
Once you have the individual portions running reliably you can assess the size and needs (e.g. µC cycles, periferals, …) of each part and see if some can be combined into one sub-project running on a single device or whether that one task is too demanding to share the controler with other tasks.
If you then couldn’t pull off the combination, you would still have a running project - not perfectly streamlined, but running.