Matrix Orbital Corp

Hi, MO Folks,

Just got my new LK204-24-USB with insert which works like a charm using LCDC. Whole installation process and setup was a no-brainer!

But I bought this toy as a fun programming hobby. I am using Borland C++ Builder 6 and just downloaded an eval. version of the MarshallSoft serial communication libraries, as recommended elsewhere in these forums.

Question now becomes: Can anyone please send me--or point me to--some sample code using those tools so I don't have to reinvent the wheel?

My goal is to produce a GUI-interfaced general app that will allow me to customize what I display on the LK204. I know, I know: LCDC probably does everything I would want to do. But where is the fun in that?

Many thanks if you can help me here. I am hoping somebody will point me to the "grunt" code for accessing the device, sending it simple commands, etc.

Steve
steve@edmicro.com

P.S. Already my propeller-head friends are drooling over my VFD. Wait 'til I start custom-programming it!

Basically the way the USB devices operate is the same way that serial (com port) devices work. Using the appropriate libraries to access the essential com port is your first step. Since we use a virtual com port, you would use the library to access com port 3 instead of 4, or wherever your USB device is listed as. Talking to our displays is straight forward. The hardest part is gaining access to the port. Send the appropriate bytes to the display and it will respond accordingly. By this I mean if you send the command byte followed by a command, the corresponding action will be performed.

Hi, Miles,

Yes, the VFD is not at all hard to program. Once I figured out how to integrate the MarshallSoft serial comm. library into the Borland IDE, it was pretty smooth sailing.

I can already display anything I want on the VFD. Next I will look at doing some simple animation. I suppose people use while or for loops for this?

Thanks,

Steve
steve@edmicro.com

Animation is tricky, even with "simple" animation. You can use any type of programming style you like. The trick with any type of "changing" screen requires delays. Delays give the display time to "catch up", so to speak. If the delays are to long, you may not be using the display to it's full displaying potential. If the delays are too short you might overflow the buffer. It's a very fine line, too fast or too slow!!

Hi, Miles,

I am interested in your remarks about the difficulties of animation. Let me explain. In some ways my MO VFD display reminds me of the simple DOS screens we programmed in the olden days: direct cursor positioning, not much graphics, fairly simple character output. If that analogy is correct, then "animation" should be a matter of using spaces and characters within loops to give the illusion of animation. Am I correct?

I am an MO owner only for the last 3 days, and so am learning the basics of programming my VFD. My first foray into animation is displayed below in C code. Only 15 lines and not particularly complicated (some lines are preceded by dots to force indentation). The function goes to the given column and row and marches the given text left to right twenty times. A trivial function but perhaps a step in animation:

1. void MO_draw_moving_text(int Col, int Row, char* text)
2. {
3. ...for(int i=1;i<21;i++)
4. ...{
5. ......MO_set_cursor(Col++, Row); // Set cursor position on the display.
6. ......if(i>0)
7. ......{
8. .........MO_move_cursor_left(); // We have to erase the previous
9. .........MO_show_space_char(); // starting character as we animate.
10.......}
11.......MO_show_text(text); // Here we display the desired text.
12.......// The next for loop merely slows everything way down.
13.......for(int j=0;j<100000000;j++); // Just eat up some time.
14....} // end of line 3's for loop
15. } // end function MO_draw_moving_text

(The functions preceded with "MO_" are of course my own "Matrix Orbital" wrappers, i.e., a way of hiding the details of setting Matrix Orbital device values using the MarshallSoft libraries. Their details are unimportant.)

The key "animation" activities lie in the "for" loops at lines 3 and 13. The second "for" loop, at line 13, is easy: it counts from 1 to 100 million just to eat up some time so the animation won't run too quickly. Miles, you advised this, and it works: The animation proceeds smoothly and stately.

The loop at line 3, ending at line 14, keeps moving from one column to the next and redisplaying the text, giving the illusion of movement.

1. Is the model of animation I have proposed here a correct one?
2. Are there other approaches to animation of which I should be aware?

Miles and others, many thanks for any input/assistance.

Steve
steve@edmicro.com

You are correct in your assumption that this particular model is best accessed via direct cursor positioning and it utilizes a very simple character ouput. To be perfectly honest this would probably the way I'd do it, however I'm not a software expert, so this doesn't say much!!!

hi,

Miles wrote:Basically the way the USB devices operate is the same way that serial (com port) devices work. Using the appropriate libraries to access the essential com port is your first step. Since we use a virtual com port, you would use the library to access com port 3 instead of 4, or wherever your USB device is listed as. Talking to our displays is straight forward. The hardest part is gaining access to the port. Send the appropriate bytes to the display and it will respond accordingly. By this I mean if you send the command byte followed by a command, the corresponding action will be performed.

(sounds of grinding in my head).

my LK202-24-USB is plugged in, has a message to the same effect, and is lit. i chase the device manager, and see the matrix orbital LK202-24-USB under the USB tree as COM3 (so far so good, right)?

NOW, is the matter as simple as getting hold of COM3 - (just like i can grab any other COM port) under VC++, and performing write operations to it??

in other words, from my point of view, i should NOT be concerned whether this COM port is virtual, physical, or whatever - it should be available to me under COM3? ...as in just another COM port, like the other (physical) ones i write to?

thanks in advance.

Hi, Sidereal.

As you know from this thread I have my VFD only a week and have been learning to program it. I am using Borland C++ Builder 6 and a 60-day evaluation copy of MarshallSoft's serial communications library, downloaded from http://www.marshallsoft.com. That site has a version for VC++ users as well.

My rig has two com ports, COM 1 and COM 2. On installation Device Manager automatically found my VFD and put it at COM 4, which is fine with me. When I wrote my first program for the VFD, I specified the device was at COM4 at a speed of 19,200 baud, using the simple functions provided by the MarshallSoft library. It took me all of 5 minutes to display "Hello, world" on the VFD. So, yes, your com port for your VFD is a virtual one that acts exactly as a real com port.

I noticed elsewhere in these forums that some guy said he could write to his com port using simple file-opening and file-writing code. But I like the extreme ease of use of the MarshallSoft library. For example,

// All functions starting with "Sio" are MarshallSoft comm. functions.
// Set port.
static int ThePort = COM4; // Yup, com4 in my case.
static int TheBaud = WSC_Baud19200;
SioReset(ThePort,2048,1024);
// Set baud rate, DTR, and RTS
SioBaud(ThePort,TheBaud);
SioDTR(ThePort,'S');
SioRTS(ThePort,'S');
// Send some text to the VFD.
char* text = "Hello, World!";
SioPuts(ThePort,text,strlen(text));

As you can see, it doesn't get much easier than this.

Steve
steve@edmicro.com

Thanks, Steve.

i found a free serial library at codeproject.com:

http://www.codeproject.com/system/serial.asp

...which sounds functionally similar to the library you are evaluating.

i'm still having problems with the serial library (above), and some W32 code posted by Matrix in another post. they both break in different places - one trying to init COM3, and the other establishing a write thread.

this is on w98.

that's all i needed: a human being to tell me that Virtual ports are pretty undistinguishable from other COM ports.

knowing this is the case, i will ultimately get this thing working..

thanks again,

Hi, Sidereal,

I saw Matrix guy Johnny Patino's message and downloaded and examined his C code. I also followed the link you reference above and read Ramon de Klein's excellent treatise on serial communications under Windows.

All I can say is this: for me, life is too short to get that heavily involved in the details of serial communications. Both Patino's and de Klein's stuff frankly gave me a headache. i admire them, but I bought my VFD to program it and not to master the intricacies of serial communications. I did dabble in serial stuff 30 years ago and I have the scars to prove it. But now I am content to use the MarshallSoft library which conceals from me the ugly details of serial comm. and lets me get on with the business of programming my VFD.

Cheers. Hope your COM3 troubles clear up.

Steve
steve@edmicro.com

hi,

Karellin wrote:Hi, Sidereal,

....
I did dabble in serial stuff 30 years ago and I have the scars to prove it.
...

Cheers. Hope your COM3 troubles clear up.

Steve
steve@edmicro.com

yup - 20 years for me - and still struggling with SIOs

post mortem: i'm pretty sure W98 has troubles with SOME uses of virtual serial ports.

i recompiled the w32 code posted on another thread, and it runs on my XP system downstairs.

..only burned about 12 hours on this one. your statement about life being too short applies here.

Take care, Steve.

Hi, Sidereal,

Yes, it did occur to me that Win98 might be causing you some trouble, but I hesitated to say so because I had no firm knowledge of that. All the six boxes in my house are running XP Pro. Since of course I have to do computer support for all my relatives, friends, and neighbors, I try to shoot Win98 wherever it hides and breeds.

Steve
steve@edmicro.com