Problem with UART between 30F5015 and 16F946

[stoyanoff]

Greetings! I connected PIN 33(PIN F3) of 30F5015 to PIN 62(PIN C7) of 16F946 and pin 34 of 30F5015 to PIN 61 of 16F946. I have 4k7 pull-ups on both lines.
Here is my code:
Master:

[Ttelmah]

What crystal do you have on the DsPIC?. 10MHz?.
Have you done a simple 'flash an LED' test, and verified that both chips are running at the speed you want?.

Best Wishes

[stoyanoff]

Yes! The crystal on 30F5015 is 10MHz and on 16F946 is 20MHz! I can run the test, but I think the oscillator's frequencies are fine, because both controller work excellent independently.

[temtronic]

hmm...

#use delay(clock=80 000 000)


I don't like the spaces, maybe the compiler doesn't either ?

hth
jay

[stoyanoff]

The one crystal was demaged! Thanks!
May I ask another question?? How could I increase the accuracity of the transmition to ensure the reciever has correct data?

[temtronic]

comments..

1) add a small delay to the 'transmit' program between sending characters. this allows the 'receiver' program time to work...

2) use an ISR for 'receive' program. look at the CCS example ex_sisr.c. using it I can get very reliable 115K200 data transfers.

3)use a crystal that's a 'binary' cut. xtals like 2.457600,8.192, etc. are 'binary'.they are divided by 2, so no remainders giving you odd frequencies like 9601.3 baud when you want 9600.

serial transfers require less than 3% difference in speeds to be accurate.if the transmit is 'high' by 2%, and the receiver is 'low' by 2%, the difference is 4% ,so you'll get errors even though they appear to be in 'spec' of <3% each.

create a simple program to send the character 'U'( 0x55) continuously.you should get a square wave.check with a scope to verify the pulse width is correct for the baudrate you're running.

buy/use higher quality crystals and osc. caps.again verify the frequency but be careful of 'loading'(shifting) the frequency.

use proper board layout(as per uChip specs) and clean the board.

be sure the power supply is well filtered and within spec.

hth
jay

[Ttelmah]

and (of course), design a packet that contains checks and recovery.

You can (for instance), send Shannon encoded data, and lose any one bit and still recover it, and detect 2 bit errors. Big advantage is that 50% extra transmission gives recovery without having to take the time to request re-transmission. Combine with a checksum, and then you can detect if you haven't reconstructed the data fully, and if not, then ask for retransmission or throw away this packet, depending on the nature of the data.

Best Wishes

[stoyanoff]

Is there example for this?!
Thanks!

[Ttelmah]

Correct to Reed-Solomon coding. My internal data transmission is not error
correcting.....
(I always tend to confuse names).

As an online posted freebie. No.

Systems like TCP/IP use the checksum, and request retransmission approach. So all you have to do is make the packet this sends using self correcting data. The encoding is easy just using a lookup table. For decoding, look at 'syndrome decoding'.

The approach as a whole, is what is used in things like DVD players. It rejects the packet if it can't correct it. The more parity bits you include, the more can be recovered, but the more extra data has to be transmitted.

I've done really fast systems in FPGA's, and slower ones in PIC's, but they were all very commercial.

Best Wishes

[stoyanoff]

Isn't it a better idea to use extra pins? Like CS to ensure the sequence start moment?

[temtronic]

Serial communications using a hardware UART is very, very reliable when used with an ISR and buffer (ie: ex_sisr.c). It's also 'selfsyncing' so doesn't require a pin to 'flag' incoming data.
Providing the hardware is 'robust' (proper signal levels, grounding, etc.) your PICs should run forever at 9600 baud.
I've done 1megabaud to a Vinculum just to prove to myself it was possible and had no errors. I've also done 24baud using a software UART without any data loss.
However the faster you go, the more the 'details' (wiring, logic levels, traces,etc.) can become an 'issue'.

hth
jay

[Ttelmah]

It does depend massively on the environment.

Wired RS232 over short distances, should give 99.999% reliability very easily.
Go longer distances with something like RS485, and you can still get 99.99% reliability over km distances.
If you are in a noisy environment, provided the link turn-round is short, then simple checksum systems with an acknowledge, are easy to program, and can bring reliability up to 99.99999% even then.
Where corrections and checksumming are used together it is in complex environments with long turn round, or even with no ability to turn round at all. If after correction, the checksum is still bad, you have to apply an error interpolation algorithm, or simply throw the block.
On many occasions if the data repeat time is short losing one packet won't matter at all, provided you _know_ it is bad.

It depends totally on what the requirements are, and the communication medium, as well as the environment involved.

As an example, I send some instrumentation data through a one way radio link which crosses a high power radar. The radar repeats at about 10 second intervals. When the beam crosses the receiver, all reception is lost (you have to be careful to design the circuits to survive). Data is transmitted at approximately 55% of the radar interval, which does change a little, and also can also involve a standby set at a slightly different interval), so only about 1 in 20 packets is lost, Given that the system only requires one good packet a minute, reliability is fine, without a single failure to log in the last five years....

Best Wishes

[jeremiah]

Someone mentioned using an additional I/O above. Just wanted to comment:

While definitely not required for accurate serial comms, I do find such a signal pretty helpful when dealing with complex messaging protocols. I tend to have a buffer clear happen whenever my external CS like line goes high (or low if active low) so I don't have to waste time parsing through junk looking for a valid message. It also provides a nice clean means of waking up from sleep (if that is important to you) to intercept important data. Obviously, you can just parse the data looking for a valid message and that does work, but the additional I/O helps simplify a lot of stuff. Again though, nothing really to do with actual transmission accuracy.