I am developing a system on an Arduino board that will have two (possibly three) separate modes. And when I say "mode", I mean that depending on which "mode" is selected, the software will process input and display corresponding output differently. In my world (software engineer) this is typically controlled via a conf file that is read during startup and (for various reasons) that mode persists for the life of the program's execution. Though there are variants, obviously.
However this is a combination hardware/software application, so it's a bit of a different animal. I am debating the merits of the various possible approaches. I could have the mode be controlled by an external switch on the product's casing. I could have it set via menuing. And the question is: does anyone even use conf files on a microcontroller project like this? If so, where would the conf file reside (EEPROM)? I read in the Programming Questions sticky that only 2K of SRAM is available for use during program execution. Is that still correct? (the sticky is a year old or so)
Because I am planning on producing a fair number of these units personally, I'm shying away from the hardware option of another switch to wire up. I suspect that production will be somewhat labor intensive as it is. Some users will want a given mode at startup, others of course will want another. That is to say that they won't like a requirement to "configure" their product if the unit comes up in a mode other than what they prefer. They'll want to just switch it on, use it, switch it off and store it until the next time they need it. Therefore I'll need a way of bringing the system up in one mode or another.
The first thought was to ask the customer what mode they'd want and program the board to always startup in that mode, with the ability to switch modes via menuing. But that has obvious drawbacks. The next thought was to utilize a conf file to determine the mode in which the system would startup, including instructions on how to modify the conf file, and retain the mode changing menuing option. But without knowing if conf files are even do-able or customary on these microcontrollers (nor how you could implement it) in addition to the clunkiness aspect of conf file modification for a non-computer type of product user that option is less appealing. Which brings the discussion around full circle to implementing it with hardware via an external switch on the product casing.
So. Any thoughts? How is this usually done on a microcontoller? What would you do in this scenario?
Read up on the EEPROM. You can fit 1k bytes in it. You need two bits, to select your one-of-three modes. Looks like it will fit.
Another common method is to use a jumper on header pins. You move the jumper to indicate the mode. At startup, you read a few inputs to see which one is grounded.
Microcontrollers like Arduino have no conf files. In fact, they have no files at all! Well, an SD card could be interfaced and files read from that, but there will be cost involved there and it's not the easiest because now the parameters need to be stored on the SD card, so an extra step.
I have a couple projects that have parameters that the user can select via buttons and their preference gets stored in EEPROM. As part of initialization, the code reads the parameters from EEPROM, which persist until changed, even through power loss.
If there are already switches and a menu system in the project, it's a no-brainer. If not, adding a button still may be the simplest approach. Assuming there is some feedback mechanism, a display, or just LEDs so that the user can see what he's doing.
billroy:
Another common method is to use a jumper on header pins. You move the jumper to indicate the mode. At startup, you read a few inputs to see which one is grounded.
I'll take back what I said about a button being the simplest approach. This would probably be the simplest approach from a couple different angles.
Sorry for not being clearer, BTW. When I mentioned a conf file, I realized of course that it would need to reside on disk somewhere, likely an SD. I understood that 1K persists on the EEPROM even during power down, and the bit suggestion was exactly what I was imagining in that scenario. This device could be powered down for long periods of time, so I need to consult some documentation on the EEPROM. I hadn't thought of dip switches or a jumper, good ideas.
Considering the target audience of the product, ease of use and cost are far and away the two largest driving design factors. Most won't want to fuss and fiddle with configuration issues each time they use it. So...I'll give it a little more thought. If appropriate, I'll post some code to help others who might be considering a similar operational scenario.
Could also put a button to cycle thru the modes, use 2 output pins to light LEDs to show the mode selected.
Store last selected mode in an EEPROM byte, read it & light the LEDs as needed on power on.
If just 3 modes, then Left LED, Right LED, or both LEDs.
CrossRoads:
Could also put a button to cycle thru the modes, use 2 output pins to light LEDs to show the mode selected.
Store last selected mode in an EEPROM byte, read it & light the LEDs as needed on power on.
If just 3 modes, then Left LED, Right LED, or both LEDs.
Cool! Although the reason escapes me at the moment, I hadn't thought of positive state feedback regarding the mode selection. I like the idea of the LEDs, good call, thanks!
Your suggestion mentioned a push button, which brings me to a question: this device will be used outdoors in varying temperatures and weather conditions. It'll also be exposed to what most would consider rather harsh environmental factors, specifically that of a repair station/garage/workshop. With that in mind, I need some "heavy duty" style push buttons (for lack of a better term) to mount on the exterior of the casing. You can find these in the abstract in the Internet on any one of a zillion websites, but what about the buttons sold by microcontroller vendors like Adafruit, etc.? Would any of you consider those to be "heavy duty" such that they'd weather the aforementioned conditions that they'd be subjected to?
push button ... this device will be used outdoors in varying temperatures and weather conditions ... specifically that of a repair station/garage/workshop.
You're worried about the weather? I'd be worried about the solvents.
If you do use LEDs to indicate which of 3 modes the device is in can I suggest that you use 3 of them and label them specifically 1, 2, 3, A, B ,C or whatever? Users of this conference may be happy with 2 LEDs indicating one of 3 states but your target users will almost certainly prefer a simple, labelled indication. Another alternative would be an RGB LED which would also be easy to understand.