PIC18F27K40上的EUSART速率提高失败

你为什么要做所有的中断，禁用和重新启用？当然，您需要的是：（我假设您正在使用TMR4实现某种超时）。



      以下为原文

    Why are you doing all the interrupts disabling and re-enabling?
Surely all you need is:
void EUSART2_Receive_ISR(void) // receive a byte
{
    EUSART2RxBuffer[EUSART2RxHead++] = RC2REG; // Read the EUSART into a global volatile uint8_t array variable called EUSART2RxBuffer at the position of EUSART2RxHead
    T4TMR = 0; // reset the TMR4 counter
    PIR4bits.TMR4IF = 0; // clear the TMR4 interrupt flag
}
(I assume you are using TMR4 to implement some sort of timeout.)

你有没有理由以这么慢的时钟速率运行PIC？是什么阻止了接收缓冲区溢出？什么叫空洞EuSART2A2？MCC浪费循环是通过函数指针调用的吗？在PRO模式下运行编译器吗？



      以下为原文

    Is there a reason  you're running the PIC at such a slow clock rate?
 
What prevents your receive buffer from overflowing?
 
What is calling void EUSART2_Receive_ISR(void)?  Is MCC wasting cycles calling this through a function pointer?
 
Are you running the compiler in PRO mode?

问得好，约翰。我假设OP试图节省电力。我也打算对此进行评论。所提出的代码是非常危险的，它最终肯定会溢出缓冲区。这将是MCC做的，而且效率很低。显然，还有一个TMR4中断运行，尽管来自提出的代码，我们不知道它是否与USAT相同的优先级。另一个好问题：



      以下为原文

   
Good question John. I assume the OP is trying to save power.
 
 
I meant to comment on that also.
The code as presented is extremely dangerous, it will almost certainly overflow the buffer eventually.
 

It will be MCC doing that, and it WILL be very inefficient.
Plainly there is also a TMR4 interrupt running, although from the code presented we don't know if it's at the same priority as the USART.
 

Another good question :)
 

而且在57600的波特率误差非常高，而不是9600，这取决于如何配置波特发生器。您需要使用BRGH集的16位BRG。



      以下为原文

    And you've got a very high baud rate error at 57600 that isn't present at 9600, depending on how you have the baud generator configured.  You need to use the 16-bit BRG with BRGH set.

谢谢大家，正如我提到的，我正在运行建议代码MCC，所以ISR从“中断管理器”调用。在这一阶段，我还不知道它是如何完成的。是的，这两个中断都是相同的高优先级。QHB——是的，我使用TMR4作为输入字节数组的超时。它设置了大约1个半字节。PIC正在以一个速度运行，这对于它需要做的所有事情来说都是完美的。我对电源使用非常有意识-它是一个电池应用。QHB -你是正确的，我可以离开TMR运行，只是重新设置计数器（而不是停止和启动）在每个字节进来，但我必须首先启动它。我相信你们不处理传入的流一字节。一次？我的方法可能是愚蠢的。我想把连续流的每个字节都推到数组中，当流停止时，我会处理数组。要做到这一点，我需要把一个数组推到大约6到7位的时间范围内完成。如果能改变的话，这可能会改变。再次感谢



      以下为原文

    Thanks guys,
 
jtemples - As mentioned, I'm running the suggested code my MCC so the ISR gets called from an 'interrupt manager.c'.  I am not up with how else it is done at this stage.
 
Yes the two interrupts are both the same high level of priority.
 
QHB - Yes I'm using TMR4 as a timeout for the incoming byte array.  It it set for about 1 and a half bytes.
The PIC is running at a speed which is perfectly fine for everything else it needs to do.  I am very conscious about power usage -  it is a battery application.
 
QHB - you're correct in that I can leave the TMR running and just reset the counter (rather than stop and start) after each byte comes in but I've got to start it first.
 
I trust you guys don't process the incoming stream one byte-at-a-time ?  My methodology may well be silly.  I was thinking to push each byte of a continuous stream into an array and when the stream stops I would process the array. To do this I need the push into an array to be completed within the timeframe of about 6 or 7 bits I'd reckon.
 
No just running compiler in FREE mode.  That can change if it would make a difference.
 
Thanks again

在时钟速率和57600波特时，每个中断都有800个指令周期。你的ISR可能不使用其中的10%个。你的问题是波特率错误，正如我上面提到的，或者在你还没有告诉我们的代码中的其他地方。这很好，只要你能保证它在它超过你的缓冲区之前就停止。但写的是一个很难找到的bug。至少你想做点什么



      以下为原文

    At that clock rate and 57600 baud, you have > 800 instruction cycles per interrupt.  Your ISR probably isn't using 10% of that.  Your problem is either with the baud rate error as I mentioned above, or somewhere else in the code you haven't shown us.
 

 
That's fine as long as you can guarantee it's going to stop before it overruns your buffer.  But as written it's asking for a hard-to-find bug.  At a minimum you'd want to do something like if (EUSART2RxHead < sizeof EUSART2RxBuffer)
    EUSART2RxBuffer[EUSART2RxHead++] = RC2REG;

如果它有帮助，这是代码从MCC在CufftTyManger-Curr.C.串行数据是从一个MC2200非常接近靠近一个子板。也许有2英寸的信号路径从PIC到MC2200。软件缓冲区检查超支。实际上我有更多的代码做各种检查（比如帧错误等），我已经从ISR中删掉了。在这个阶段，我已经把ISR代码减少到几乎没有了，但它仍然不能在更高的速度下工作。如果有错误（MCP程序的MCU实用程序没有设置）。Le正好是57600，因为它的价值）我不知道如何在硬件中减少它们。我在PIC和MC2200中都使用晶体。



      以下为原文

    If it helps, this is the code from MCC in interrupt_manager.c
 

 
void interrupt INTERRUPT_InterruptManagerHigh (void)
{
// interrupt handler
if(PIE0bits.TMR0IE == 1 && PIR0bits.TMR0IF == 1)
{
TMR0_ISR();
}
else if(PIE3bits.RC2IE == 1 && PIR3bits.RC2IF == 1)
{
EUSART2_Receive_ISR();
}
else if(PIE3bits.RC1IE == 1 && PIR3bits.RC1IF == 1)
{
EUSART1_Receive_ISR();
}
else if(PIE4bits.TMR4IE == 1 && PIR4bits.TMR4IF == 1)
{
TMR4_ISR();
}
else if(PIE4bits.TMR2IE == 1 && PIR4bits.TMR2IF == 1)
{
TMR2_ISR();
}
else if(PIE0bits.IOCIE == 1 && PIR0bits.IOCIF == 1)
{
PIN_MANAGER_IOC();
}
else
{
//Unhandled Interrupt
}
}
 
void interrupt low_priority INTERRUPT_InterruptManagerLow (void)
{
// interrupt handler
if(PIE3bits.BCL2IE == 1 && PIR3bits.BCL2IF == 1)
{
I2C2_BusCollisionISR();
}
else if(PIE3bits.SSP2IE == 1 && PIR3bits.SSP2IF == 1)
{
I2C2_ISR();
}
else
{
//Unhandled Interrupt
}
}

 
The serial data is incoming from an MCP2200 located very close by on a daughterboard.  Perhaps there is 2 inches of signal path from PIC to MCP2200.
 
The software buffer has checks for overruns.  I did actually have a lot more code doing various checks (like frame errors etc.) that I've cut out of the ISR.
 
At this stage, I've reduced the ISR code to almost nothing and it still doesn't work at higher speed.
 
If there are errors (the Microchip utility that is used to program the MCP doesn't settle on exactly 57600 for what its worth) I'm not sure how to reduce them in hardware.  I'm using crystals in both the PIC and MCP2200.  
 

我同意约翰的观点。你可能在追寻错误的问题。除非你做的事情效率太低，否则错误是由于波特率，而不是指令执行。你还没有提到BRG/BRGH/BRG16设置是用来获得57600波特的。



      以下为原文

    I agree with John. You're probably chasing the wrong problem.
Unless you're doing something horribly inefficiently, the error is due to the baud rate, not instruction execution.
You've still not mentioned what BRG/BRGH/BRG16 settings you are using to get 57600 baud.
 
 

这里是57600的初始化例程。



      以下为原文

    Here's the initialization routine for 57600.
 

 
 
 
 
 
 
 
void EUSART2_Initialize_57600_8N1(void)
{
PIE3bits.RC2IE = 0; // disable RC2 interrupt
PIE3bits.TX2IE = 0; // disable TX2 interrupt
BAUD2CON = 0x08; // ABDOVF no_overflow; SCKP Non-Inverted; BRG16 16bit_generator; WUE disabled; ABDEN disabled;
RC2STA = 0x90; // SPEN enabled; RX9 8-bit; CREN enabled; ADDEN disabled; SREN disabled;
TX2STA = 0x24; // TX9 8-bit; TX9D 0; SENDB sync_break_complete; TXEN enabled; SYNC asynchronous; BRGH hi_speed; CSRC slave;
SP2BRGL = 0x54; // Baud Rate = 57600; SP2BRGL 84;
SP2BRGH = 0x00; // Baud Rate = 57600; SP2BRGH 0;
Reset_EUSART2_Tx_Buffer();
Reset_EUSART2_Rx_Buffer();
TMR4_Initialize_57600();
PIE3bits.RC2IE = 1; // enable RC2 interrupt
}
 
I believe it is exactly the same as what is produced by MCC.
 
 
 
 
 

好的，这是波特率57826，所以只有0.4%的错误，尽可能接近。所有其他中断都有效吗？其他代码中有慢代码吗？您的ISR从不检查溢出标志。



      以下为原文

    ok, that's giving a baud rate of 57826, so only 0.4% error, and as close as you can get.
Are all those other interrupts active?
Any slow code in the other ones?
Your ISR is never checking the overflow flag.
 
 

TMR4中断在每个字节之后被激活。我目前只运行一个EUSAT的测试代码，但是我可以显式地禁用在中断程序管理器C中提到的所有其他中断。如前所述，运行在9600的代码很好，至少有20字节数组。我不能用57600得到一个字节！现在是新的一天，我也会在它上面扔一个字节序列，并把它记录在范围内，检查传入的字节流的时间。我已经删掉了那里的代码，现在下降到非常少的数量。前面正在检查溢出标志。我认为输入源于一个应该有垃圾的MC2200。在我看来，溢出的可能性是不可能的。在MCC的简单设置中有一个嘀嗒框，上面写着“启用连续接收”，这是我不确定的。我想知道这是否起了作用？



      以下为原文

    The TMR4 interrupt is activated after each byte.  I'm only running test code for the one EUSART at present but I could explicitly disable every other interrupt mentioned in the interrupt_manager.c I guess.  As mentioned previously, the code running at 9600 is fine with at least a 20 byte array.  I can't get one byte correct with 57600 !
 
Now that it is a new day I'll also throw a byte sequence at it and record it on the scope to check the incoming byte stream for timing.
 
I've cut out code that was there and am now down to a very scant amount.  The overflow flag was being checked previously.  I figure that the incoming is sourced from a MCP2200 that should have its junk in place.  To my mind, the likelihood of an overflow is unlikely.
 
There is a tick box in the Easy Setup of MCC that speaks of 'Enable Continuous Receive' that I'm not sure about.  I wonder if this plays a part ?

这将排除中断处理程序的问题。



      以下为原文

   
 
That would rule out an issue with the interrupt handler.

你能把字符序列CP2200发送到PIC和你在程序中接收到的序列吗？



      以下为原文

    Can you post the character sequence MCP2200 sends to the PIC and the sequence you receive in your program?

嗯，现在在任何图片上第一次获得“程序内存错误”。虽然PM3表示当擦除设备时，设备被擦除，但空白检查失败。我用的是一个旧的PM3。但是请让我先更换芯片。



      以下为原文

    Hmmm...
 
Now getting "Program Memory Errors" for the first time ever on any PIC.  Although the PM3 says the device is erased when I erase it the Blank Check fails.  I'm using an older PM3.
 
@ NorthGuy Sure!  But let me change the chip first please.
 

让我们再试一次…从PM3到板的领先优势…



      以下为原文

    Lets try that again ... 
A busted lead from PM3 to board ... 
 

好的-我刚刚切换到19200，结果非常好。这里是9600个测试结果，大约有57600个结果被钉在末端。我需要稍微解释一下。我有一个4字节的开始和结束的“帧”，这些是A2 19，63和38在开始和E4 9D 52和29在结束。第五字节是一个帧长度字节，所以在这个阶段的最小帧是A2 19，63，38，09，E4，9D，52，29（按这个顺序）。在接收流中看到的输出显示了用冒号（3AH）分隔的帧头和页脚。因此，在开始（复位后）的冒号是正确的。然后FRA的8字节。ME页眉和页脚。然后是另一个冒号。然后有5个字节的兴趣。一个用于TMR4超时的字节（TMR4使用LFIFTSC）。因此，27小时是39个小数的32.768千赫时钟或大约（1.19M）-一个字节为“预期长度”-一个字节为“好的COMs”-一个字节的“坏的COMs”-一个字节的最后一个值的RxHeadThen殖民地，前16个字节的接收缓冲区，然后殖民地的前16个字节的“共用”BUF。FER不包括帧头和页脚-在最小的情况下，它只包含09h的预期长度（它确实）。最后，冒号。嘿！在32.768 kHz LFIFOTC上，57600的计数值是6。这可能是个问题吗？也许我应该提高这个数值，只是为了看看…



      以下为原文

    OK - I've just switched to 19200 and the results are perfectly fine...
 
Here is the 9600 test results with some 57600 results tacked onto the end. I will need to explain things a little. I have a set of 4 bytes for the start and end of a 'frame' these are A2 19 63 and 38 at the start and E4 9D 52 and 29 at the end. The fifth byte is a frame length byte.
So a minimum frame at this stage is A2 19 63 38 09 E4 9D 52 29 (in this order).
The output as seen in the received stream shows those frame headers and footers separated with colons (3Ah).
So a colon at the start (after a reset) is correct.
Then 8 bytes of the frame header and footer.
Then another colon.
Then there are 5 bytes of interest.
- A byte for TMR4 timeout (TMR4 is using the LFINTOSC). So 27h is 39 decimal counts of 32.768kHz clock or thereabouts (~1.19ms)
- A byte for 'expected length'
- A byte for 'good comms'
- A byte for 'bad comms'
- A byte for the last value of RxHead
Then a colon
Then the first 16 bytes of a receive buffer
Then a colon
Then the first 16 bytes of a 'comms' buffer that does not include the frame header and footer - in the minimum case it would contain just the expected length of 09h (which it does).
Finally, a colon.
 
Hey! The count value at 57600 is 6 on the 32.768kHz LFINTOSC. Could that be a problem ??
 
Perhaps I should raise that count value significantly just to see...
   Attachment(s)

9600 and 57600 test results.txt (1.07 KB) - downloaded 27 times

TMR4超时从06h到10h看到一些但变化不大的结果。结果是不一致的。注意57600个结果比9600个结果长得多。这对我来说很奇怪。我很确定，我只是改变EUSAT设置和TMR4超时值时，在EUSAT速度之间的变化。TH主代码和各种例程不变。我还应该提到的是，我正在使用一个称为“MyLeal'”的串行监控程序，这是一个非常有问题的软件，我需要重置并配置恰到好处地运行它。任何工作的付费软件提示将不胜感激。



      以下为原文

    Taking the TMR4 timeout from 06h to 10h sees some but little change in results.  The results are not consistent.
 
Note that the results for the 57600 are much longer than for the 9600 results.
This is very strange for me.  I'm pretty sure I'm just changing EUSART settings and a TMR4 timeout value when changing between EUSART speeds.  Th main code and the various routines are unchanged.
 
I should also mention that I am using Linux with a serial monitoring program called 'moserial' which is a very problematic piece of software that I need to be sure to reset and configure just right to get it running.  Any tips on paid software for the job would be appreciated.

这意味着发送端的速度比57600慢，所以接收器看到更多的字符。你检查帧错误吗？你检查了接收器上的信号以确保慢摆率不会引起问题吗？



      以下为原文

   
That implies that the transmitting end is going slower than 57600, so the receiver sees more characters.
Are you checking for framing errors?
Have you checked the signal at the receiver to make sure a slow slew rate isn't causing problems?
 
 

好的，我已经阅读了从PIC上重新发送信息所需的时间。数据流长1.7m，与10个10位字节相关。当我给它数据流时，我得到一个大约为39.85字节的长约为992毫秒的响应。PIC应该发送40字节，所以这是正确的。我的问题是我的串口监控软件叫做MyLeal.这不是我能控制的，但我已经怀疑了一段时间。我不想住在任何靠近Windows环境的地方。



      以下为原文

    OK.
 
I've taken a reading for the length of time it takes to send information from the PIC on reset.  The data stream is 1.7ms long which correlates to 10 10-bit bytes.  When I give it the datastream I get a response that is about 6.92ms long which correlates to 39.85 bytes.  The PIC should send 40 bytes so this is correct.
 
My problem is my serial port monitoring software called moserial.
 
#$%!
 
This is not something I can control but I have been suspect about it for some time.
 
I do not want to live anywhere near a Windows environment.