Step 3: Software - Menu System
The first thing I developed with the menu and setting system. Creating the menus is easy - just increment or decrement an array index and then read the string out of flash using the PROGMEM directive. I suppose there were few enough strings you could just put it in RAM, but using FLASH when possible is a good habit.
The real work was the setting system. I wanted to be able to set each value character by character. Some of the numbers, like longitude and latitude are 5-6 digits (ignoring the decimal) - I did not want to use a press and change method, even with a jump increment on button hold. Speaking of buttons, this project uses Button.h, which I had initially thought handled debouncing but actually does not. A better choice would be Bounce.h. It was enough to toss in a small delay in the button polling loops, since the CPU itself isn't doing anything else - the RTC keeps time on its own.
So anyhow, the first problem of a by-character setting system is knowing where the cursor is allowed to go, This is handled by a two-dimension array which stores a 1 or 0 for each position on the VFD to indicate if the cursor is allowed there or not. If not, the cursor skips to the next available spot or stays on the last spot. I made liberal use of defined constants so I don't have to memorize which index value goes with with setting array.
The second problem of a by-character setting system is handling data validation. You would think it is as simple as re-assembling your digits back into the value and then doing a comparison against the max value, but to block the user from going to the next value you have to see what that value + 1 would do to the number as a whole. That's not bad for a couple of digits but it's a mess for 5-6. I found it was easier to have a two-dimensional array like the position array to hold the max allowable value per character. This allows you to check the same thing based on index every time the user tries to increment, and coupled with a check for the max value as a whole, this captures most bounds violations. It will still be possible for the user to sometimes set an illegal value. It was either that or a lot more code.
Along the same lines, I didn't care if the user tried to set something like February 30. You can add that sorts of bounds checking if you want. I'll admit I got "project fatigue" and left that sort of thing out.
The real work was the setting system. I wanted to be able to set each value character by character. Some of the numbers, like longitude and latitude are 5-6 digits (ignoring the decimal) - I did not want to use a press and change method, even with a jump increment on button hold. Speaking of buttons, this project uses Button.h, which I had initially thought handled debouncing but actually does not. A better choice would be Bounce.h. It was enough to toss in a small delay in the button polling loops, since the CPU itself isn't doing anything else - the RTC keeps time on its own.
So anyhow, the first problem of a by-character setting system is knowing where the cursor is allowed to go, This is handled by a two-dimension array which stores a 1 or 0 for each position on the VFD to indicate if the cursor is allowed there or not. If not, the cursor skips to the next available spot or stays on the last spot. I made liberal use of defined constants so I don't have to memorize which index value goes with with setting array.
The second problem of a by-character setting system is handling data validation. You would think it is as simple as re-assembling your digits back into the value and then doing a comparison against the max value, but to block the user from going to the next value you have to see what that value + 1 would do to the number as a whole. That's not bad for a couple of digits but it's a mess for 5-6. I found it was easier to have a two-dimensional array like the position array to hold the max allowable value per character. This allows you to check the same thing based on index every time the user tries to increment, and coupled with a check for the max value as a whole, this captures most bounds violations. It will still be possible for the user to sometimes set an illegal value. It was either that or a lot more code.
Along the same lines, I didn't care if the user tried to set something like February 30. You can add that sorts of bounds checking if you want. I'll admit I got "project fatigue" and left that sort of thing out.
Remove these ads by
Signing UpFlag this comment as:
Not NiceInappropriateSpam
Visit Our Store »
Go Pro Today »
