This is an interesting project. I had much the same idea, but never got around to implementation...story of my life...
Anyway, I had a couple of questions:
1. In the
update_char_display function, you use the following code to update all three digits:
Code: Select all
for(i=0;i<3;i++)
{
switch(i)
{
case 0 : PORTB = all_digits[char_disp[i]] + 0b1000;
break;
case 1 : PORTD = all_digits[char_disp[i]];
break;
case 2 : PORTC = all_digits[char_disp[i]];
break;
default :
break;
}
}
Was there any reason that you didn't simply do the following, and avoid both the loop overhead and the switch statement pipeline flush?
Code: Select all
PORTB = all_digits[char_disp[0]] + 0b1000;
PORTD = all_digits[char_disp[1]];
PORTC = all_digits[char_disp[2]];
2. The raw ADC reading has the
gravity_ss variable subtracted from it, then it is left-shifted by 5 (equivalent to multiplying by 32), and then divided by
display_divider (which was set to 20):
Code: Select all
g_val = current_result - gravity_ss;
g_val = g_val << 5;
g_val = g_val / display_divider;
Since you are only measuring acceleration in the forwards/backwards direction, orthogonal to gravity, would you say the the variable name
gravity_ss is a bit of a misnomer? I understand how the accelerometers work, and that 512 is the value that represents 0g when using a 10-bit ADC, it just seems like naming a variable like this will only serve to confuse people, especially when gravity isn't involved here.
3. Did you do any sensor calibration to see if 32/20 is actually a good number to scale the result by? If you rotate the sensor to be in line with gravity, does it display 1g?
Thanks for the project, and thanks for the good writeup.
--Matthew