serrxd problems - 28X1 internal resonator

[MORA99]

I am trying to readin 6bytes using serrxd with a qualifyer.

It is almost working, but I have to send the data 2 times before anything happens, and the last few bits are wrong.

I am using AiTerm to send the data "raw".
%01110111 %11111111 %00000000 %11111111 %00000000 %11111111 %00000000 CR LF

tried without CR LF too.

I am using a serial port monitor to see what is sent, and the AiTerm sends the same data each time, so its not some termination thats missing.



My code
<code><pre><font size=2 face='Courier'>
for b10 = 0 to 10
sertxd(&quot;LOADING ...&quot;,#b10,13,10)
toggle 2
pause 1000
next

disconnect



readserial:
do
;12leds &#225; 4 bits = 48bits / 8 = 6bytes

SERRXD [5000,timedout],(119),b1,b2,b3,b4,b5,b6
toggle 2

b0=b1
sertxd(&quot;LED 1 = &quot;,#bit7,#bit6,#bit5,#bit4,13,10)
sertxd(&quot;LED 2 = &quot;,#bit3,#bit2,#bit1,#bit0,13,10)

b0=b2
sertxd(&quot;LED 3 = &quot;,#bit7,#bit6,#bit5,#bit4,13,10)
sertxd(&quot;LED 4 = &quot;,#bit3,#bit2,#bit1,#bit0,13,10)

b0=b3
sertxd(&quot;LED 5 = &quot;,#bit7,#bit6,#bit5,#bit4,13,10)
sertxd(&quot;LED 6 = &quot;,#bit3,#bit2,#bit1,#bit0,13,10)

b0=b4
sertxd(&quot;LED 7 = &quot;,#bit7,#bit6,#bit5,#bit4,13,10)
sertxd(&quot;LED 8 = &quot;,#bit3,#bit2,#bit1,#bit0,13,10)

b0=b5
sertxd(&quot;LED 9 = &quot;,#bit7,#bit6,#bit5,#bit4,13,10)
sertxd(&quot;LED 10 = &quot;,#bit3,#bit2,#bit1,#bit0,13,10)

b0=b6
sertxd(&quot;LED 11 = &quot;,#bit7,#bit6,#bit5,#bit4,13,10)
sertxd(&quot;LED 12 = &quot;,#bit3,#bit2,#bit1,#bit0,13,10)
loop






timedout:

for b10=0 to 20
toggle 2
pause 100
next

GOTO readserial
</font></pre></code>


Log from AiTerm
<code><pre><font size=2 face='Courier'>
(Loading...)
LED 1 = 1111
LED 2 = 1111
LED 3 = 1000
LED 4 = 0000
LED 5 = 0000
LED 6 = 0000
LED 7 = 1111
LED 8 = 1111
LED 9 = 1000
LED 10 = 0000
LED 11 = 0100
LED 12 = 0011
</font></pre></code>

So already at the second byte theres wrong bits.

Any ideas ?



Edited by - MORA99 on 10/07/2007 01:18:22

 

[hippy]

You don't need the CR or LF terminator, so leave those out.

If it's a timing issue, then try sending each byte separately rather than as a back-to-back sequence. Enter %01110111, click &quot;#&quot; button, enter %11111111, click &quot;#&quot; etc. Try not using the same value more than once as that may show up what's happening better.

You could drop to a simpler ...<code><pre><font size=2 face='Courier'>Do
SerRxd [5000,timedout],(&quot;0&quot,b1,b2,b3,b4,b5,b6
SerTxd (&quot;RXD=0&quot;,b1,b2,b3,b4,b5,b6,CR,LF)
Loop </font></pre></code> un-tick &quot;Send Whole Line&quot; and just type in 0123456 and see what that throws back.

You can also try that from the Programming Editor terminal; type 0, press send, type 1 press send etc. That will take any possible bugs from AiTerm out of the equation.

I'd also add an extra SERTXD in 'timedout:' so you'll know if a timeout is occuring.

Edited by - hippy on 10/07/2007 16:34:51

 

[MORA99]

Thanks for the timing point.

It looks like its a timing problem.

The 0123456 test works fine with send whole lines off, so theres a delay between each, but not with all at once.

So I have to make a seperate serial link, since serrxd cant work at other baudrate I think.
But its ok, then I can get background recieve instead.

 

[hippy]

That's quite a serious SERRXD drawback if it is the case, and I'm a bit surprised because SERIN at 4800 baud works well ... or did I believe, I haven't tested it on a 28X1. There's 208uS of stop bit for the PICAXE to take the last byte, store it and be ready for the next. having sampled half-way through the bits, that should give 312uS and I'd have thought that plenty.

It would be interesting to hear Technical's take on this - limitation, bug, whatever.

One trick would be to set your PC up to send two stop bits, giving it an extra 208uS of processing time, but that could cause problems on receive. AiTerm doesn't handle allow stop bits or parity ... yet.

 

[MORA99]

It is just wierd how it works every 2nd time.
With a qualifier, I would think it has to find that and then 6 bytes to trigger ?

So it should be random that it would work, not every 2 times (with error).

I am trying to make it work with a 210ohm resistor to the breadboard adapter and a digital out/in pin now, but not going well.

The serial cable is somewhat long too, maybe that is causing problems, its 1meter usb extension, then the usb2serial adapter, then the regular serial cable.

So about 2meters of usb, and 3meters of serial, was actually planning on 2more meters of usb if this worked, anyone tried to extend the usb adapter 3meters ?
-Maybe its better to extend at the serial end ?

Edited by - MORA99 on 10/07/2007 20:03:40

 

[papaof2]

USB extenders are not usually a problem.

Serial can run over unshielded cable for 25-50 feet in an electrically quiet environment. Shielded cable can work for hundreds of feet, regardless of environment.

John

 

[MORA99]

Just saw the other serin problem with a 281, so wanted to try at 8mhz.

Gives same error, here send whole lines, then one char at a time, then whole lines again.

RXD=01&#171;99&#187;&#171;99&#187;&#171;9A&#187;M&#171;F3&#187;
RXD=0123456
RXD=01&#171;99&#187;&#171;99&#187;&#171;9A&#187;M&#171;F3&#187;

 

[Technical]

We'll look into this, multiple back to back bytes may be too fast for the current firmware. The 28X1 does have to do more tasks than the older X parts, such as checking for timeouts. The simplest way to slow bytes down is just for the transmitting device to leave a tiny delay between bytes.

The Programming Editor Serial Terminal&gt;Options menu has an option to do just this, adding 5ms between each byte sent. You may want to try this option on your setup.

 

[MORA99]

The 5ms option works, and when its disabled I get garbled chars back.

I will have to see what the lowest pause that works is, the chip is running a multiplexing too, so it cant spare much time reading the new serial.

Will probaly need to use the hardware serial on another pin instead.