rs232通信中的问题

亲爱的NKurzman，我收到的数据从外部硬件到Mx23 2芯片，然后PIC控制器。实际上，硬件是一个平衡模块。它应该只在大约20字节的数据中给出对象的权重。该数据不应该是任何特殊符号和不需要的字符。



      以下为原文

    Dear NKurzman,
   I receive a data from external hardware to max232 chip and then pic controller. Actually that hardware is a balance module. It should give a weight of the object in some 20 bytes data only. That data is should not any special symbols and unwanted character.

距离为1米至2米。我不希望有任何垃圾字符。在我的代码中，只接收一个数据并将其存储到某个数组变量中。



      以下为原文

    Distance is 1 to 2 meters. I don't expect any garbage characters. In my code just receive a data and store that to some array variable.

1到2米TTL或带收发器？环境是什么？桌面？实验室还是工业？如果你希望你的接收是健壮的，你必须期待垃圾字符和丢失的字符。



      以下为原文

    1 to 2 meters TTL or with transceivers?
What is the environment? desktop? lab or industrial ?
If you want your reception to be robust you have to expect garbage characters and lost characters.

1到2米的收发器。在实验室中将PIC控制器连接到平衡模块。



      以下为原文

    1 to 2 meters transceivers.
Interfacing pic controller to balance module in lab.

我启用CREN位永久控制器不能接收数据。它等待着发出中断标志。如果我启用CREN，我将接收数据并在数据接收后禁用它。这个条件只有我能接收到数据。这是正确的方法吗？



      以下为原文

    I enable CREN bit permanently controller can't receive a data. It goes wait to raise interrupt flag. If i enable CREN when i will going to receive a data and disable that after data reception. This condition only i can receive a data.
Is it a proper way?
 

PIC中时钟的准确度是多少？定时漂移会导致接收困难。两侧5%的误差会导致故障。我不使用那个处理器，但是你的时钟除法器是精确的吗？在我使用的PIC16S中，波特率发生器参数是关键的。你看到任何帧错误吗？超支？什么是数据？正如NK所说的，一个健壮的协议可能会有所帮助。我发送小数据包（10至20字节），很好地分隔，并使用CRC16进行保护。始终使用保护



      以下为原文

    How accurate is the clock in the PIC?  Timing drift can cause reception difficulties.  A 5% error on both sides will cause failure.  I don't use that processor, but are your clock dividers exact?  In the PIC16s I use, the BaudRate Generator parameters are critical.
 
Are you seeing any framing errors?  Overruns?
 
What is the datarate?
 
As NK has said, a robust protocol might help.  I send small packets (10 to 20 bytes), well delimited, and use a CRC16 for protection.  Always use protection.
 
GP

我清除CREN的唯一时间是在数据溢出之后。在PIC16S中使用“棍棒”



      以下为原文

   


The only time I clear CREN is after a Data Overrun.  Overrun "sticks" in the PIC16s I use.
 
GP

在所有图片上运行过度。如果你被超载，那么你就不会足够快地从缓冲区中提取数据。你不应该和克伦一起玩。波特率是多少？你有水晶吗？你说的东西有水晶吗？



      以下为原文

    Over run sticks on all PICs.
If you are getting overruns then you are not pulling the data from the buffer fast enough.
You should not have to play with CREN.

What is the baudrate?
Do you have a crystal?
Does the thing you are talking to have a crystal?

我的控制器时钟是41.6兆赫的PLL。我使用默认波特率9600，8个数据位，无奇偶校验。波特率发生器SPBRG值为67（默认值），数据表中给出0.16%错误，我不想用CRC发送数据。我只需要接收它。有可能获得没有特殊符号和丢失字符的接收数据。



      以下为原文

    My controller clock is 41.6 Mhz with a PLL.
I'm using default baud rate 9600,8 data bits,none parity.
Baud rate generator SPBRG value is 67(default) with 0.16% error which was given in data sheet.
I don't want to send a data with crc. I need to receive it only. Is any possibilities to get a received data without special symbols and losing characters.

是的，它一直都在进行。但是如果你正在清理和设置CREN，你不能肯定你在字节传输过程中没有这么做。在启用EUSAT（通过设置SPEN）之前设置CREN，除非您需要处理溢出，否则留下CREN。在41兆赫，如果你超支，有一个严重的设计缺陷在程序中。很容易跟上10KB，一个1 MHz的FoSC。你使用中断来检索从UART的FIFO接收到的字节吗？你的中断做了多长时间（超过25个指令每个外设）？如果你不使用中断（你应该），你多久检查一次RCIF？您可以通过使用第322页所示的值来降低波特率误差：SPBRG＝1084和Syc＝0，BRG16＝1，BRGH＝1或同步＝1，BRG16＝1。误差为0.01%。但这不是你问题的原因。UART通常可以容忍2%个错误，因为它们每10位重新同步（或类似）。您没有回答NK关于晶体控制的问题。看来你在使用PIC18内部振荡器。[我没有找到它的准确度，但是参数f13表示抖动是+/- 2%。这与准确性不一样。你可能需要一个水晶或陶瓷谐振器。发送者呢？你用一个好的示波器或其他工具验证了它的比特率是稳定的和正确的吗？你应该调查为什么你认为你需要设置和清除CREN。这是一个真正的问题。没有看到实际的代码，它只是猜测。



      以下为原文

   


Yes, it's done all the time.
 
But if you're clearing and setting CREN, you can't be sure you're not doing so during the transmission of a byte.  Set CREN before you enable the EUSART (by setting SPEN) and leave CREN on unless you need to handle Overrun.  [At 41+ MHz if you're getting overrun, there is a serious design flaw in the program.  It's easy to keep up with 10Kb with a 1 MHz Fosc.]
 
Are you using interrupts to retrieve the received bytes from the UART's FIFO?  Are your interrupts doing anything long (more than 25 instructions per peripheral)?
 
If you're not using interrupts (you should), how often are you checking RCIF?
 
You can reduce your baud rate error by using the values shown on page 322: SPBRG=1084 and SYNC = 0, BRG16 = 1, BRGH = 1 or SYNC = 1, BRG16 = 1.  The error will be +0.01%.  But that is not the cause of your problem.  UARTs can generally tolerate 2% errors easily as they re-sync every 10 bits (or so).
 
You didn't answer NK's question about crystal control.  It seems you're using the internal oscillator in the PIC18.  [I didn't find its accuracy but parameter F13 states jitter is +/-2%.  That's not the same as accuracy.  You may need a crystal or ceramic resonator.
 
What about the sender?  Have you verified its bit rate is stable and correct with a good oscilloscope or other tool?
 
You should investigate why you think you need to set and clear CREN.  That's a real problem.
 
Without seeing the actual code, it's all just guesses.

同意。我怀疑在字符中间启用了CREN时，错误发生了，我怀疑OP之所以这样做是因为设备总是发送数据，当它们去做一些需要花费时间的事情时，它们会发生溢出错误。



      以下为原文

   
Agreed.
I suspect the errors are occurring when CREN is enabled in the middle of the character,
and I suspect the OP is doing it because the device is always sending data, and they are getting overflow errors when they go to do things which take some time.
 
 

在41.666 MHz和9600波特，这是大量的指令每字节，超过10850。UART的缓冲区至少有两个字节。我猜想程序的结构需要考虑延迟。但没有代码发布，我猜。GP。



      以下为原文

   


At ~41.666 MHz and 9600 Baud, that's a lot of instructions per byte, over 10,850.  And the UART's buffer is at least two bytes.
 
My guess is the program's structure needs to take latencies into account.  But with no code posted, I'm guessing.
 
GP.
 
 

我使用的是具有12兆赫频率的外部晶体，我使用的是轮询方法，而不是中断。我的代码是：无符号char BalangsId[0]＝{ 0 }；空隙UARTHOCIIT（空隙）{TrISCbTITE；TrISC7＝1；TXSTA1= 0x00；RcSTA1= 0x80；BaDCONC＝0x00；SPBRG＝67；}无符号char DATAAL接收（空隙）{uncar char i＝0；RCSTA1Bi；Ts CREN＝1；（i＝0；i和lt；20；i++）{同时（！）BrasixDATA＝RCREG1；} RCSTA1BIT。CREN＝0；}/PrasANTH



      以下为原文

    I'm using external crystal which has 12 Mhz frequency.
I'm using polling method not as interrupt.
 My code is here
 
unsigned char Balance_data[20]={0};
void Uart_init(void)
{
     TRISCbits.TRISC7=1;
     TXSTA1=0x00;
     RCSTA1=0x80;
     BAUDCON=0x00;
     SPBRG=67;
}
 
unsigned char Data_Receive(void)
{
     unsigned char i=0;
     RCSTA1bits.CREN=1;
     for(i=0;i<20;i++)
     {
          while(!PIR1bits.RC1IF);
          Balance_data=RCREG1;
     }
     RCSTA1bits.CREN=0;
}
 
/prasanth
   

关掉CRON是你问题的根本原因。别再干了！



      以下为原文

    Toggling CREN off and on is the root cause of your problem. Stop doing it!
 

如果你得到一个额外的字节或松散的代码，会发生什么？你在哪里检查错误？如果你不在那个循环中接收一个字节，会发生什么？您认为您需要CREN，因为它隐藏了您处理不当的溢出错误。



      以下为原文

    What will happen to that code if you get an extra byte or loose one?
Where do you Check for errors.
What happens if you receive a byte while you are not in that loop?
You think you need the CREN there because it hides your improperly handled the overflow error.

如果我停止切换CREN位，我无法从该平衡模块接收数据。编译器在一段时间内循环等待。我正在丢失字节和意外的特殊符号。我用我的桌面超级应用程序检查了平衡模块，没有错误发生。我想做什么？



      以下为原文

    If i stop toggling CREN bit that i can't receive a data from that balance module.
Compiler get wait in a while loop.
I'm getting losing of bytes as well as unexpected special symbols.
I had checked that balance module with my desktop hyper term application there is no error get occur.
What i want to do?
 
 

我发现很难相信你可以将RCREG1分配给数组，而不用索引到数组中，尽管我不使用那个编译器。我怀疑这不是正在运行的代码。正如NK和QHB和我所说的，您不能在任意时间启用接收器。你会得到坏的字符和框架错误。除非报告了溢出错误，否则不要禁用和启用接收器。您不应对错误（FER和ORR测试）。对于9600波特，你应该使用更好的近似。



      以下为原文

   
 
I find it hard to believe you can assign RCREG1 to an array without indexing into the array, although I don't use that compiler.  I suspect this is not the code that's being run.
 
As NK and qhb and I have said, you cannot enable the receiver at an arbitrary time.  You will get bad characters and framing errors.  Unless an OverRun error is reported, do not disable and enable the receiver.
 
You don't handle errors (test for FERR and OERR).  You should use a better approximation for 9600 Baud.
 
IOH,
GP

这是一个不使用代码标签的副作用。“”在那里，但被解释为“斜体标记”。

以上来自于百度翻译

      以下为原文

   
It's a side effect of not using code tags.
The "[ i ]" was there, but was interpreted as an "italics on" tag.