I have to design a Data Logger programusing mikroC PRO to run on the EasyPIC5 board (with PIC 16F877A microcontroller). I also have to use a 2-line LCD for display.
Here is what i have been given:
The program will take measurements from Analogue Port AN0 at regular intervals, and save the raw data to
EEPROM. The user should be able to select any of 6 memory banks to store the results of a logging session,
and should be able to set the time interval between readings at 1 second, 2 seconds, 5 seconds or 10
seconds. The number of readings taken in each logging session should be set to 5, but should be alterable from a #define in the first few lines of the program. Another #define should be used to specify the total number of memory banks (set to 6).
Having quite a bit of trouble with this.
Any help would be appreciated.
EDIT
Up till now i am able to get the readings of AN0 and i write them to EEPROM.. BUT the my question which i stupidly missed to ask.. how would i set the the memory banks to 6 and how to save the logging session to any of the banks
for(i = 0; i < k; i++) // Fill data buffer
EEPROM_Write(0x00+i, i); // Write data to address 0x00
By changing the initial value of i and k you can determine where to store your data.
Related
I have a sensor that sends data at 8Khz to a microcontroller. The microcontroller parse the data and send it to the high level controler at 1Khz. I have seen people using ring buffer to collect the data from the sensor to the microcontroler and then take out the data to send it when we need.
If I receive 8 data but I can only send 1, the 7 other data in the ring buffer are useless...
I am curious why the use of a ring buffer is necessary/better compare to just wait for a new data and send it to the higher level?
Thank you
If you are receiving the data at 8 KHz rate and forwarding that data at 1 KHz rate, it means you get some data every 125 microseconds and you are forwarding it every 1 milliseconds.
Obviously you will need something to store that data every 125 microseconds and send the accumulated data after every 1 ms. For that you need some buffer kind of mechanism to store it. Hope this explanation helped.
I am using the sensors (gyroscope/accelerometer) of smartphones to acquire raw X, Y, X values with time stamps via a sensordemo created. I would like to be able to compare these data points to predefined values.
For example, if a user (female) is standing on one leg for 30 seconds, if she looses her balance at 14 seconds then she is at risk for falling. If she first looses her balance at 19 seconds then she is not at risk for falling.
I need help writing a formula to be able to compare the raw data to predefined model in to a mobile application.
I need to create a board that will contain about 50 LED’s. The LED’s need to be turned on/off individually, and together (timer is based on days suppose every Monday all the 50 LED’s turn on and every day of the week 10 LED’s are turned on).
In my research I have found the LM555 timer but that would lead to a huge circuit of 50 different timers
What is the most efficient way of controlling these LED’s
My first answer was really stupid (i'm so sorry about that) and i don't know why I didn't think before about the amazing "Shift Registers".
Your Arduino don't have so much pin to light every LEDs you had. But using shift registers this is possible. From an 8-bit shift register you can light 8 LEDs using just 2-3 PIN on your Arduino board (1 for clock, 1 for data and 1 for latch).
So to light 50 PINs you just need 7 of this components (for example).
How to use it? There are a lot of tutorials on internet, usually the sparkFun tutorial is my favorite.
Below: an image from Arduino site. It explained how to connect 16 LEDs.
Anyway from the software side, what you have to know ShiftOut function.
After that you have to use time function.
First of all initialize your time variables as you can see in link I posted above.
After, in your loop:
Put HIGH your Datapin connected to 50 leds when previousMonth != month.
Put HIGH dataPin connected to 10 leds when daySum == 10 (so, when previousDay != day you have to increase daySum using daySum++).
I have a setup with a Beaglebone Black which communicates over I²C with his slaves every second and reads data from them. Sometimes the I²C readout fails though, and I want to get statistics about these fails.
I would like to implement an algorithm which displays the percentage of successful communications of the last 5 minutes (up to 24 hours) and updates that value constantly. If I would implement that 'normally' with an array where I store success/no success of every second, that would mean a lot of wasted RAM/CPU load for a minor feature (especially if I would like to see the statistics of the last 24 hours).
Does someone know a good way to do that, or can anyone point me in the right direction?
Why don't you just implement a low-pass filter? For every successfull transfer, you push in a 1, for every failed one a 0; the result is a number between 0 and 1. Assuming that your transfers happen periodically, this works well -- and you just have to adjust the cutoff frequency of that filter to your desired "averaging duration".
However, I can't follow your RAM argument: assuming you store one byte representing success or failure per transfer, which you say happens every second, you end up with 86400B per day -- 85KB/day is really negligible.
EDIT Cutoff frequency is something from signal theory and describes the highest or lowest frequency that passes a low or high pass filter.
Implementing a low-pass filter is trivial; something like (pseudocode):
new_val = 1 //init with no failed transfers
alpha = 0.001
while(true):
old_val=new_val
success=do_transfer_and_return_1_on_success_or_0_on_failure()
new_val = alpha * success + (1-alpha) * old_val
That's a single-tap IIR (infinite impulse response) filter; single tap because there's only one alpha and thus, only one number that is stored as state.
EDIT2: the value of alpha defines the behaviour of this filter.
EDIT3: you can use a filter design tool to give you the right alpha; just set your low pass filter's cutoff frequency to something like 0.5/integrationLengthInSamples, select an order of 0 for the IIR and use an elliptic design method (most tools default to butterworth, but 0 order butterworths don't do a thing).
I'd use scipy and convert the resulting (b,a) tuple (a will be 1, here) to the correct form for this feedback form.
UPDATE In light of the comment by the OP 'determine a trend of which devices are failing' I would recommend the geometric average that Marcus Müller ꕺꕺ put forward.
ACCURATE METHOD
The method below is aimed at obtaining 'well defined' statistics for performance over time that are also useful for 'after the fact' analysis.
Notice that geometric average has a 'look back' over recent messages rather than fixed time period.
Maintain a rolling array of 24*60/5 = 288 'prior success rates' (SR[i] with i=-1, -2,...,-288) each representing a 5 minute interval in the preceding 24 hours.
That will consume about 2.5K if the elements are 64-bit doubles.
To 'effect' constant updating use an Estimated 'Current' Success Rate as follows:
ECSR = (t*S/M+(300-t)*SR[-1])/300
Where S and M are the count of errors and messages in the current (partially complete period. SR[-1] is the previous (now complete) bucket.
t is the number of seconds expired of the current bucket.
NB: When you start up you need to use 300*S/M/t.
In essence the approximation assumes the error rate was steady over the preceding 5 - 10 minutes.
To 'effect' a 24 hour look back you can either 'shuffle' the data down (by copy or memcpy()) at the end of each 5 minute interval or implement a 'circular array by keeping track of the current bucket index'.
NB: For many management/diagnostic purposes intervals of 15 minutes are often entirely adequate. You might want to make the 'grain' configurable.
I am using NXP LPC17xx family microcontrollers (LPC1759 and LPC1768).
How can I determine if RTC is running for sure?
I am doing a test on
LPC_RTC->CCR & RTC_CCR_CLKEN
but it seems no much reliable.
I have seen values in year 3197 or so when turning on my device.
How can I tell if RTC is running and its value is not corrupt?
EDIT:
I ended up adding a simple sanity check in RTC values:
bool DateTime::validate( const RTC_TIME_Type &time_info )
{
if ( time_info.YEAR > 2100
|| time_info.DOY > 366
|| time_info.MONTH > 12
|| time_info.DOM > 31
|| time_info.HOUR > 23
|| time_info.MIN > 59
|| time_info.SEC > 59 )
return false;
return true;
}
It is run during my POST, as suggested bellow.
I battled with the RTC on that chip's grandfather (LPC2148) about 5 years ago. If you look on the Yahoo LPC2000 group (it also covers the LPC1000 chips) you'll see the RTC & its issues come up a lot.
Anyway, I'm going from memory here, but I think I concluded that reading the status register wasn't reliable enough. Maybe the issue was that when power was removed, if the battery backup was absent, things would get scrambled...
So what I recall I did was the following, during the boot phase:
(1) Enable RTC peripheral
(2) Read ALL RTC registers. In firmware, have "out of bounds" min & max values for each field (e.g. year must be at least 2005, and no larger than 2030)
(3) If any value is out of range, reset date & time to some hard-coded value (e.g. Jan. 1, 2005) (product would let user adjust time/date once booted)
(4) Take snapshot of registers; wait AT LEAST one second (use timer peripheral to measure time), then make sure the value changed. I might have gone so far during boot-up as to set the values so that a 1-second tick would/should cause everything to roll over (probably 1 second before midnight, Dec. 31), ensure everything changes, then write back the original value + 1 second. (You would want to do this right as the value changes to avoid slipping seconds)
I will try to dig up the code and see if there was something more. I just recall finally concluding I had to run the damn thing & watch it work before I passed the P.O.S.T. for that peripheral.
(I kind of mentioned it in passing, but just to re-iterate... if your values seem corrupted on power-on, make sure your battery back-up circuitry is rock solid - even a basic circuit with a pair of diodes normally suffices. Could be that the clock is running when the product is running, but that when power is removed, its brains get scrambled.)
Also confronted with temperamental rtc's here....
I don't think a really reliable test is possible, you could store the last recorded time somewhere in non volatile memory, and check that the clock hasn't moved to a past date, and you can also test that the delta between two checks is not too big. That would catch something like the year 3000, but you cannot reduce the tested time lapse to say 1 month - you want the thing to wake up even if it was shelved for say a year.
Do you have the possibility to consult a time source at startup? Eg an ntp server or some other device that your controller speaks with that can be considered synchronized with a reliable time source?
You can route the RTC clock to an external pin and watch it on an oscilloscope or a logic analyzer.
IIRC I did just that for LPC1766/1768 (I have two identical boards populated with different processors).