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 
returned.

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:

>On Fri, 14 Oct 2005 12:20:57 +1000, you wrote:
>
>  
>
>>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 
>>board).
>>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.
>>    
>>
>
>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. 
>
>
>
>  
>
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist