Hi
I have a problem with my project, it is to make an ebike monitor.
Most of the things that need measuring do not need to be done at high speed one cycle of the loop will be quick enough as long as the loop is not too long. The speed sensor is another thing.
The sensor will be put on an interrupt according to my calculations the interrupt will be activating at a max of 260 interrupts per second when at a speed of 30mph(my maximum speed.
An interrupt will occur every time a hall sensor passes one of the magnets built onto the motor which is 26 per revolution on this wheel.
The sort of code that will be required in the interrupt ideally will convert the pulses from the interrupt to kph(if MPH is requires then the conversion will be done at time of display.
Number of poles(interrupts per revolution) and cercumfrence of the wheel will be stored in EEram. For this test project I am bypassing storage in EEram and using constants, the circumference will be 1370mm the number of poles will be determined in first test then locked into first revision of program.
...with the proviso that you use the ISR sensibly.
e.g. Just increment a pulse counter, or other low latency uperation.
Let your slow loop do the calculations.
You may get wheel pulses at (3.5kHz or whatever... big numbers), but it’s ok if the display only updates at 20Hz or whatever.... i.e there will be ~many wheel pulses before the core wants to refresh the display... plenty of time.
Yes - Given the volume of data OP wants to store at rest, adding an extra component rather than using built in eeprom makes limited sense to me - was just trying to be funny (that link works for me)
EERAM is a standalone SRAM memory with shadow EEPROM backup that helps retain the contents of the SRAM memory when system power is lost. The EERAM uses a small external capacitor to provide the energy needed to store the contents of the SRAM on to the EEPROM when system power is lost. Unlike NVSRAM, no external battery is needed. EERAM offers unlimited erase and write cycles to the memory and FRAM-like functionality at a fraction of the price.
Thanks for the input.
The reason for asking about the internal lock being accurate enough is that the interrupt is to mesure speed eg MPH this would be done by measuring the time between each pulse/tnterupt, I did read that the internal clock was not accurate enough for a real time clock but since I will only be measuring times of well below a second the internal clock should be accurate.
The contents of the interrupt is at the moment needs to be thought about, to start with I was going to increase a pulse countered a=a++; but this would not include the time factor, my revised code would be to workout the time since the last pulse, that can then be converted into speed just befor the speed is displayed a line of code at point of display can be added that if the pulse time is greater than a given time assume stationary.
As for storage in EEPROM the wheel circumference and number of poles/magnets is a constant but to each bike this is used on so will be set and then never changed the distance will need to be saved before the device is switched off, this will be done with a quick bit of power supply maipulation.
Kendrick
...with I was going to increase a pulse countered a=a++; but this would not include the time factor...
NOT a=a++;
JUST a++;
The time factor is irrelevant when you are accumulating the interrupt count.
Simply count up++, then when the desired period (e.g. 1 second) passes, read the value and reset the counter... a=0;
If you want faster updates, then read & reset every 200mS (1/5th second) - and multiply the value by 5 when displaying.
Easy huh!
Sorry I’m still getting back into the flow of c++ programming after a 15 year break.
I can see where you are coming from if I put in the interrupt pulse++;
Then when I get to the point where I update the display I add some lines of code.
//a- micros at start of code
//b =micros at end of code
//c=time since code was last executed
// d=pulses since last time code was executed
// e= pulses recorded in interrupt
//f= distance traveled since code travelled
{
//calculate microseconds since last time code was called
a=micros();
c=b-a;
b=micros();
//calculate pulses since code last executed
d=e;
e=0;
//calculate distance travelled since code last executed
f=d*(wheel circumference/poles);// for this example circumference=1370,poles=26
}
I think I have missed something but this is a good start.
Kendrick
//a- micros at start of code
//b =micros at end of code
//c=time since code was last executed
// d=pulses since last time code was executed
// e= pulses recorded in interrupt
//f= distance traveled since code travelled
{
//calculate microseconds since last time code was called
a=micros();
c=b-a;
b=micros();
//calculate pulses since code last executed
d=e;
e=0;
//calculate distance travelled since code last executed
f=d*(wheel circumference/poles);// for this example circumference=1370,poles=26
}
