@rlogiacco I came across your Circular Buffer Arduino library while searching Google to learn about FIFO buffers.
I remember seeing you on this forum so figured I would reachout and ask if any changes need to be made for this to work on the Photon or the Electron without any problems.
I’m looking at using this for graphing out a running stream of data like seen below:
It should work out of the box, for what I recall there is no dependency on anything specific to Arduino in the library.
I believe I’ve also used it on a Photon (actually a Spark Core), but I’m not 100% sure about that…
Give it a try and let me know: we can work out the hiccups if you find any 
I got it working!
But not without one issue 
So as is it would not compile for me and threw an error about not being able to find the CircularBuffer.tpp file which is called in the CircularBuffer.h file.
So after reading about .tpp files to understand better what they do, I commented out the #include “CircularBuffer.tpp” as shown below:
And then I just copied and pasted the contents of the CircularBuffer.tpp file to the bottom of the code in the CircularBuffer.h file and it compiled and is working as described now.
I’ve learned a lot about how Circular Buffers work by playing with this code and graphing out the Buffer over time.
The library made it easy to understand and work with
On the Photon I had to add this line to keep the array from being filled with random Spikes in data readings which I’m guessing were caused by the Particle OS interrupts that were operating in the background because your Interrupt trick below prevented the random spikes and dips from happening.
Not sure what compiler optimizations get turned off though. Any ideas if this applies to the Particle Platform?
So I have to say your library allowed me to get going quickly with Circular Buffers without needing to write the code from scratch.
Everything is working the way I wanted it to so I’m happy to see some of my ideas realized with graphing data over time on a color LCD screen.
Good to know the trick does work as intended!
I guess you are populating or accessing the buffer within an interrupt routine, right?
I’m not a C expert, but my understanding is, when the count variable is defined as volatile, the compiler is forced to read it’s value, without trying to use the latest buffered value, as it might change out of the normal process flow.
Normally, if the compiler doesn’t see any change in the process flow, it just uses the latest known value, but when a change occurs in an interrupt, the compiler has no way to guess that.
The downside of declaring a variable volatile is you are forcing read operations to access the RAM rather than just use the register value, a little price in your case. Obviously you want to use it only where needed, that’s why is not on by default…
Thanks for your feedback: I will add the Photon to the supported devices. If you don’t mind I would appreciate a star on the Github project
Humm… what if you rename the .tpp to .cpp? Does it work that way? It might be something related to how the compiler is invoked by the Particle build platform… Anybody willing to advice on that?
BTW, I’m really happy the library is easy to understand 
I think it is.
I just saw one blip indicating the value was out of normal realistic bounds but this happened while I was moving something so it could have been a 255 reading from a bad connection. Other than this one blip I have not seeing any others after adding the Interrupt code the library provides.
I'll be testing this for months I'll know if it's stable long-term or not.
So does things get worse if I want to have many circular buffers using the Volatile method? I do want to add more buffers.
I guess you are populating or accessing the buffer within an interrupt routine, right?
I'm using two Particle Software Timer, so I assume it's working via interrupts.
Timer FillPowerBufferTimer(60000, FillPowerBuffer); //Take a Power Reading every min.
I have no idea how to star Github projects 
I do not have an account there.
Tried that and it will not compile.
It allowed me to get going quickly, so good job.
@RWB, Software Tiers are not interrupts. They are (daisy chained) timers implemented in a single FreeRTOS thread. Because of this, much like an ISR, you will need to be careful when you access queue data in your application. You may need to use SINGLE_THREAD_BLOCK() when reading from your circular buffer. Using volatile as was done doesn't hurt either as you found.
One thing to remember with Software Timers is that a long running timer callback can potentially prevent other timers from firing since all timers are daisy chained and on a single thread. So make sure your data acquisition is faster than the fastest timer interval.
Thanks for that.
Is the SparkIntervalTimer app able to do timers spaced to fire every min? I tried but was not able to get it to work like the software timer. Maybe I was doing something wrong or maybe the library only works with shorter timing frames.
Since declaring the buffers as Volatile things seem to be stable.
I’m calling the timers to take readings every min. I should just bundle all the read task into the same function that the timer calls.
Graphing data out over a 3.5-hour timeframe is looking good on this 240x240 color LCD using that graphing library.
Than don't worry 
Too bad... We might want to verify with Particle if there's any trick to have templated code compile in any other manner compatible to the Arduino world....
No, that shouldn't be a big issue, it's probably using 4 or 6 clock cycles instead of 1, but that's a tiny tiny fraction of time: I just didn't want to have it always on.
The SparkIntervalTimer library CAN give you one minute interrupts but your application is better served with Software Timers IMO.
That makes me feel like I’m on the right track then.
Saw another spike, so I put the read from Buffer for loop() into a SINGLE_THREAD_BLOCK() to see if that is indeed the cause of the random out of range readings.
Learning something new every day.