Repository for the GCC LCA (Low-Cost Array) Senior Design project 2018-2019. The LCA_SYNC folder contains the C# .NET Windows application, and the other folders contain the Arduino sketches.
The way interrupts are used in the Mega code needs to be reevaluated. Especially places where interrupts are enabled or disabled. The interaction between the interrupt routines and the main loop is a bit complicated and probably a little buggy.
Some interrupts may not be needed at all and may only be complicating things. For example, maybe the serialEvent interrupt routine (which occurs when the Arduino receives serial data from the LCA Sync application) could possibly be made into a normal function that is called in the main loop if there is some serial data available for reading. This would make reading serial data always occur at a certain spot in the main loop - not an interrupt that can happen nearly anywhere. It would have a specific place in the sequence of events that happen in the main loop. The serial event interrupt is never disabled in the code, so there's a possibility that the sampling routine (reading thermocouples, reading RTC for timestamp, and writing data to the SD card) could be interrupted by it if the LCA Sync application sent a message at the wrong time. That could be pretty bad.
Setting the time and date of the real-time clock (RTC) on the Arduino Mega can be done from the LCA Sync application (Check "Synchronize Time and Date" under the Config tab, then press "Sync").
This works fine before you start a test. However, once you start a test and that test ends (the program doesn't let you set the RTC while a test is running), if you try to set the time and date of the RTC from LCA Sync, you will not receive a serial response from the Arduino and the whole Arduino will lock up. It won't respond to anything - pushbutton presses or LCA Sync serial messages.
Even after a couple hours, I still don't know what causes it. I'm fairly certain it is not a problem on the LCA Sync side. I think it occurs at or around the rtc.adjust(dt); line in the ProcessOtherCategory() method in the serialSync.cpp file.
It's very weird since I don't know why it would work fine before running a test but not after running a test.
A few times I've tried to run a test with a sample period of 1 second, and the test started running with a sample period much shorter than that - probably somewhere around 0.6 seconds. It only seems to happen when the Arduino loses power and then is plugged back in again. After the test that runs too quickly, subsequent tests that I start seem to behave normally with 1 second sample periods like it is supposed to have.
I haven't investigated the cause of the issue yet.
We began porting the code over from the Arduino Mega to the Due, but the code doesn't work yet. Also, it uses an older copy of the Arduino Mega code, which would need to be updated.
Going forward, maybe the Arduino Mega and Arduino Due code can be combined together. Most of the code is going to be pretty similar anyways. This would simplify development because if changes are made on the Mega version, you wouldn't have to copy all the changes over to the Due version.
This could be accomplished with preprocessor directives that check whether you are compiling for the Mega or the Due and choose different methods and libraries depending on that.
Sometimes stopping a test will cause serial communication with the LCA Sync application to stop working and cause the pushbutton to not actually start tests anymore. When the pushbutton is pressed, it will recognize it and go into the startTest method (or stopTest method?), but the test doesn't actually run. It just does nothing. I'm not sure if the issue can also occur when trying to stop the test via the LCA Sync application.
I have a feeling that the issue is caused by interrupts somehow. The interaction between the interrupt routines and the main loop is a bit complicated. Maybe the sampling routine in the main loop is getting interrupted and that is causing issues. I don't know. The way interrupts are used in the program needs to be reevaluated. Especially places where interrupts are enabled or disabled.