Matrix Orbital Corp

Hello everyone, I

Hello...

The MX series is not a stand alone device and will need some type of controller to perform the necessary functions. LCDC needs to be running as the LCD connot be programmed to adjust specific tasks. LCDC is a convenient piece of software that is user friendly. You can control the device via a microcontroller as the MX series can communicate via Serial TTL levels. I hope I answered all your questions and if I haven't, feel free to post!!!

I was pretty sure what you said was the case but it never hurts to ask. Thanks for the fast reply, I'm ording one now. More posts to follow.
Yuriy

Glad we can help!

My MX412 will be here on Friday and I wanted to pester you some more before it gets here. You mentioned

Yurly wrote...
" The device communication is via USB so if I wanted to develop a microcontroller interface I would need to utilize the USB on-the-go spec? "

Not unless you choose this communication method. The display is capable of TTL, or transistor to transistor logic which is 5 volts. You can simply connect 1 I/O of the microcontroller to the display and use serial communication type commands to operate the display.

My real concern is the PIC16F877A firmware. I will be programming a PIC18F8720 to control the MX4 as the LCDC software would, in a scaled down way, in effect replacing the PC communications. I have a phase change evaporator attached to my PC CPU that has to reach a user defined temperature (-30 C) before sending the start signal to the PC. It will also have to monitor the CPU temp probe for low temp warning which will also be user definable, in addition to a few other tasks. I will also be using LCDC and a custom plug-in once the PC is started. Using the USB on-the-go specification will allow me to plug the MX4 into my custom controller board which will itself be plugged into the PC. Without having some communications protocol or command set I can

Thought I should jump in at this point. There is a 2x4 header in the middle of the MX series. These are direct access to the TTL signals between the PIC and the FTDI chip. It also has +5/GND for you too.

Probably the easiest way to what your looking for would be to ignore our USB interface and create a device that has another FTDI chip that will be linked to your PIC controller. Under normal circumstances your PIC would simply relay the signals to/from the TTL pins on the display. But when the PC is off, then your PIC could generate the commands required to run our display. Sort of a man-in-the-middle setup. Your PIC device could also throw in commands as long as it was careful to not interrupt the commands comming from the PC. I'd ditch the USB on-the-go spec, it sounds like more pain than it is worth.

Our displays are quite dumb You will need to do the reading of the temp probes via the 1-wire interface yourself, and control the GPOs in response to the temperature.

Just one other thing to clear up: the GPOs are OUTPUT ONLY. They have never been designed to be inputs under ANY circumstance. If you need inputs try the DS2408 part. It's a 1-wire part with 8 pins of GPIO. LCDC won't know what to make of it, but your software could easily use it.

Anything else?

Paradigm

The 2x4 header is a Godsend and sheer stroke of genius, thank you for pointing it out. UPS delivers the display this Friday and I am doing some rough coding. The new information you provided does simplify things, always remember (KISS-keep it simple stupid). I will be using FTDIs FT2232C for the bridge in the manner you described, very good idea. No problem with the Dallas 1-Wire code, I have additional devices that utilize the protocol. I take it fan PWM will have to remain at 100% until the PC is started and running LCDC? Thanks all, time to fire up the BitScope logic analyzer.

Rob