Serial ports

[Raphael]

SCRUB
DECIMAL
0 RAM !


HERE 80 4 + ALLOT CONSTANT RBUFF EEWORD
RBUFF 80 4 + SCI0 RXBUFFER

HERE 80 4 + ALLOT CONSTANT TBUFF EEWORD
TBUFF 80 4 + SCI0 TXBUFFER

HERE 80 4 + ALLOT CONSTANT RBUFF1 EEWORD
RBUFF1 80 4 + SCI1 RXBUFFER

HERE 80 4 + ALLOT CONSTANT TBUFF1 EEWORD
TBUFF1 80 4 + SCI1 TXBUFFER


: GETIT SCI1 RX? @ 0 = IF." NO DATA" ELSE SCI1 RX EMIT THEN ; EEWORD

: PRINT BEGIN GETIT? TERMINAL UNTIL; EEWORD
PRINT

SCI1 is connected to HyperTerminal on (COM 2 of PC) and I type using the keyboard. I can see what I print on NMI term connected via the other (COM1) port.

Any character typed more than twice in HyperTerminal puts in a different symbol on the
NMI term.


Questions:

Does this mean I am trying to do something stupid or I don’t know enough about extended ASCII set and stuff or is it because I haven’t understood what EMIT does or maybe ( hopefully not) that pods cannot handle this ?? Is it a trick on the Hyper Terminal
and that it would not effect other serial devices that send similar continuous characters which are to be read by Pods?

Another general question is, has ISOMAX ( the state structure ) some relationship with what is referred to as SFC ( Sequential Function Charts ) in PLC programming?

[RMDumse]

I am concerned about the IF statement.

SCI1 RX? @ 0 = IF." NO DATA" ELSE

First SCI1 RX? returns a Boolean ready for testing. So if it is false and you return a 0, you @ (fetch) location 0 in the memory map. So if it is true and you return a -1, you @ (fetch) location FFFF in the memory map. I think you want to remove the @ (fetch) there.

Next I see no space between IF and ." in the IF." and then ." NO DATA" emits 6 characters many many times for any one you might get.

As typed here, GETIT in the definition and GETIT? in the word PRINT are two differently spelled words. So I guess this is not an exact copy.

I'd redo the IF like this:

: GETIT SCI1 RX? IF SCI1 RX EMIT THEN ; EEWORD

and see if anything got better.

[Raphael]

I am sorry about the mistakes .....I copied them to MS word and did a spell check, creating shifts except for the '@'.

Here is the rite one.

SCRUB
DECIMAL
0 RAM !


HERE 80 4 + ALLOT CONSTANT RBUFF EEWORD
RBUFF 80 4 + SCI0 RXBUFFER

HERE 80 4 + ALLOT CONSTANT TBUFF EEWORD
TBUFF 80 4 + SCI0 TXBUFFER

HERE 80 4 + ALLOT CONSTANT RBUFF1 EEWORD
RBUFF1 80 4 + SCI1 RXBUFFER

HERE 80 4 + ALLOT CONSTANT TBUFF1 EEWORD
TBUFF1 80 4 + SCI1 TXBUFFER


: GETIT SCI1 RX? IF SCI1 RX EMIT THEN ; EEWORD

: PRINT BEGIN GETIT ?TERMINAL UNTIL ; EEWORD
PRINT

I think this hasn't resolved my problem. It could still be at my end, would really appreciate if you could point out where ?? I would like to know how Extended Ascii ( though i dont know much about them) is handled in PODS.

*** One general question I have is whether ISOMAX has something in commmon with SFC ( Sequential Function Charts ) in PLC programming ?

[RMDumse]

Why not make things as simple as possible? Consider trying this


SCRUB

: GETIT SCI1 RX EMIT ;

GETIT


Without the buffering, or EEWORDing, or looping etc... when you do the SCI1 RX the system will hang until it gets a character.

The EMIT will cause the character to appear on SCI0. EMIT is defined as SCI0 TX .

So this simple code will wait for one character on SCI1 and spit it out on SCI0. (No response back on SCI1 by the way.)

This code, is one that can be called repeatedly, since it tests to see if there is a character there or not.


SCRUB

: GETIT SCI1 RX? IF SCI1 RX EMIT THEN ;
: PRINT BEGIN GETIT ?TERMINAL UNTIL ;
PRINT


This one you down load on SCI0, then switch to SCI1 to send a character.

Hopefully, you have two computers, or two serial channels each with an NMITerm (or other terminal program) open at a time. Otherwise, what you type on SCI1 will be sent to SCI0 so fast, you'll never see it.

Once these are working, you can add back in the buffers, etc.

I would like to know how Extended Ascii ( though i dont know much about them) is handled in PODS.

I don't really know what you are asking. The Pod software receives 8 bits if it can, and transmits 8 bits. The only special character is back space (08 iirc) which when calling EXPECT will alow a back up in the character buffer.

Otherwise, the Pod's do nothing special with the character set I can think of.


*** One general question I have is whether ISOMAX has something in commmon with SFC ( Sequential Function Charts ) in PLC programming ?

Again, difficult for me to say, because I don' t know what SFC ( Sequential Function Charts ) in PLC programming are. PLC and IsoMax(TM) have a common root, in that both have an outer scan loop. I just looked up some SFC's and they show this outer loop. They seem to use contact closures somewhat parallel to how we use CONDITION - CAUSES qualifiers. Beyond that, I really am not familiar enough with SFC's to say.

[Raphael]

I think I haven't explained well enough. I have attached a screen shot of the experiment I did with the code.

Thanking you for all the support, time and patience

[RMDumse]

Oh oh, now I get it. Okay, this has nothing to do with the 'Pod's at all. What you see there are two different fonts, and the problem of them not matching is entirely on the PC side of things.

If you could make the Hyperterm and the NMITerm programs use the same fonts, then the problems you see would go away, if I'm understanding what's going on. The extended ASCII fonts can vary from font to font. Since both programs have different fonts chosen, the extended portions don't match. In NMITerm you have the Option, Font, settings and can choose different character sets. You can probably do the same thing with Hyperterm, or, why don't you use two copies of NMITerm, or two of Hyperterm, so you can see what happens when you're sure you've got two with the same font set.

But what I saw in your screen capture looked to me like two different font sets, and that's strictly a PC issue, not at all associated with the 'Pod, where there are only numbers, and no such thing as a display font set.


Well, hang on, there's something else there. So you are sending one two or three characters in a row. The third character looks garbled. Is that the problem?

Let me ask this. If you type the three characters more slowly, does this problem show up as well? or only if you type them fast???

[Raphael]

Hi

The suggestion you gave me were very very useful. I dont seem to have a problem with Nmi-Nmi but there is something betwen Nmi-Hyperterminal and Hyperterminal-Hyperterminal which means that the PODS are quite safe..

-*** The third consecutive character typed in comes out as garbled.**

I typed them slow and fast, that doesn't make a difference ( I dont think its a baud rate issue), I have captured the screen shots and have attached them with this mail.

So can I conclude that any serial device connected would have no problems with the Pods, even though their initial caliberations are done with hyperterminal.

Thanks for all the help . I tried the font settings but I dont think this has something to do with font settings.. All your thoughts on this are most welcome.


-- Just now I figured what was wrong with hyper to hyper. I turned on the 'Force incoming data to 7-bit ASCII' option and could get away with the hyper- hyper problem. I am still unable to find such an option or an equivalent in NMI term.

Once again thanking you

[RMDumse]

Hi So can I conclude that any serial device connected would have no problems with the Pods, even though their initial caliberations are done with hyperterminal.

Well, not completely certain. Maybe there's something happening in that 8th bit.

I tell you, there's no reason we shouldn't be able to see what's going on though. There's no reason we can't print the value as well as EMIT the character, at least at low speed hand typed use.



: GETIT SCI1 RX? IF CR SCI1 RX DUP EMIT . THEN ;
: PRINT BEGIN GETIT ?TERMINAL UNTIL ;
PRINT


This should put each character on a new line, followed by the value printed out. (I might find HEX easiest to follow, but printing in DECIMAL might appeal to others, be sure to know which number base you are using with the " . " to interpret results correctly.

-- Just now I figured what was wrong with hyper to hyper. I turned on the 'Force incoming data to 7-bit ASCII' option and could get away with the hyper- hyper problem. I am still unable to find such an option or an equivalent in NMI term.

Well, there isn't a built in function in NMITerm that I know of, but you can always trim the bit at the 'Pod if you like. For instance:


HEX
: GETIT SCI1 RX? IF CR SCI1 RX 7F AND DUP EMIT . THEN ;
: PRINT BEGIN GETIT ?TERMINAL UNTIL ;
PRINT


This way, you'd know if the extra bit was being sent to the 'Pod and echoed (a PC Hyperterm problem) or was being generated from the 'Pod by overflow framing error, or such. Or, you could even turn on a light when the 'Pod receives a high bit character to more easily visualize if the extended ASCII character is arriving as such to the 'Pod, or being generated as it leaves the 'Pod.


HEX
: GETIT SCI1 RX? IF CR SCI1 RX DUP 80 AND REDLED SET 7F AND DUP EMIT . THEN ;
: PRINT BEGIN GETIT ?TERMINAL UNTIL ;
PRINT

[Raphael]

Hi
Sorry for being late on the response !!!

That was a perfect test...I could see the character and the Hex values..
For eg.
A41
A41
ÁC1
B42
B42
ÂC2 - This was the result...

With triming the last bit, there was no problem with the third consecutive character entry.

Also I was getting a REDLED glow for the third consecutive character entry.

I have attached the test results.

- I am not quite sure as to what to conclude...

Once again thanking you for all the help and support

Regards

[RMDumse]

I now have an IsoPod(TM) set up so I can try what you are trying. (IsoPodX(TM) actually, but it's what I had on hand.)

I started out just testing a little. I hooked my expansion chassis to my laptop go get my native COM1, then NMITerm on COM1 via serial cable to the board, to be sure it worked, which it did. I hooked my USB-to-Serial cable to my laptop USB to the board and it came up with NMITerm on COM4, which did work. Now I replaced the cable on my COM1 with a split cable wired to J2 of the IsoPodX(TM), which is SCI1.

Now I can send system commands to the board on COM4 via SCI0 or the system port, and send characters to the board on COM1 via SCI1. Here's the first test. Into COM4:


IsoMax V0.82
DECIMAL OK
9600 SCI1 BAUD OK
HEX OK
41 EMIT A OK ( prove A comes out SCI0 with EMIT
41 SCI0 TX A OK ( prove A comes out SCI0 with TX
41 SCI1 TX OK ( prove A comes out SCI1 with TX
42 SCI1 TX OK
43 SCI1 TX OK


And here is what I saw on the COM1 NMITerm


ABC


Good. That looks right.

(One thing different I noticed that I didn't see in your code was the specific setting of the baud rate for SCI1. I wondered if the trouble might be there.)

So then I tried the code we'd come up with:


: GETIT SCI1 RX? IF CR SCI1 RX DUP EMIT . THEN ; OK
: PRINT BEGIN GETIT ?TERMINAL UNTIL ; OK
OK
OK
PRINT
A41
B42
C43
C43
C43
C43
C43
C43
C43
C43
C43 OK
OK


Now that looked good too. So I downloaded Hyperterm to my laptop, and tried it:


PRINT
A41
B42
C43
C43
ÃC3
C43
ÃC3
C43
ÃC3
C43
ÃC3
C43
ÃC3


There's the 8th bit problem.

I closed Hyperterm and reopened NMITerm, and the problem was gone.

So to me, since NMITerm to NMITerm works, and Hyperterm to NMITerm doesn't work, it seems it is a Hyperterm problem of some sort. Since Hyperterm isn't my product, do you suppose you might take up your problem with them? (I hate to recommend that, because I doubt they will be able to respond.) Or how can I convince you the problem is not something I can fix?

[RMDumse]

I searched around and found our old MAXTERM DOS serial program and ran it. Same results as with NMITerm:

A41
A41
A41
A41
A41
A41
A41
A41
B42
B42
B42
B42
B42
B42
B42
B42
C43
C43
C43
C43
C43
C43
C43
C43
C43


I don't think this is a problem NMI has any control over. Do you have to use Hyperterm? or can you use something else just as well?

[Raphael]

Thanks a lot for all the help and support and I am totally convinced that its not with 'PODS, it could just be another PC world bug.

Thanking you once again for all your time and patience.