next topic »

[Reply #15 on:]

I don't think comparing installing a new firmware in an Arduino with installing a custom OS in an Android is really that fair. But ok. I don't know all the details of your application, so I am going at it blindly here, I admit.

So, you want to build an interface that allows an Android phone to control a 3D printer, correct? I assume that 3D printer is being controlled by a computer, mostly like through a serial port? So why didn't you just go with that? Are you sure there aren't commands already to get the same statuses that are displayed on the LCD?

What you are suggesting is definitely possible and I am not trying to suggest otherwise. And I am not criticizing your project at all. I just think there may be simpler ways and if I could suggest something to make it simpler, that is my goal. Again, I don't know all of the details.

[Reply #16 on:]

The 3D printer does have serial port interface.  However, the author of the firmware didn't have them probably documented.  I did roughly dig into the source code to figure out what really is going.  The serial communication is on packet base, each packet is safeguarded by a CRC check code, ... ...  Unfortunately, some usefully functionality are only available via the LCD control panel.  I do plan to modify the source code.  However, it must be done after I thoroughly figure out the whole thing, which would take me quite some time without a proper documentation.

I realize that hacking the LCD control panel is more difficult and less flexible than modifying the firmware source code.   Maybe... I'm doing it just because I don't how to do it (coz' the other option is simple to me).

[Reply #17 on:]

Maybe... I'm doing it just because I don't how to do it (coz' the other option is simple to me).

Nothing wrong with that. Best way to learn. Well, you know you need to monitor 6 pins. I would set an interrupt on EN since that is the clocking pulse. In the interrupt, check the state of RS which would tell you whether it is a register or data command being sent. Then grab then the two nibbles and combine them.

The sequence will always be to set the RS line, put data on the data lines, and clock EN HIGH then LOW.  So the data should always be there on the falling edge of EN. So, on the falling edge of EN, check the RS line, and capture the nibble. Set a flag to record whether the nibble is a register or data. Use global variables for these. Then on the second EN interrupt, grab the second nibble and reset the state machine.

[Reply #18 on:]

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.

--- bill

[Reply #19 on:]

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

Thanks for pointing it out, and my sincere apology to Retroplayer.  Being sarcastic is a terrible habit that I  picked up from the programming forums, which I'm trying real hard to get rid of.

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

Finally, I successfully resembled the text from the output to the LCD display  ( I wired something wrong, and had been stuck there for quite a while, anyway... ).  I can now isolate the register and the data commands, and their corresponding code.  I'm trying to program my Arduino to process the LCD output for mirroring the LCD display.  Unfortunately, I couldn't find the documentation of the register commands.  Though it is possible for me to obtain the information in a less civilized way (reading the LCD library source code), it is always easier to do it with the documentation.

Do you know where can I find the documentation of the register commands?

Any information would be greatly appreciated.

Gary

[Reply #20 on:]

They are all in the datasheet for the controller (HD44780?)

[Reply #21 on:]

Opps... how can I miss something that obvious?  Thanks .

[Reply #22 on:]

Do you know where can I find the documentation of the register commands?

They are all in the datasheet for the controller (HD44780?)

The structure of that command set is a bit easier to understand if you keep the following in mind.

In analyzing the instructions:
-- You should ignore the two left columns since they deal with the control signals RS and R/W and not the instructions themselves.
-- The last instruction 'Read busy flag & address' should also be ignored (for the time being) since it deals with reading stuff from the display.
-- You now have eight instructions left and they are identified by the location of the highest bit that is logic '1'.

   For example:
-- The 'Cursor or display shift' instruction has logic '0' for DB7, DB6, and DB5
-- The highest bit that is logic '1' is DB4.  This bit identifies the instruction but has no other significance.
-- The entry in the DB3 column is S/C and the description of what this controls is at the bottom of the table (usually on the next page).
-- The entry in the DB2 column is R/L and the description of what this controls is also at the bottom of the table.
-- The entries in the DB1 and DB0 columns are dashes and those bits are ignored by the LCD controller.

The resulting binary number is 'bit mapped' which means that it's hexadecimal (or decimal) value has no meaning.  If you use the hex value in your program, which you must do for some compilers, you really should put the binary value in a comment.

Don

[Reply #23 on:]

I have successfully resembled the LCD output locally in my Arduino, and mirrored the LCD output via serial.  Everything works fine, great ^^.

Now, I want to program my Arduino to control the buttons on the LCD panel.  Here is the circuit board of the LCD panel,


Originally, I thought it should be an easy task.  However, when I looked into the circuit of the LCD panel buttons, I saw something funny.  The signal corresponds to the off state of the buttons is HIGH.  Anyway, I tried to replace the switches with my Arduino output pins, and here is what I have done
.

Though it works, I have a very bad feeling about my rough design.  First, I'm shorting an input pin of the first Arduino to an output pin on my Arduino. Am I going to damage anything like this?  Second, the off state of the buttons is HIGH.  Before my Arduino can set its output pin HIGH during setup(), my Arduino is probably pressing buttons randomly.

Are these two issues going to be a problem?  If so, how can they be solved?

Gary

[Reply #24 on:]

Use a transistor to replace the switches. Much more reliable.