serial problem with pcFullDuplexSerial4FC object

stef

Hi

Back again a beginners question.
I'm using the object pcFullDuplexSerial4FC for multi serial connections.
Sending with the command· "· rs232.dec(0,okay1)" is no problem. It is working fine
recieving with following is giving me a strange reaktion.

·repeat
··· rx1 := rs485A1.getc(0)
··· rs232.dec(0,rx1)
··· rs485A1.rxflush(0)
···· waitcnt(LEDDELAY/2 + cnt)··
I'm recieving from a rs485 connection and sending it back again out on the rs232. The problem is that the first charakter I recieve is ok. The second is always not ok. The therth is back again ok.
I give an example.
I send "aaa"
I recieve "97 225 97 225 97 225"
The "97" is· the ascii for a, But what is the 225 comming in the game. If I test with an other charakter it is different values but the same principal.

What am I overlooking??

Stefan

Mike Green

How are you sending the "aaa" to the RS485 input?

I notice that "a" is %01100001. If you change the MSB to 1, you get %11100001 = 225.

If there's a mismatch in bit timing, the last couple of 1 bits could be misinterpreted (11 becomes 011 or 111). Just a thought.

stef

HI

Nice touch Mike.

Im sending it true an other comuter comport who has a rs232/485 converter on it. I'm testing/creating on the propellor a protocol convertor for our machiens. They send on RS485. I'm simulating now with normal computers.

All the com ports are on 8N1 2400 boud. How is it possible to have a bit timing mismatch??

Stefan

agodwin

I have been using pcFullDuplexSerial4FC and while it's very useful I do have some problems that I mean to attack. I'm running 3 115200 bps unidirectional streams.

First and most serious problem was that it takes a little while to buffer a character (due to hub access speed) and it starts this just after it samples the stop bit. This can mean that it misses the following start bit. I did two things to help this - I used 2 stop bits to give it a little more time, and I moved the buffering of the data to occur at the end of the last data bit rather than in the stop bit. This isn't ideal - it can't now check for a framing error (though it didn't before anyway !) and it isn't always possible to send two stop bits.

Next problem is that I sometimes get the RX input stuck at zero. I'm using an RS485 bus and this can happen under some fault conditions and perhaps when the bus is enabled for transmit. On a hardware UART, I would expect a break condition : probably a framing error. The software UART gives me continuous zeros and no error indication.

Finally, I've occasionally seen corruption on the data - usually the data is shifted and the top bit is set. This sounds similar to your problem, but it isn't very reproducible on my setup. I think it's another sampling problem - it's synchronising too early and reading the start bit as the MSB. I suspect that detecting the edge of the stop bit instead of the level would solve both this and the second problem.

I haven't had any time to look at this yet, so I've only done anything about the first, which was a showstopper for me. However, I've built a version of the code that has the CTS/RTS support removed (I didn't need it) in order to make a little space for code changes and I intend to look at it again sometime.

Another unrelated problem I had was that the spin code to flush the receive buffer ran so slowly that more data had arrived before the buffer was flushed ! I altered it to just move the pointers instead.

StefanL38

Hello Stefan,

if I remember it right a timing mismatch can ocur if the constants
_clockmode and _xinfreq are NOT setup properly

CON    
  _clkmode = xtal1 + pll16x
  _xinfreq = 5_000_000

do you get the same results when using FullDuplexSerial for just ONE port ?

best regards

Stefan

Timmoore

agodwin, I have seen the speed problem before though whenever I have seen it I have reproed it with the standard FullDuplexSerial. What I found was if I changed the baud rate slightly to either side I would find a baud rate that always worked. It was dependent on teh other device - some devices dont generate a baud rate exactly at the rate. Try +-5% and +-10%. Hardware uarts sample 16x per bit and average to get over this problem, the software one doesn't do this so if the baud rate is slightly off you get a sampling problem.

hippy

For simple bit-banged serial, sampling half-way through the bits, serial needs to be something like +/-6% out of spec before corruption or errors start to appear and that's quite a lot.

Timmoore

The problem is that because of the way fullduplexserial works - processing send on the same cog means it can be late spotting the start bit, that makes it late sampling bits - after the middle of the bit, if there is an error with the actual baud rate faster than the prop thinks it is, the sampling point moves later in the bit until it falls off the end of the bit into the next bit. You mostly see this error in the MSB since this is the last bit received where this sampling error adds up the most. So most of the time adding +5 or +10 to the baud rate handles this problem.

stef

Hi StefanL38

Yes I checked the settings you mention and they are OK.

I did this morning the test with fullduplexserial object on 1 port and then I get the same result.

Fore alle the others, thanks for the advice but nothing what I do is changing the result. I was thinking it is hardware related to my design Because if the baudrate is not ok vor the recieving it is not ok for the sending. For sending I have no problem.



Stefan

agodwin

Thanks, Tim - I'll experiment with that.

However, although I can see how the sample point might be late, you start with it 1/4 of a bit past the detection point and add 1 bit time to rxcnt on each iteration - you aren't accumulating errors by retiming each succeeding sample from the previous (perhaps delayed) one. So the errors shouldn't be cumulative.

Of course, an actual bit rate error will be cumulative - though crystal-controlled sources shouldn't be anything like 5% off if it's correctly divided. If the data is coming from a micro with insufficient timer resolution to get the proper bit rate, it might be poor.

Post Edited (agodwin) : 10/3/2008 8:44:38 AM GMT

stef

Hi

I checked my hardware design. I'm using a driver ic SN75176. It is a 5V powerd ic, so I put a 1K in serie with output to the inputpin off the propeller and A 10 K pull up to the 3,3V on the driver side.

The last one I'm not sure if it is ok. I picked up the design somewhere but I'm not sure.

Has someone experiance with that driver connected to the propeller or how to connect 5V devices to the 3,3v propeller. I hope my resistercombination is ok.

Stefan

stef

Hi

I 'm getting more and more confused with my serial connection. The problem i discrubed abouv (getting always a wrong charakter after recieving a goed one) is getting more ugly and undiscrible.

I did some testing and it still the same. What I also found was that I can send a lot of charakters (testet with a textfile) without any problem in recieving as long as thier are no to up ietsfollowing charakters that are the same. Ex. If I send ABCDEFG..... it is recieving as ABCDEFG.... But wen I send ABCCCDEFG it is recieving as ABC??DEFG (the ?? are other charakters).



How to explain that?? Has someone already syn that?



Stefan

Cluso99

If my memory is correct, RS232 is quoted as requiring +-1.5%. I had to cater for Apple //c (in an Apple branded modem I designed with a soft UART) which if I remember correctly, was just under 2% out.
UARTs were able to cater for +-48% distortion so I believe not only were they sampling at 16x baud rate, but they were resynchronising on bit transitions. This is simpley not the case with bit-banging as used in the FullDuplexObject.
This is just some background, as it seems there is a timing issue here. Changing the rate +-5-10% is not a solution.

agodwin

I've wondered about resynchronizing, but not convinced it's a great help. There aren't enough guaranteed transitions in normal async data : only the stop/start transition is always present. So while resyncing on a data transition won't hurt, if it's necessary to keep the sampling correct it ain't gonna fly on a character with no transitions, or with them at the ends.

The most useful thing is the averaging that Tim referred to : this gives improved noise rejection by ignoring spikes thatoccur right on the sample point, and similarly by detecting the initial start transition more accurately.

Stef :

That is REALLY weird. No, I haven't seen that problem at all !

agodwin

Tim,

I see that the 4FC code has some tests to avoid polling pins for unused UARTs, by modifying the initial values of txcode, rxcode etc. However, in the copy I have (from the GPS demo), these tests are commented out, so that all the UARTs are polled and presumably the maximum speed does not rise with less channels.

I've tried re-enabling the code and see that the initial poll for the start bit goes from about 2.25us to about 1.25us, even though I'm using 3 of the 4 ports. This seems like a worthwhile improvement, so I'm curious as to why you removed the tests. Is there a downside ?

-adrian