|
hi all i am having problem in conducting Asynchronous communication with one start 8 data bit and one stop bit. (8N1). i dont want to use spra633 solution as that is not so much reliable as i have experienced please tell me is there any onther solution. thanking in anticipation Regards __________________________________ |
|
|
Asynchronous communication with C6711
Started by ●August 9, 2004
Reply by ●August 10, 20042004-08-10
|
Hi !! wrote: > hi all > > i am having problem in conducting Asynchronous > communication with one start 8 data bit and one stop > bit. > (8N1). i dont want to use spra633 solution as that is > not so much reliable as i have experienced please tell > me is there any onther solution. > thanking in anticipation There is an error in the spra633 solution. RDATDLY must be set to 1 or 2 to have a true uart. Otherwise it's only syncronous. I told EPIC about this. This was their answere in May 2004: > You are correct about the RDATDLY bit. It has to be 1 or 2 otherwise > the chip randomly misses the frame syncs. This is already known and > will be corrected in the next revision of the document. We sincerely > apologize that this has caused you valuable time. > I have now a solution based on spra633 which works fine for me. Gustl |
Reply by ●August 10, 20042004-08-10
|
Hi- SPRA633 seems to be the obvious solution for UART type of communication. There mite be other methods to deal with the problems but I would like to know why u consider that to be unreliable. -Tarang P.S: I have sucessfully implemented application on top of SPRA633 solution. On Mon, 9 Aug 2004 07:33:07 -0700 (PDT), Hi !! <> wrote: > hi all > > i am having problem in conducting Asynchronous > communication with one start 8 data bit and one stop > bit. > (8N1). i dont want to use spra633 solution as that is > not so much reliable as i have experienced please tell > me is there any onther solution. > thanking in anticipation > Regards > > __________________________________ > > _____________________________________ > Note: If you do a simple "reply" with your email client, only the author of this message will receive your answer. You need to do a "reply all" if you want your answer to be distributed to the entire group. > > _____________________________________ > About this discussion group: > > To Join: Send an email to > > To Post: Send an email to > > To Leave: Send an email to > > Archives: http://www.yahoogroups.com/group/c6x > > Other Groups: http://www.dsprelated.com > > Yahoo! Groups Links |
Reply by ●August 10, 20042004-08-10
|
Gustl- I have'nt use procom scripts to download commands. I agree to the RDATDLY setting that you have suggested. I had also made that change in my code. But I think that would *not make much of the difference* since we do have votelogic that takes care of it. (Votelogic tests just the center 4 bits out of 16 bits and makes a decision). I still didnt understand your point about synchonous. How will value in RDATDLY bit make it synchronous??? There is no external clock to the McBSP. Also in GPIO mode for SoftUartSpeedDetect routine they have said in the comment divide speedcounter by 2 and in the code it is speedcounter >>= 2; /* speedcounter divide by 2 */ -Tarang On Tue, 10 Aug 2004 13:58:28 +0100, Bennane Aomar-ABENNAN1 <> wrote: > > -Tarang > > Have you really implemented applications where you had to download commands using procom scripts? > If so how fast was the transfer rate? > Thanks > > -----Original Message----- > From: Tarang Dadia [mailto:] > Sent: 10 August 2004 08:42 > To: Hi !! > Cc: > Subject: Re: [c6x] Asynchronous communication with C6711 > > Hi- > > SPRA633 seems to be the obvious solution for UART type of communication. There mite be other methods to deal with the problems but I would like to know why u consider that to be unreliable. > > -Tarang > > P.S: I have sucessfully implemented application on top of SPRA633 solution. > > On Mon, 9 Aug 2004 07:33:07 -0700 (PDT), Hi !! <> wrote: > > hi all > > > > i am having problem in conducting Asynchronous > > communication with one start 8 data bit and one stop > > bit. > > (8N1). i dont want to use spra633 solution as that is > > not so much reliable as i have experienced please tell > > me is there any onther solution. > > thanking in anticipation > > Regards > > > > __________________________________ > > > > > > > _____________________________________ > > Note: If you do a simple "reply" with your email client, only the > > author of this message will receive your answer. You need to do a > > "reply all" if you want your answer to be distributed to the entire > > group. > > > > _____________________________________ > > About this discussion group: > > > > To Join: Send an email to > > > > To Post: Send an email to > > > > To Leave: Send an email to > > > > Archives: http://www.yahoogroups.com/group/c6x > > > > Other Groups: http://www.dsprelated.com > > > > Yahoo! Groups Links > > > > > > > > > > > > _____________________________________ > Note: If you do a simple "reply" with your email client, only the author of this message will receive your answer. You need to do a "reply all" if you want your answer to be distributed to the entire group. > > _____________________________________ > About this discussion group: > > To Join: Send an email to > > To Post: Send an email to > > To Leave: Send an email to > > Archives: http://www.yahoogroups.com/group/c6x > > Other Groups: http://www.dsprelated.com > > Yahoo! Groups Links |
|
|
Reply by ●August 11, 20042004-08-11
|
Tarang Dadia wrote: > Gustl- > > I have'nt use procom scripts to download commands. This question wasn't from me. > > I agree to the RDATDLY setting that you have suggested. I had also > made that change in my code. But I think that would *not make much of > the difference* since we do have votelogic that takes care of it. > (Votelogic tests just the center 4 bits out of 16 bits and makes a > decision). I still didnt understand your point about synchonous. How > will value in RDATDLY bit make it synchronous??? There is no external > clock to the McBSP. IIRC the example in spra633 is not asynchronous but syncronous because it receives and sends with the same clock. If you use a synchronous enviroment RDATDLY doesn't matter. But in an asynchronous enviroment RDATDLY=0 can cause a frame start detection error. There is nothing wrong with votelogic and decoding of the bits. The Problem is within McBSP. I've had some frame starts in the middle of the data! I have had two solutions: 1. sync incomming data/frame to outgoing clock with a flipflop or 2. set RDATDLY to 1 or 2 The problem is worse if you send your data one after another. > Also in GPIO mode for SoftUartSpeedDetect routine they have said in > the comment divide speedcounter by 2 and in the code it is > > speedcounter >>= 2; /* speedcounter divide by 2 */ I didn't use the GPIO mode. Gustl |
Reply by ●August 11, 20042004-08-11
|
Bernhard- > IIRC the example in spra633 is not asynchronous but syncronous because > it receives and sends with the same clock. Same clock does not matter for definition of synchronous. What if system is half-duplex (one way)? Then what definition would you use? Synchronous simply means data synchronized to separate clock line (or other source). > The problem is worse if you send your data one after another. Async communication is always more difficult in back-to-back char situation. 1 stop-bit is worst case. If you cannot perform software loopback without errors under these conditions, at your maximum required baud rate, then your solution is unreliable. I have a feeling that using built in McBSP features such as RDATDLY will exhibit unreliability at some point. The reliable approach would be to define the McBSP pins as GPIO, then sample the Rx pin at a high rate using a chip timer + interrupt, for example sample at 20 MHz or higher. Then you can find accurately find the start bit edge, and set the timer to interrupt you at middle of following bit periods, according to your baud rate. A better approach -- if the board permits -- is to do the UART function in logic, then burst the chars through on standard McBSP. The DSP never knows the difference. That approach is very flexible -- you can for example set up N logic UARTS, send the DSP 16-bit words, and store the channel number on the high byte. OCTUART or more :-) -Jeff |
|
|
Reply by ●August 11, 20042004-08-11
|
Jeff Brower wrote: > Bernhard- >> IIRC the example in spra633 is not asynchronous but syncronous >> because it receives and sends with the same clock. > Same clock does not matter for definition of synchronous. What if > system is half-duplex (one way)? Then what definition would you use? > Synchronous simply means data synchronized to separate clock line (or > other source). > It's a loopback and it's synchronized to the same clock source so it is synchronous even if you don't have a seperate clock line. > >> The problem is worse if you send your data one after another. > Async communication is always more difficult in back-to-back char > situation. 1 stop-bit is worst case. If you cannot perform software > loopback without errors under these conditions, at your maximum > required baud rate, then your solution is unreliable. I have a > feeling that using built in McBSP features such as RDATDLY will > exhibit unreliability at some point. The reliable approach would be > to define the McBSP pins as GPIO, then sample the Rx pin at a high > rate using a chip timer + interrupt, for example sample at 20 MHz or > higher. Then you can find accurately find the start bit edge, and > set the timer to interrupt you at middle of following bit periods, > according to your baud rate. But the GPIO solution is using a lot of DSP time. I'm using the McBSP solution with the change in RDATDLY. I have tested it with different baud rates and havn't found any unreliability. > > A better approach -- if the board permits -- is to do the UART > function in logic, then burst the chars through on standard McBSP. > The DSP never knows the difference. That approach is very flexible -- > you can for example set up N logic UARTS, send the DSP 16-bit words, > and store the channel number on the high byte. OCTUART or more :-) > > -Jeff |
Reply by ●August 11, 20042004-08-11
|
Bernhard- > It's a loopback and it's synchronized to the same clock source so it is > synchronous even if you don't have a seperate clock line. What clock source? The external device is a UART... isn't it? No clock... no synchronous. -Jeff > But the GPIO solution is using a lot of DSP time. I'm using the McBSP > solution with the change in RDATDLY. I have tested it with different > baud rates and havn't found any unreliability. What maximum baud rate? How many stop bits? -Jeff |
|
|
Reply by ●August 11, 20042004-08-11
|
Jeff,Bernhard-
On Wed, 11 Aug 2004 16:19:59 +0200, Bernhard Gustl Bauer <> wrote: > Jeff Brower wrote: > > > Bernhard- > > > > > >> IIRC the example in spra633 is not asynchronous but syncronous > >> because it receives and sends with the same clock. > > Clock is needed for sync'ing but in spra633 they are using FSR to provide sync information and not the clock. And I am pretty sure that if I doubled the clock rate at receive McBSP. I would still be able to get data properly since I would then be sampling McBSP line at twice the rate and I can then re-write code to decode 32 bits instead of 16 bits as in the current application. Would you call this system synchronous? > > > > Same clock does not matter for definition of synchronous. What if > > system is half-duplex (one way)? Then what definition would you use? > > > > > > Synchronous simply means data synchronized to separate clock line (or > > other source). > > > > It's a loopback and it's synchronized to the same clock source so it is > synchronous even if you don't have a seperate clock line. I think, loopback mode is demonstrated in the application report since they are doing just proof of principle and not every one has access to 2 DSK boards so better on single board. In the application, I am using 2 different boards and I dont transmit clock to receiver and hence application is asynchronous (doesnt require the *same* clock). According to what I have understood, synchronous system is the one in which we need same clock at the receiver that we used at the transmitter. And by same clock I dont mean same clock frequency, but same phase. > > > > >> The problem is worse if you send your data one after another. > > > > > > Async communication is always more difficult in back-to-back char > > situation. 1 stop-bit is worst case. If you cannot perform software > > loopback without errors under these conditions, at your maximum > > required baud rate, then your solution is unreliable. I have a > > feeling that using built in McBSP features such as RDATDLY will > > exhibit unreliability at some point. The reliable approach would be > > to define the McBSP pins as GPIO, then sample the Rx pin at a high > > rate using a chip timer + interrupt, for example sample at 20 MHz or > > higher. Then you can find accurately find the start bit edge, and > > set the timer to interrupt you at middle of following bit periods, > > according to your baud rate. I have come to agreement to the fact that McBSP is more robust and repeatable as compared to GPIO. I observed lot of skew in my received data when I operated it in GPIO mode. But then didnt sample it at high sampling rate, as you have told, > > But the GPIO solution is using a lot of DSP time. I'm using the McBSP > solution with the change in RDATDLY. I have tested it with different > baud rates and havn't found any unreliability. Yeah I agree to this, GPIO modes takes lot of DSP time. I have come to terms with mixed system. GPIO at tx and McBSP in serial port at receiver. > > > > > A better approach -- if the board permits -- is to do the UART > > function in logic, then burst the chars through on standard McBSP. > > The DSP never knows the difference. That approach is very flexible -- > > you can for example set up N logic UARTS, send the DSP 16-bit words, > > and store the channel number on the high byte. OCTUART or more :-) Yes Jeff, this mite b interesting to try out. Do correct me if I am wrong. -Tarang > > > > -Jeff |
Reply by ●August 11, 20042004-08-11
|
Tarang- > Clock is needed for sync'ing but in spra633 they are using FSR to > provide sync information and not the clock. And I am pretty sure that > if I doubled the clock rate at receive McBSP. I would still be able to > get data properly since I would then be sampling McBSP line at twice > the rate and I can then re-write code to decode 32 bits instead of 16 > bits as in the current application. > > Would you call this system synchronous? If the "clock" is being used for sampling purposes, and you don't know which clock to expect to find data, then no. If the clock is being used to tell you where data is -- exactly -- then yes. Typically in a sync system, rising (or falling) edge of clock says "data bit". If you're sampling looking for a UART start bit, well then you might find one, and you might not :-) That's async, and you simply chose your clock to be fast enough to not miss anything. -Jeff > > > Same clock does not matter for definition of synchronous. What if > > > system is half-duplex (one way)? Then what definition would you use? > > > > > > > > > Synchronous simply means data synchronized to separate clock line (or > > > other source). > > > > > > > It's a loopback and it's synchronized to the same clock source so it is > > synchronous even if you don't have a seperate clock line. > > I think, loopback mode is demonstrated in the application report since > they are doing just proof of principle and not every one has access to > 2 DSK boards so better on single board. > > In the application, I am using 2 different boards and I dont transmit > clock to receiver and hence application is asynchronous (doesnt > require the *same* clock). > > According to what I have understood, synchronous system is the one in > which we need same clock at the receiver that we used at the > transmitter. And by same clock I dont mean same clock frequency, but > same phase. > > > > > > > > >> The problem is worse if you send your data one after another. > > > > > > > > > Async communication is always more difficult in back-to-back char > > > situation. 1 stop-bit is worst case. If you cannot perform software > > > loopback without errors under these conditions, at your maximum > > > required baud rate, then your solution is unreliable. I have a > > > feeling that using built in McBSP features such as RDATDLY will > > > exhibit unreliability at some point. The reliable approach would be > > > to define the McBSP pins as GPIO, then sample the Rx pin at a high > > > rate using a chip timer + interrupt, for example sample at 20 MHz or > > > higher. Then you can find accurately find the start bit edge, and > > > set the timer to interrupt you at middle of following bit periods, > > > according to your baud rate. > > I have come to agreement to the fact that McBSP is more robust and > repeatable as compared to GPIO. I observed lot of skew in my received > data when I operated it in GPIO mode. But then didnt sample it at high > sampling rate, as you have told, > > > > > But the GPIO solution is using a lot of DSP time. I'm using the McBSP > > solution with the change in RDATDLY. I have tested it with different > > baud rates and havn't found any unreliability. > > > > > Yeah I agree to this, GPIO modes takes lot of DSP time. I have come to > terms with mixed system. GPIO at tx and McBSP in serial port at > receiver. > > > > > > > > > A better approach -- if the board permits -- is to do the UART > > > function in logic, then burst the chars through on standard McBSP. > > > The DSP never knows the difference. That approach is very flexible -- > > > you can for example set up N logic UARTS, send the DSP 16-bit words, > > > and store the channel number on the high byte. OCTUART or more :-) > > Yes Jeff, this mite b interesting to try out. > > Do correct me if I am wrong. > > -Tarang > > > > > > -Jeff > > > > |
|
|
