OOP best practice for real time monitor

New to Particle, but enthusiastic about the platform. Currently developing an environmental monitor, which uses interrupts to measure a signal (potentially multiple signals), performs some analysis and occasionally informs a user (via phone app, email, SMS etc etc) if an alarm condition is met.

I’d like to do this in an object oriented manner, and this question is to seek advice on how best to do this. It would seem natural to have a class for each of those activities - but how do you wire it up so each object knows about where to send its output?

For instance, the object closest to the hardware essentially dequeues hardware reads from a global buffer (so that routine would be called from loop) and averages over a set period- but how does it know about the analyser that decides when an alarm condition is met? And how does the analyser know about the notifier?

One solution might be to have an app controller that instantiates everything- and in the init routines provides the callback functions each object needs; or perhaps to set up the sampler and have it instantiate the analyser, which in turn instantiates the notifier? But there’s also a command interpreter which I will use to modify some parameters, so there might be other communication flows.

Advice from OOP gurus appreciated!

Hi @sdcsdcsdc

I think I have a picture from your description of how you envision this working through elegant design patterns from the world of object oriented programming. However, are you sure you really want to do this for your project? Is your goal to produce an environmental monitor, or to learn design patterns in OO through this project?

If it is the former (just produce a monitor) then I would suggest a more straight forward approach be taken. That isn’t to say you can’t have classes, but I would suggest they be statically allocated, and the flow of information between them be hardwired through direct calls.

If it is the latter (learning design patterns in OO), then I would suggest an embedded microcontroller with limited memory and where it is unwise to do a lot of dynamic memory constructs isn’t the best environment to learn these skills.

Anyway, that’s just my 2c’s. If you decide you want to go forward, far be it from me to discourage you.

(btw: You mention the use of interrupts. Again I would discourage the use of them unless you really must have realtime response. Timers or tight loops checking for the next sample time are much easier to get working and debug. And I mean several orders of magnitude easier.)

1 Like

Thanks, @rvnash, much appreciated. The aim is to both produce a monitor, and learn OO/improve the elegance of my code. My initial approach was as you suggest (I think), a bunch of statically -ie global - objects, instantiated before setup is called when globals are initialised.

This wasn’t beautiful: and since the monitor works through a series of states (unclaimed, uncalibrated, running, etc) when different types of objects are needed, I was considering dynamic instantiation (and destruction) of these objects. So the question was about that: if I have a state machine that moves between these states, it can set up objects- but how do those objects interact with each other? They will mostly be singletons, but not all of them. But in light of your advice I’ll reconsider: perhaps I can clean this up while retaining static objects.

Finally, I appreciate the warning on interrupts- but I have to sample at several tens of kHz to do signal analysis: that, at least, is working!

Hey @sdcsdcsdc,
if you want to get a cleaner code, and if you did not already, may I suggest you use a library for FSMs like this one?
I ported it to Particle some time ago from an Arduino lib I found and liked very much and it’s been doing wonders for me.
It’s available in Particle Build, for your convenience.

I’m glad you are making progress on your project and learning how to make your code elegant in the ways that matter. It makes me curious as to what this project is. Care to describe it at a high level? By you mentioning sampling at “tens of kHz” and doing signal analysis, I’m guessing it is some sort of audio processing/recognition system?