The first Arduino is not running my own code. To be more specific, I'm working on a 3D printer that driven by an Arduino board, and I want the remote device to be an Android Phone. The 3D printer firmware is definitely not something I wanted to modify without a comprehensive consideration of the whole picture. By the way, there is another reason why I wanted to do that. The LCD control panel is connected to the board with a 20 pin connector. To an ordinary user, switching a plug is far more simpler than installing a custom built firmware. If you think the otherwise is more likely, try to convince an ordinary people to install a better custom built Android OS to his Android phone, and you'll see what I meant.
Ah, knowing the full environment makes a BIG difference.
It is always better to describe the full environment/project when asking for help/comments
to solve a problem in that there may be better/simpler solutions by attacking the problem
in a different way.
I'm assuming the comment about installing a custom built Android OS is sarcasm?
as even modifying the code in the first Arduino wouldn't require that.
Here is why knowing the full environment really matters.
I've seen hints of trying to push the sampled data and control lines over a serial interface.
This method can be very problematic and has synchronization issues because
the 4 bit hd44780 interface has no synchronization information.
When doing this, the receiver has to run a full hd44780 state machine
and can never ever loose any nibble transfer since, if it does, it can get hopelessly
out of sync.
When out of sync there will be no valid LCD information displayed.
I'd be very concerned about keeping sync when using a serial interface and
would not even consider using a wireless link for sending raw hd44780 information,
particularly when using 4 bit mode.
Here is an alternative for providing a "plug and play" remoted LCD display solution
vs modifying the code on the first Arduino
i.e. some sort of board that plugs into the same connector as the existing LCD
and then the original LCD plugs back into the interface board.
Consider processing the hd44780 information and mirroring the LCD display
inside of the interface board rather than pushing the low level information over a serial interface
to the Android APP.
For example, the processor on the interface board with the bluetooth interface looks
at the hd44780 interface pins and then creates an image of the LCD display
in a shadow buffer inside it.
Then periodically, say every 1/4 to half second, it blasts the full LCD shadow buffer
to the Android app over the bluetooth.
This has the potential to do a number of good things:
- The android app does not have to maintain 100% connectivity to the device
- It removes pushing the realtime hd44780 information over a non reliable interface
- It keeps the realtime processing in a processor that is always electrically connected to the hd44780 interface.
- It potentially reduces the traffic over the serial interface.
- It keeps the android app code very simple
- It allows for errors on the communication interface to the Android APP since
if there is an error, it could self recover with the next LCD screen push update.
The first one is a REALLY BIG DEAL. If the low level hd44780 data is remoted over the serial
interface to the app, the APP must see 100% of all the 4 bit transfers.
The app has to be connected when the first arduino starts up and can never loose connectivity
or drop any sampled information.
It has to do this to maintain full 4 bit synchronization.
When the app processes the low level hd44780 information,
it will not be able to just connect in at any time and start displaying the LCD data.
Whereas if the interface board is pushing out LCD screen updates, then the app can
start up and join in at any time to start displaying what is on the LCD, including
the current LCD display.
It does require defining a robust message interface for blasting the LCD push updates.
The message interface must contain some sort of synchronization so
that the receiver can recover from dropped/lost bytes.
It could even be smart enough such that push updates are only done if the screen
has actually changed within the update period.
However, once that is defined, the app will be able to join in or drop out at any time.