Post
by Irish Steve » Mon Oct 22, 2012 12:00 am
Have to admit, I've been thinking about that pin concept for a while, my boards are here, but the workspace wasn't ready, so been on hold.
My preference would be to use a short piece of ribbon cable, there's 5 wires for the old switches, and then 4 wires for the rotary and centre button, what I wasn't sure of yet is if the common for the switches and the common for the rotary is the same, or if they need to be kept separate.
If they are common, then that's very easy, it's a piece of 8 way, if the are not, then 9 way, which could be split down from a piece of 16 or similar.
Another option might be to use Arduino style bread board cables, they come with pins on the ends if I remember correctly, so that gives a good fix on the boards, and allows them to be separated at a later date for whatever reason. Pins would mean less risk of "hairy" soldering, which can be a problem if multi core wire is used, and a whisker of wire across 2 tracks can be very hard to see when fine gauge wire is being used.
My thought on the use of the centre button is that it becomes the replacement for a menu long, without having to be long, and the menu short could stay on the original menu button, which would help avoid the problems of did it take the entry or not, so the centre button is the accept, the old menu becomes the escape up a level, or back, or whichever.
Things like model name are slightly more tricky, in that there's multiple moves across the field, and for selecting the character. The rotary is for sure a better way of selecting the character to be entered, would it makes sense to take whaterever value is in the field as being the new character if a left.right is used to move across the field, so select the field, move the rotary to select the character, which changes as the rotary is moved, and then when left/right is hit, that temporarily fixes the character that was under the cursor before the move, then move to the previous/next character, change it in the same way, and then take a centre button to accept the global change for the field. That would save a lot of button presses, as long as there's somewhere to temporarily store the old value and the WIP new one without doing EPROM writes. I would also allow an overflow from the right end to the left end in either direction, and only use the centre as an accept/move on button, to either the next value (on things like the limits screen) or to the next modifyable field that's appropriate, which in some cases would be a return to the higher level.
Another option for the left right buttons, or up down depending on the context, would be to use them to do a direct set to the maximum or minimum value for the field, and the rotary is the step value move. In model settings for example, up/down moves to next character, left/right move to the first or last field of the select area, or maybe the first (space I think) and middle, (or lower case a) last is only one rotate from first, and rotary is then the individual select. If we want to save screen real estate space to use it for other things, maybe left right could be a shift on/off option, so only half as many characters to display on screen.
Having said that, do we actually need to display the entire character set, if it can be scrolled on screen in the intended position, that removes the need to step through the characters below the field, which could save a chunk of space on that screen for other things, maybe even save some space in memory too.
On limits and similar, one of the buttons could be minimum (-100) and the other zero, with an "overflow" from -100 to +100 only needing one click of the rotary.
That's my 2c worth for this evening, I think some of these thoughts may be worth playing with to see how they work in practise, if it's not too much coding to acheive it.
Irish Steve
If it was easy, shure, would't we all be doin it?
_