HELP me saving the odometer reading into EEPROM

This is the odometer code

#include <LiquidCrystal.h>
LiquidCrystal lcd(12, 11, 5, 4, 9, 8);

const int odometerPin = 3;
const int odometerInterrupt = 1;

const float wheelCircumference = 0.002035;  // wheel circumference in km

volatile unsigned long wheelRevs;       // total wheel revolutions counted, will overflow after 85 million km
unsigned long lastDisplayedMs = 0UL;    // time when we last refreshed the display


void setup()
{
  // Set up the odometer sensor pin and interrupt
  pinMode(odometerPin, INPUT);
  attachInterrupt(odometerInterrupt, odometerIsr, FALLING);  
}

void odometerIsr()
{
  ++wheelRevs;
}

void loop()
{
  // Capture the wheel revs with interrupts disabled in case it changes while we read it
  noInterrupts();
  unsigned long savedWheelRevs = wheelRevs;
  interrupts();
  
   unsigned long now = millis();
    if (now - lastDisplayedMs >= 200)    // update display every 200ms
    {
      lastDisplayedMs = now;
      float km = wheelCircumference * savedWheelRevs;
      lcd.setCursor(7, 0);
      lcd.print(km, 1);
      lcd.setCursor(14, 0);
      lcd.print("Km");
      
    }
   }

I would like to save the wheelRevs every time the power goes off..

I am only bothered as the wheelRevs will gradually keep increasing the more I ride the vehicle, so how will I save it into the eeprom...??

for example 491 wheelRevs = 1 km

so if I have driven 10,000 kms that is 490000 wheelRevs.
How doI save such a big number into the EEPROM...??

moreover I will be having additional 4 A, B, C, D Trip meters.. So I will have to save wheelRevs for them too... :frowning:

How..??

I would like to save the wheelRevs every time the power goes off..

How will you detect that power is going to go away, prior to it going away and terminating the sketch?

wheelRevs is an unsigned long. It is easy enough to extract the 4 bytes that make up that long, with bit shifting and masking or using a union. Once you have the 4 bytes, store them in 4 addresses in the EEPROM.

On start up, read the 4 addresses, and reassemble the unsigned long, again with bit shifting and masking or a union.

One thing you could do is to measure the time between ISR calls. When the time exceeds some value, the vehicle is traveling very slowly/stopped. Save the data then. If the power is lost, you have saved data. If the vehicle starts moving again, you've wasted a write cycle, but that might be OK.

moreover I will be having additional 4 A, B, C, D Trip meters.. So I will have to save wheelRevs for them too...

You save these exactly the same way. Setting a trip meter to 0 simply means recording the number of wheel revs at that time. Each time you want to display that trip distance, subtract the starting wheelRevs value from the current wheelRevs value to get revs since reset, then multiply by circumference to get distance.

These are even easier to deal with as they only need to be saved when the set/reset button is pressed, not on power down.

How will you detect that power is going to go away, prior to it going away and terminating the sketch?

ohhh..
thats not a big deal..
I have the A0 of the atmega measuring the main voltage.. and a big capacitor is also connected in parallel to the main supply..
So when I will detect that the A0 has gone below a certain value the code will write the current wheelRevs into the EEPROM with the existing power stored in the capacitor..

Hummm now the write to EEPROM part..

will you please show me with an example please..??
I am not able to understand much from the bitshift reference page.. :frowning:

I am not able to understand much from the bitshift reference page

So try a union.
Or try this

AWOL:

I am not able to understand much from the bitshift reference page

So try a union.
Or try this

:slight_smile: I just went through that page and it is possible to write anything to the EEPROM..

but at the same time I do not want to run away from learning about bitshift..
:stuck_out_tongue:
Please teach me about this bitshift as how to use it to write such big nos. to EEPROM...??

Think of bitshift as dividing (>>) or multiplying (<<) by powers of two.

If you mask a value with another value, the only bits that will remain are those that are true (1) in both values.

So:
unsigned long val = 0x3456;

unsigned long mask = 0xF000;

unsigned long masked = val & mask;

will result in masked being 0x3000. Now, if you shift ( >> ) this 8 times to the right, you get 0x0300. If you shifted 16 times, instead, you'd get 0x0030. If you shifted 24 times, instead, you'd get 0x0003.

If you store this last value in a byte, you get the same value as the 1st byte of the long.

If you use a mask of 0x0F00 and shift 16 times, you get the 2nd byte of the long.

If you use a mask of 0x00F0 and shift 8 times, you get the 3rd byte of the long.

If you use a mask of 0x000F, you get the 4th byte of the long.

Putting the long back together is just as easy. Simply shift in the other direction ( << ).

Search for VirtualWire posts, where people want to send longs using virtual wire.

Joy, have you had any success with this? I am working on the exact same thing, maybe we can help eachother out?

Mike

Assuming that you are driving at 100 km/hr speed; your main line program (the loop function) will be interrupted at every 73 ms (1/((491100)/(6060))) interval. Have you thought about this -- your MCU/loop() function might not like these kinds of frequent interruptions. They are machines; but, we have induced intelligence into them through programming; they might get tired/fatigue like human beings and ultimately end up with catastrophic breakdown.

You may check your system by simulating interrupt signal at every 73 ms. If you are not happy with the performance, you may think of assigning a counter (TC0/TC1/TC2) to accomodate so many wheel revolution pulses; read the count via interrupt strategy or polling strategy (I would prefer polling!).

GolamMostafa:
They are machines; but, we have induced intelligence into them through programming; they might get tired/fatigue like human beings and ultimately end up with catastrophic breakdown.

You're going to have to explain that particular bit of mysticism

AWOL:
You're going to have to explain that particular bit of mysticism

Too big job for me! Let people enjoy their liberty to express their intuitive feelings! Things can always be screened out by the Respected Moderator.