SCI0 baud rate

[gtiani]

I am getting many data errors while using SCI0 in a real (somewhat noisy) system. Changing to a slightly lower baud rate solves the problem. However, every time I type SCRUB and re-boot, the baud rate returns to 115,200 baud.
Is there some way to change the baud rate and save it so that the baud rate does not default to 115,200 baud after SCRUB and re-boot.
It's a nuisance to have to keep changing NMIterm between the two baud rates.
Thank you,
Gary

[Dave]

Hi Gary, think we may have a solution, but may take a bit. We'll let you know soon.

[gtiani]

I'm getting a lot of serial port errors when I run SCI0 at 115,200 baud. I thought noise might be the problem. However, if i insert a very small delay between characters (10 0 DO LOOP), everything starts working fine. When I look at the signal with a scope, it looks like I'm increasing the stop-bit length by about an extra bit. Is it possible to change SCI0 to use 2 stop-bits rather than 1?
Also, can you verify that SCI0 TX? works properly at 115,200 baud? I always get the number 21 returned from TX? no matter how fast I send characters to SCI0.
Thank you,
Gary

[gtiani]

Another note on this problem:
If I connect pin 2 (serial data out) to pin 1 (data carrier detect), the serial port works fine at 115,200 baud. I realize that you do not use pin 1, but connecting pin 1 & 2 together seems to allow data to enter NMIterm without errors. This only works when I am using NMIterm on my laptop computer. Our real system does not use data-carier-detect so this is not a good fix.
If you have any ideas on this subject, I could really use your help. I don't think toggling between 115,200 baud and 38,400 baud is really a fix. The default baud rate needs to work or communication with the ServoPod after a Scrub is not possible. I have to try several times before a getting successful download. This makes programming the ServoPod very difficult.
I really need your help on this problem. If the 115,200 baud rate can not work, then I need some firmware that uses 38,400 baud.
Thank you,
Gary Tiani

[gtiani]

I finally got the 115,200 baud rate working on all of our machines in both noisy and quiet areas. I'm still not sure why it works. But, here is the solution:
Define a new emit with a wait for ready part (even though the original emit already has such a check). Then, store the CFA of the new emit in the UEMIT vector.
: EMIT-NEW BEGIN SCI0 TX? UNTIL SCI0 TX ; EEWORD
: SET-EMIT-NEW ['] EMIT-NEW CFA UEMIT ! ; EEWORD
SET-EMIT-NEW \ new emit to avoid errors at 115,200 baud

I also increased the buffer size for extra safety, but that was not really needed.

If anyone has any idea why the EMIT-NEW word should work so much better than the original EMIT word, I would really like to hear about it. Even though I have a solution, I would like to understand why it works.
I wonder if this is somehow related to a background task happening after an SCI0 but before TX? and causing an incorrect value.
Thanks,
Gary

[RMDumse]

There are two ends to every serial cable. I have it in mind one end is at our ServoPod(TM) but I don't know what is at the other end of your cable. I think most of the problems are coming there. In otherwords, slowing down EMIT sounds like you are giving the other system a chance to get the character, and it can't take them as fast as the ServoPod(TM) can send them.

You mention background task timing. Are you transmitting from both the foreground and background at the same time? Are you using buffers for both transmit and receive?

These answers might shed some more light on what is going on.

[gtiani]

One end is connected to the ServoPod and the other end to a laptop computer running NMIterm. I am using both TX and RX buffers of adaquate size (I've tried up to 100 which is more the one line of data). The error often shows itself within a few characters. So, I'm sure the buffers are not the issue. I am printing from both the background and foreground. However, I disabled all background tasks and saw no difference. The foreground printing is for diagnostics only.

I agree that the problem might be on the laptop side. However, it seems very odd that checking for transmit buffer empty solves the problem since EMIT does the same check internally (I hope). The delay introduced by the tx-empty check is much less than the minimum delay needed by using a simple do-loop. So, I think the tx-empty check is doing more than just delaying. It also seems very odd that connecting pin-1 to pin-2 (data-carrier-detect to transmit-data) also solves the problem. Does NMIterm use data-carrier-detect?

This problem only shows itself when the ServoPod and laptop are near some motor drivers and X-ray tanks. So, it is probably somehow related to noise. Although, I don't see any noise when I look with a scope.

NMIterm crashes nearly everytime the error occures. If I use Hyperterminal, I can see the missing charaters but Hyperterminal keeps running. So, it does look like NMIterm has a bug that shows itself whenever a character error occurs. It made debugging a little difficult since I had to keep closing and re-starting NMIterm. But since NMIterm is so much better than Hyperterminal, I prefer using NMIterm. Since I put in the extra tx-buffer empty check, I have never seen NMIterm crash.

Since I have a suitable fix for this problem at this time, this question is purely for understanding purposes.

Have other customers had similar problems with 115,200 baud or am I the only one? If I'm the only one, maybe I'll try a lead shield in case some X-rays are reaching the ServoPod.
Thanks
Gary

[RMDumse]

To the best of my knowlege, you're the only one having troubles with 115200. Or at least this type of trouble.

Just in case someone else hasn't been through it with you yet, the ServoPod(TM) side has only RX and TX lines. The PC side will have all the standard comm lines.

Your comment about DCD driven solves it makes me wonder if the problem are these other handshaking signals causing problems.

Generally, when you have this situation with one side with hand shaking signals and the other side without, you want to wrap back the handshaking inputs to outputs, so they don't cause noise problems. So you can hook DTR (Pin4) to DSR (6) + DCD (1), and separately RTS (7) to CTS (8). And of course, you also have to have a ground pin at the ServoPod(TM) to the signal ground (5)

Because the DTR is used as a remote reset in the 'Pod's line, DTR is not also jumpered to DSR and DCD on the ServoPod(TM) itself. The RTS-CTS jumper is there on the ServoPod(TM). Perhaps you could try to run a jumper on the bottom of the ServoPod(TM) DB9 Pins 4-6-1 and the problem may go away.

This site might help explain the idea.
http://www.lammertbies.nl/comm/cable/RS-232.html

You have control of the levels of DTR and RTS from NMITerm, see the help menu.

Let us know.