| View previous topic :: View next topic |
| Author |
Message |
iw2nzm
Joined: 23 Feb 2007
Posts: 55
|
| General questions about serial |
 Posted: Fri Aug 31, 2007 10:17 am |
 |
|
Hi,
I read a lot of thread but I still have a couple of questions. I'm using a PIC18F4520 @ 40 MHz (x4 PLL).
1) Let's consider a serial repeater. One serial link is connected to the hw uart, the other to PIN_B0/INT (rx) and PIN_C0 (tx). Both links run @ 19200 bps.
Each channel works fine if tested alone. However, I need to forward the incoming data from a port to the other and vice versa. What's the right way to do this? Keep in mind I have a PC-based software which must communicate with the peripheral via this repeater. So the link must be "transparent".
2) I have an electronic compass connected to a software UART and a remote link to the hw UART. The compass transmits data every 200 ms. Every 200 ms I should also send this and other data to the remote link. I tried to use a timer interrupt to send data on the remote link while the ext interrupt receives the compass data. But after a while it hangs-up (also using 'disable_ints' in the rs232 declaration). Please, may you provide me a sample code to manage such a situation? By the way, I can't transmit data just after received the compass data because if the compass dies no data will be transmitted anymore.
Thanks
Marco / iw2nzm |
|
 |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Fri Aug 31, 2007 10:39 am |
|
|
Does your tranmission go in one direction only ?
Example :
| Quote: | | From Compass --> PIC --> PC |
How many bytes are in the data packets coming from the compass ? |
|
|
RLScott
Joined: 10 Jul 2007
Posts: 465
|
| Re: General questions about serial |
| Posted: Fri Aug 31, 2007 10:45 am |
|
|
Your method should allow for the possibility that the two 19,200 Baud rates may not be exactly the same (the one from the compass and the one from your PIC). Therefore you cannot simply transmit each character that you receive on a character-by-character basis. You need to have a software buffer that can store several characters in case the receiving channel gets ahead of the transmitting channel. As long as there is a pause every 200 msec, then you will always have a chance to catch up. Figure the size of the largest continuous packet that you will receive, then multiply by the maximum fraction deviation between the two baudrates. That will give you the minimum size for your buffer. For example, if a packet is 200 bytes, and if baud rates differ by at most 2%, then you need at least 4 bytes of buffering.
Robert Scott
Real-Time Specialties |
|
|
iw2nzm
Joined: 23 Feb 2007
Posts: 55
|
|
| Posted: Fri Aug 31, 2007 10:51 am |
|
|
| PCM programmer wrote: | Does your tranmission go in one direction only ?
Example :
| Quote: | | From Compass --> PIC --> PC |
How many bytes are in the data packets coming from the compass ? |
The compass data length is about 20 bytes.
Nope, the transmission is bidirectional. However, in the first situation I only need to forward the incoming data. In the second one, I need to acquire the compass data, send it to the PC and receive from this new commands.
Bye
Marco / iw2nzm |
|
|
iw2nzm
Joined: 23 Feb 2007
Posts: 55
|
| Re: General questions about serial |
| Posted: Fri Aug 31, 2007 10:58 am |
|
|
| RLScott wrote: | | As long as there is a pause every 200 msec, then you will always have a chance to catch up. Figure the size of the largest continuous packet that you will receive, then multiply by the maximum fraction deviation between the two baudrates. That will give you the minimum size for your buffer. For example, if a packet is 200 bytes, and if baud rates differ by at most 2%, then you need at least 4 bytes of buffering. |
The data packet length is very short: about 20 bytes. However, I don't understand why I need the buffer. If I forward byte-by-byte even if the baud rates are not exactly the same no data should be loss until the uart is able to decode incoming bits.
And I tried to buffer the entire string but it doesn't work.
Thank you!
Marco / iw2nzm |
|
|
Ken Johnson
Joined: 23 Mar 2006
Posts: 197
Location: Lewisburg, WV
|
|
| Posted: Fri Aug 31, 2007 11:47 am |
|
|
Why not just forward the Rx data stream (through a buffer if needed) on to the PC without going *through* the pic? If only some data needs forwarded, maybe you could gate this buffer?
Otherwise, depending on what other work the pic is doing, simply copying each byte should work ok. Or just monitor the Rx pin and set/clear the Tx pin to follow it . . .
Ken |
|
|
SherpaDoug
Joined: 07 Sep 2003
Posts: 1640
Location: Cape Cod Mass USA
|
|
| Posted: Fri Aug 31, 2007 11:48 am |
|
|
I built a product a few years ago that had sensor A data coming in packets into port A, and out port B to a modem to a PC host. At the end of each packet the PIC added its own data, making a longer packet.
The data from A to B just passed through a gate (NAND I believe) between the ports. The PIC eavesdropped on this data and when a packet started the PIC took an A/D reading did some math and then waited to see the packet terminator go by. As soon as the terminatior passed, the PIC inserted its own data through the NAND gate.
The PIC didn't have to actually read more than a byte or two of the A data and there was no need to store or buffer anything. The PC would simply read bytes till it saw a terminator, then read a packet till the next terminator arrived. It saw the PIC data, one sample old, as being added to the FRONT of the main A data.
This was an optional add-on sensor so the PC would simply receive long packets if the option was present, or short packets if the option was missing. It sounds like your situation may be similar.
_________________
The search for better is endless. Instead simply find very good and get the job done. |
|
|
iw2nzm
Joined: 23 Feb 2007
Posts: 55
|
|
| Posted: Fri Aug 31, 2007 12:12 pm |
|
|
In normal mode the compass data is read, decoded, added to the packet data frame and sent to the host. When in calibration mode, the host should communicate directly with the compass. So the PIC must do both functions.
I can't use external hardware. It isn't a new design, so I must use what there is.
Bye
Marco / iw2nzm |
|
|
treitmey
Joined: 23 Jan 2004
Posts: 1094
Location: Appleton,WI USA
|
|
| Posted: Fri Aug 31, 2007 2:49 pm |
|
|
The nice thing is both links are 19200
| Quote: | | The compass transmits data every 200 ms. Every 200 ms I should also send this and other data to the remote link. |
I would use ONLY the hardware USART.
compass --> PIN_C7 (PIC) PIN_C6-->remote link
Only 1 hardware UART is needed!!(I think) |
|
|
iw2nzm
Joined: 23 Feb 2007
Posts: 55
|
|
| Posted: Fri Aug 31, 2007 4:03 pm |
|
|
| treitmey wrote: |
I would use ONLY the hardware USART.
compass --> PIN_C7 (PIC) PIN_C6-->remote link
Only 1 hardware UART is needed!!(I think) |
It's a great idea! But unfortunately I need to forward data to *both* direction 
Marco / iw2nzm |
|
|
RLScott
Joined: 10 Jul 2007
Posts: 465
|
| Re: General questions about serial |
| Posted: Sat Sep 01, 2007 6:46 am |
|
|
| iw2nzm wrote: |
The data packet length is very short: about 20 bytes. However, I don't understand why I need the buffer. If I forward byte-by-byte even if the baud rates are not exactly the same no data should be loss until the uart is able to decode incoming bits. ..
Marco / iw2nzm |
I agree. With any reasonable minor baudrate mismatch, it should be impossible for one transmitter to get more than one character ahead of the other transmitter in only 20 bytes. But you could see where it could have been a problem if you were trying to repeat 200 or more bytes.
When acting as a repeater, are you still checking the transmit buffer empty bit before loading a new character from the receiver?
Robert Scott
Real-Time Specialties |
|
|
iw2nzm
Joined: 23 Feb 2007
Posts: 55
|
| Re: General questions about serial |
| Posted: Sat Sep 01, 2007 7:00 am |
|
|
| Quote: | | When acting as a repeater, are you still checking the transmit buffer empty bit before loading a new character from the receiver? |
Nope. I do this in the rda and ext isr:
char rcv;
rcv = fgetc(stream_A)
fputc(rcv, stream_B)
and viceversa.
Are you saying I have to check the buffer empty bit and if it isn't empty I must save the char in a buffer until the buffer will be void?
Marco / iw2nzm |
|
|
RLScott
Joined: 10 Jul 2007
Posts: 465
|
| Re: General questions about serial |
| Posted: Sun Sep 02, 2007 6:34 pm |
|
|
| iw2nzm wrote: | ...
rcv = fgetc(stream_A)
fputc(rcv, stream_B)
Are you saying I have to check the buffer empty bit and if it isn't empty I must save the char in a buffer until the buffer will be void?
Marco / iw2nzm |
I'm not sure what fgetc() and fputc() does, but I'll bet that fgetc() implicitly waits for the Received Full bit to be set and fputc() implicitly waits for the Transmit Buffer Empty bit to be set, so it looks like you are protected. Given the double buffering in the transmitter, you can fall behind by up to one character and still every time you come to fputc(), the Transmit Buffer Empty bit will already be set, resulting in no extra wait.
When you say that the communication fails "after a while", is the time until failure always about the same? What evidence do you have of a failure? Can you say that some expected byte got left out of the transmit stream? Dividing and conquer. Place some diagnostic code in the middle of your repeater and see which end is "failing"
Robert Scott
Real-Time Specialties |
|
|
iw2nzm
Joined: 23 Feb 2007
Posts: 55
|
| Re: General questions about serial |
| Posted: Mon Sep 03, 2007 12:32 am |
|
|
| RLScott wrote: | | When you say that the communication fails "after a while", is the time until failure always about the same? |
No, sometimes it hangs after few seconds, others immediately.
| Quote: | | What evidence do you have of a failure? |
I receive garbage chars, and the software on the PC doesn't recognize anymore the compass.
| Quote: | | Can you say that some expected byte got left out of the transmit stream? Dividing and conquer. Place some diagnostic code in the middle of your repeater and see which end is "failing"Specialties |
I tried to do this, but it's quite difficult. If the data stream is only in one direction there's no problem at all. When both ports have to retransmit bytes it's not easy to monitor what's happening!
Marco / iw2nzm |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
