Exact match. Not showing close matches.
'[PIC] Menu system ideas'
I am working on a Remote LCD display that connects to another board via SPI.
The signals available between the boards are SCK,SPO,SPI,+5,GND and 2
bidirectional IO lines.
What I want to do is transmit a MENU from the main board to the display
board. The display board would then
independently navigate the menu using buttons on the board.
When a selection is made, a message needs to be sent back to the main
board to act upon the menu selection (This may then send another Menu to
navigate or perform some action based on the keys pressed on the display
ie. The user may scroll down several menu levels to get to an adjustment
setting, They then can change the values of the setting.
There are several issue I need to resolve.
1) SPI protocol
I am not sure if it would be best to have the main board become the
Master and display become the slave and poll the display
periodically for keypresses or whether it might be better to let
either board request to be a master to send by pulling one of the
IO lines low, the other micro responds by pulling the other IO line
low. ?? Any ideas.
2). Menu Structure
I am not sure what would be a good structure to use for the menu.
Whether it simply displays 1 level at a time and then requests
the next level when the SELECT key is pressed or previous level if
ESC is pressed.
The navigation keys are UP, DOWN, SELECT and ESC. For Value changes,
there are 4 function keys that can be used to scroll values.
Any ideas much appreciated.
Thanks in advance
On Fri, 14 Oct 2005 12:20:57 +1000, you wrote:
Have the main board as a master, and a signal that the slave can send to say 'something has
happenned, please poll me to find out what'. With SPI, this can be done quite easily, e.g. by
defining that the data line must stay high when idle, and have the slave pulse it low briefly ( or
hld it low until the SPI clock is seen) to request attention - this would go to an interrupt line on
the master as well as the SPI port, and the SPI peripheral is only enabled while sending.
In the case of holding low til acknowledged, you wouldn't need the interrupt.
You need to think carefully about the timings to ensure it behaves when they both ends decide to do
something at the same time but this is usually just a case of adding some guard times to guarantee
thet the SPI ports are enabled at the right time and stay in sync.
> > I am working on a Remote LCD display that connects to
> > another board via SPI.
> > The signals available between the boards are
> > SCK,SPO,SPI,+5,GND and 2 bidirectional IO lines.
How "remote" is the LCD ?
Are they 5 cm or 5 km apart ?
Have you thought about setting up a CAN bus ?
Message based and easy to expand to more "nodes"
then two if needed...
|Thanks for your replies.
The boards are about 50mm apart.
I did manage to some some info since the post that describes micro to
micro link using SPI.
Sending the menu should be straight forward as I can have the info
delimited and use escape character
to prevent the flag bytes appearing in the upload packet. The receiver
can then stuff the incoming bytes into
a circular buffer and the main process in the display unit scan the
buffer for flag bytes to delimit the packet start and end.
I suppose if the main loop is made to cycle every 20ms then I can simply
send a poll to the display and return the button status
at the same time.
The main program only needs to make changes if a Select or Escape is
Maybe if only 1 menu at a time is uploaded then the main program "knows"
where the display is navigating and if it is a
screen that returns a value then the value is received in addition to
the button status. (Requires an extra dummy byte sent from master to
read the second byte).
As long as the display and main unit are in synch it should be ok.
POssibly it would be better to extend the protocol so that the
display unit returns key status, current menu number , and the number of
any databytes attached. The master then sends additional dummy bytes to
read the required number of data bytes ?
What do you think ?
Mike Harrison wrote:
> What do you think ?
One of the courses I had long ago had one basic question:
"What is the problem that you are trying to solve?"
Now I know you stated a problem, but it seems to be part of a possible
solution rather than the problem that you are having. Here are some of
1) Why SPI? Asynchronous duplex serial communication would take fewer
lines, and would be much easier to implement.
2) Why have the display board work independently? Do you not have
enough time on the first board to handle the display directly? (If
you're worried about the number of lines: there are 2-3 line solutions
for addressing a character display, and there is a one line solution
for reading four buttons).
In other words: please provide a little more context.
Timothy J. Weber
> I am working on a Remote LCD display that connects to another board via
> The signals available between the boards are SCK,SPO,SPI,+5,GND and 2
> bidirectional IO lines.
> What I want to do is transmit a MENU from the main board to the display
> board. The display board would then
> independently navigate the menu using buttons on the board.
Interesting - I'm doing something very similar, also a separate box that
runs a simple menu-based UI. Some differences from what you're describing:
- Mine uses LED modules right now for across-the-room visibility in
darkness, but the display technology is modular and the overall approach
is compatible with a larger LCD.
- I'm using a simple bus protocol using two asynch serial lines and a
fixed master/slave organization. There's very little protocol other
than the master saying "Target slave number 1" and then sending commands.
- There's one button that always means "Escape/back up", and one rotary
encoder with built-in pushbutton for forward/backward and Enter. So,
just two objects for the user to manipulate.
- I develop the menu in XML, test it on a GUI simulator (on Windows),
then compile it to a compressed binary format and download it to the
menu box's EEPROM, where it executes.
- The main module sends commands like "Execute menu at offset 0," and
then can either poll for changes or ask for continuous updating on
change. It can also interrupt and take over the menu box at any time,
setting display contents and polling raw buttons as needed. The menu
box sends back responses like "User requested action 'recalibrate'" or
"Value 'color' changed to 'purple'." Values can optionally be saved
back to the menu box's EEPROM; if not, they revert to the defaults when
the box is powered up.
- Built-in menu item types include submenus, actions, integers 0-254,
enumerated types, and Boolean yes/no.
I dunno - there are lots more details and I can post the specs if it
would be helpful.
Timothy J. Weber
More... (looser matching)
- Last day of these posts
- In 2005
, 2006 only
- New search...