为什么运行TCPIP将随机延迟插入到外部中断响应时间中

使用Realth.BIT= X代替SET/CLR/IV偏移，以及在ExtIt中断和其他中断或主代码中的掩码也操纵同一寄存器中的其他位。你能显示外部中断处理程序吗？Ruben



      以下为原文

    Using register.bit=x instead of the SET/CLR/INV offsets and a mask in your extint interrupt and other interrupts or maincode also manipulates other bits in the same register?
 
Can you show the external interrupt handler?
 
/Ruben
 

因为我遵循这样的行为的原因，所以我把代码减少到最小。这个项目是评估两个通道信号的任务和相位。因此，外部中断的优先级最高。IAM对信号边缘和ISR输入之间的等待时间笑，但它是C。大约有300个NS，因此它至少不存在。源项目是一个来自TCPIp Server应用程序的实例。仅由外部中断It0进行补充。所有最新版本。



      以下为原文

    Because I follow the reasons for such behavior, I cut the code to a minimum.
 
The project is to evaluate the duty and phase of the two channels signal.
Therefore, the external interruption with the highest priority.
Little i am laughing at the latency between the signal edge and the ISR input,
but it is constantly about 300ns and therefore it does not hinders at least.
 
The source project is an example of a TCPIP Server application from Harmony.
complemented only by an external interruption INT0.
All the latest version.
Development board DM320007 PIC32MZ
 
void __ISR(_EXTERNAL_0_VECTOR, IPL7SRS) _IntHandlerExternalInterruptInstance0(void)
{
    LATHbits.LATH1 = 1; // oscilloscope on the LED and on the input signal
  // cnt1 = _CP0_GET_COUNT();
    LATHbits.LATH1 = 0; // LED1 off
    IFS0bits.INT0IF = 0;
}

 
 

对于PIC32，比特不是原子的，这意味着如果另一个上下文（其他中断或主代码）也使用相同的寄存器，则可以有一个RMW分支，它可以在同一个寄存器中从另一个上下文中撤消一个比特。这对于IFSX寄存器尤其如此，因为它们有几个中断源的位。使用SET/CLR/IV偏移代替，这是原子的，并且没有这个问题。/ Ruben



      以下为原文

    Register.bit is not atomic for PIC32 which means that if another context (other interrupt or main code) is also using the same register, you could have a RMW broblem which can undo a change for a bit from another context in the same register. This is especially true for IFSx registers since they have bits for several interrupt sources.
 
Use the SET/CLR/INV offsets instead, which is atomic, and does not have this problem.
 
/Ruben
 

我已经修改了ISR过程.ValuyO.ISR（外加Sux0Of向量，IPL7SRS），in thand Lead ExaltStistSnices 0（空隙）{LaStSET:0x01；IFS0BIT.It0IF＝0；//清除It0中断标志LAthCLSR＝0x01；}对于通信，我使用了UDP服务器协调模式，其中延迟的变化较小。最好是看到下面的区别。如果DRVMIIMIML初始化，潜伏期是300 Ns。如果我评论初始化，那么延迟的变化小于20NS。如果我知道如何，我将加入PixelelsPPA。



      以下为原文

    I have modified the ISR procedure.
void __ISR(_EXTERNAL_0_VECTOR, IPL7SRS) _IntHandlerExternalInterruptInstance0(void)
{
    LATHSET = 0x01;  
    IFS0bits.INT0IF = 0;  // clear INT0 interrupt flag
    LATHCLR = 0x01;  
 }   
For communication  i used a pattern of UDP server harmony, where there is less change of latency.
The best is seeing the difference from the following.
If DRV_MIIM_Initialize, the latency is 300ns.
if i comment initialization then the change of latency is less than 20ns.
If I knew how, I would join the picture
 
Elsinpa
 
 
 

你完全忽略了MasBube关于如何清除In0F的建议。



      以下为原文

    You totally ignored maxruben's advice about how to clear INT0IF.
 

我正在寻找信号源和ISR输入之间的时间。如果你认为国旗会有这样的效果，我会试试。



      以下为原文

    I am looking for a time between the signal source and the ISR input. If you think the clear flag will have this effect, i will try.
 
Elsinpa

如果你使用在同一寄存器中有中断标志的其他中断源，这可能会导致很难找到的结果，因为在错误之间可能需要很长的时间。



      以下为原文

    It could if you use other interrupt sources that have the interrupt flags in the same register.
 
This could lead to faults that is hard to find since it could take a long time between the faults.
 
/Ruben

我改变了ISR过程.ValuyO.ISR（外加A 0Of向量，IPL7SRS），in thand Lead ExaltStistSnices 0（空隙）{LaStSET:0x01；IFS0CLR＝IFSF0In 0IFIFM掩码；LaTHLRR＝0x01；}没有更好的变化。时钟从和声项目设置为200兆赫。例如，我有100KHz信号。ISR程序每2秒从30ns到100ns扩展一次。输入到ISR 200 ns的恒定延迟也太多。我开始认为它是PIC32 MZ的一个特性。



      以下为原文

    I changed the ISR procedure.
 
void __ISR(_EXTERNAL_0_VECTOR, IPL7SRS) _IntHandlerExternalInterruptInstance0(void)
{
   LATHSET = 0x01;   
   IFS0CLR =_IFS0_INT0IF_MASK;         
   LATHCLR  = 0x01;   
}    
   
There was no change to the better.
Clocks are set from the Harmony project to 200MHz.
For example, i have a 100kHz signal. An ISR procedure
will be extended once every 2 seconds from 30ns to 100ns.
Constant delay of input to ISR 200ns is also too much.
I'm beginning to think it's a feature of PIC32MZ.
 
Thanks
Elsinpa
 
 
 
 
 
 

搜索您的项目并查看IF.BuuthTyNoDabable中断，它禁用全局中断。典型的SythBugTynIdGETAI ISRYSTATE，Y-Bug TynIn Deabable中断和AySuBuffTyNoStIsIrStLATE用于保护代码的关键区域。



      以下为原文

    Search your project and see if __builtin_disable_interrupts, which disables the global interrupt, is ever used. Typically __builtin_get_isr_state, __builtin_disable_interrupts and __builtin_set_isr_state are used to protect critical region of code.  

好的，谢谢。我发现了很多CalsSoalLaCurtIxEnter（OsalaCurtIyType高），它在全局上禁用了中断OsasalCurtIyType高，我改写了OSalalCurtItEnter（OsalaCuriType Type低等），它没有OsalthCurithLead（OsalaCurtIyType低），我做了它没有任何进一步的知识。后果。幸运的是，所有的工作都是按它的方式进行的。两个客户端将不间断地连接到服务器。持续时间大约为200秒，偶尔会有100nS的延迟变化，导致我在UDP服务器中使用SysTyTMR。我没有看到中断的进一步工作。



      以下为原文

    OK thanks.
I found a lot of calls
OSAL_CRIT_Enter (OSAL_CRIT_TYPE_HIGH) which globally disable the interruption
OSAL_CRIT_Leave (OSAL_CRIT_TYPE_HIGH)
I rewrote the code with
OSAL_CRIT_Enter (OSAL_CRIT_TYPE_LOW)   which does nothing.
OSAL_CRIT_Leave (OSAL_CRIT_TYPE_LOW)

I did it without any further knowledge of the consequences. Fortunately, everything works as it should.
Two clients will connect to the server without fails.
Changes in latency dropped rapidly. The constant latency of about 200ns remains.

There are occasional latency changes 100ns that leads me to the SYS_TMR used in the UDP server.
I do not see any further work on disabling of the interruption.
 
Elsinpa

你应该告诉我们你在使用自由球员。什么是配置Max？OSALLCRITIAN（）不禁用全局中断，而是将当前执行的IPL提升到LealFixMax MySyCalLyBaseTypRePrOrthItIt，从而防止“系统中断”发生。函数状态的注释：您的外部中断设置在优先级7，最高，SOSOALLCRITIZIN（）不应该影响外部中断延迟，只要配置Max SysCalAlx中断优先级不在7。我希望您不认为ISR属性中的IPL7SRS设置了外部中断优先级。



      以下为原文

   
You should tell us that you were using FreeRTOS. What is configMAX_SYSCALL_INTERRUPT_PRIORITY set at? OSAL_CRIT_Enter() does not disable the global interrupt but raises the current execution's IPL to the level configMAX_SYSCALL_INTERRUPT_PRIORITY is at, thus preventing "system interrupt" from happening. The comment for the function states:

 
Your external interrupt is set at priority 7, the highest, so OSAL_CRIT_Enter() should not impact the external interrupt latency as long as configMAX_SYSCALL_INTERRUPT_PRIORITY is not at 7.  I hope you don't think that the IPL7SRS in ISR attribute sets the external interrupt priority.
 

我使用“TCPIpU-UppServer”和声示例。如果我知道FrRotos不被使用。在MHC中没有检查/有init进程空隙SysSyListI化（空洞*数据）{SysLCKLIQualI化（NULL）；SysSyDeNCONRY初始化（SysSeDeCurnInsixLox0，（SysSimuleMyInit）空）；SysSyDeNoviPrimeCycFig（SysSLCKYSythValueCyGET（））；SysPosisSimulalIZE省（）；SysObj.DrVMIIM= DR；索引x0，（const SysMeuleMexI**const）和（DrvmiMimItDATA）；SysObj.DrvtMR0= DrviTMR*初始化（DrviTrMyLoxxx0，（SysSimeMeuleInI*）和DrvtMR0IITDATA）；SysObj.DrvtMR1= DrviTMR*初始化（DRVIVTMRIX索引X1，（SysSimeMeuleII**）和DRVTMR1IITDATA）；VI- Mimimi初始化（Drvmimim）RyTySt（IntVoTraceT2，InPialTyryLeal4）；SysStInTyVoTraceRyLyLe0.0；SysSytInVoTrRePrimeRealSyt集合（InthVoTraceT1，InPosiRyTyLeLe1）；SysSytInVoCube PrimoRealSyt集（IntVCtoReT1 T1，InSub PrimoRealIyLe0）；SysIntIn RealSaleIZE（）；PysS0x765632；SysInSysStInTyVoCuthPrimeRealSt集（InthVoTraceIn0，InSub PrimoRyTyReal3）；SysSytIn外部中断TrutGrGeSt（InExtAuthalAuthIn SooSureC0，InEdEdGeTeGeReGueLead）；SysSytIn VECRTRORYPRORITY SET（IntViTraceIt1，InPialTyrIyLeal6）；SysSytIn向量SuthPixRealTySt集（IntViTraceIt1，InSub PrimoRyTyLeLe3）；SysSytInAutoTraceTrimeGeC1，IntEdGeGeTraceGyLead；IEC0SET＝IIE00In0IIa掩码；//启用In0ISR IEC0SET＝IEC0In I1掩码；/ /启用Int1-ISR SysObj.SyrMy= SysTrMRX初始化（SysthTMR.Idxx0），（const）SysSytIngVeltRePiTrimeSt集（InthValtoReTythEnter，InPrimRythyLeal5）；SysSytInvValpSePrimoRealSt集（InthVoCTREST，InSub PrimoRyTyLeReal3）；SysObj.TCPIp＝TCPIpsi-StaskIn（）；SysIntIn Abable（）；



      以下为原文

    I use the "tcpip_udp_server" harmony example. If I know FreeRTOS is not used. / In MHC not checked /.
There is init procedure
 
void SYS_Initialize ( void* data )
{
    SYS_CLK_Initialize( NULL );
    SYS_DEVCON_Initialize(SYS_DEVCON_INDEX_0, (SYS_MODULE_INIT*)NULL);
    SYS_DEVCON_PerformanceConfig(SYS_CLK_SystemFrequencyGet());
    SYS_PORTS_Initialize();
    BSP_Initialize();       
    sysObj.drvMiim =   DRV_MIIM_Initialize (DRV_MIIM_INDEX_0,  (const SYS_MODULE_INIT  * const)       &drvMiimInitData);
    sysObj.drvTmr0 = DRV_TMR_Initialize(DRV_TMR_INDEX_0, (SYS_MODULE_INIT *)&drvTmr0InitData);
    sysObj.drvTmr1 = DRV_TMR_Initialize(DRV_TMR_INDEX_1, (SYS_MODULE_INIT *)&drvTmr1InitData);
    SYS_INT_VectorPrioritySet       (INT_VECTOR_T2, INT_PRIORITY_LEVEL4);
    SYS_INT_VectorSubprioritySet (INT_VECTOR_T2, INT_SUBPRIORITY_LEVEL0);
    SYS_INT_VectorPrioritySet       (INT_VECTOR_T1, INT_PRIORITY_LEVEL1);
    SYS_INT_VectorSubprioritySet (INT_VECTOR_T1, INT_SUBPRIORITY_LEVEL0);
    SYS_INT_Initialize();
    PRISS = 0x76543210;       
    SYS_INT_VectorPrioritySet                (INT_VECTOR_INT0, INT_PRIORITY_LEVEL7);
    SYS_INT_VectorSubprioritySet           (INT_VECTOR_INT0, INT_SUBPRIORITY_LEVEL3);
    SYS_INT_ExternalInterruptTriggerSet (INT_EXTERNAL_INT_SOURCE0,INT_EDGE_TRIGGER_RISING);
    SYS_INT_VectorPrioritySet                (INT_VECTOR_INT1, INT_PRIORITY_LEVEL6);
    SYS_INT_VectorSubprioritySet          (INT_VECTOR_INT1, INT_SUBPRIORITY_LEVEL3);
    SYS_INT_ExternalInterruptTriggerSet(INT_EXTERNAL_INT_SOURCE1,INT_EDGE_TRIGGER_FALLING);
    IEC0SET =_IEC0_INT0IE_MASK;      // enable INT0 ISR  
    IEC0SET =_IEC0_INT1IE_MASK;     // enable INT1 ISR   
    sysObj.sysTmr  = SYS_TMR_Initialize(SYS_TMR_INDEX_0, (const SYS_MODULE_INIT  * const)&sysTmrInitData);
    SYS_INT_VectorPrioritySet             (INT_VECTOR_ETH, INT_PRIORITY_LEVEL5);
    SYS_INT_VectorSubprioritySet       (INT_VECTOR_ETH, INT_SUBPRIORITY_LEVEL3);
    sysObj.tcpip = TCPIP_STACK_Init();
    SYS_INT_Enable();
    APP_Initialize();
}


Thank you
Elsinpa

有人知道MIIM引擎通信如何影响PIC32 MZ中断系统吗？如果我把PIC通信到PHY，那么一切都会好的。下面的代码。感谢ElsPaPlbBIB模板空隙，EthyMiMeWrdEdaseTeLead（EthoMeuleSodeID索引，UInt160t Wrad Dead）{易失性EthyRealStass*t*Eth=（（EthyReaveSts**）（index））；Eth-Gt；EMACXMWTD.MWTD= WordEDATA；}



      以下为原文

    Does anyone know how the MIIM engine serial communication could affect the pic32mz interrupt systém?
If I comment communication of PIC to PHY, then everything is OK. Code below.
Thanks Elsinpa
 
PLIB_TEMPLATE void ETH_MIIMWriteDataSet_Default( ETH_MODULE_ID index , uint16_t writeData )
{ volatile eth_registers_t * eth = ((eth_registers_t *)(index));  
   eth->EMACxMWTD.MWTD =writeData ; 
}

MIPS（PIC32中的底层CPU）对嵌套中断没有任何本地支持。当中断发生时，CPU自动禁用所有中断。编译器生成的ISR处理程序必须保存一些寄存器，改变中断优先级，然后重新启用中断。这需要一些时间，如果在这段时间内发生更高优先级的中断，这种中断将被推迟。避免延迟增加的唯一方法是完全禁用所有其他中断。然而，即使如此，ISR执行的速度将取决于是否缓存。为了规避这个因素，你需要禁用高速缓存（或者可能在缓存中有创造性地将中断代码保存在缓存中）。当然，如果使用DMA，则不适用，但是还有其他未知的东西，如总线争用等。如果你想要固定的延迟和可预测性，SWIT。CH至PIC24／33。



      以下为原文

    MIPS (the underlying CPU in PIC32) doesn't have any native support for nested interrupts. When an interrupt happens, the CPU automatically disables all interrupts. The ISR handler generated by the compiler will have to save some of the registers, change interrupt priority and then re-enable the interrupts. This does take some time, and if a higher priority interrupt happens during this time, such interrupt will be postponed. The only way to avoid the increase in latency is to disable all other interrupts completely.
 
However, even then the speed of the ISR execution will depend on whether it is cached or not. To circumvent this factor, you need to disable cache (or perhaps get creative with the cache to keep the interrupt code in the cache at all times).
 
Of course, if you use DMA this doesn't apply, but there are other unknowns such as bus contention etc.
 
If you want fixed latency and predictability, switch to PIC24/33.
 

嗨，关于PIC32 MZ300的中断延迟有几个窍门，关于在80 MHz运行时在PIC32 MX上可以实现什么，并且必须跳2跳才能进入ISR码。PIC32 MZ应该有可能比PIC32 MX快，PIC32 MZ有一个EVE存储器地址的CPU寄存器。Ry ISR向量，因此只需要一跳就能进入ISR代码。然后有一组SRS寄存器可用于每一个优先级。请确保告诉编译器FPU将不在高优先级中断代码中使用。请仔细阅读XC32编译器用户指南、数据表和家庭ReFrand手册、中断部分中的第14章。迈西尔



      以下为原文

    Hi,
There are several tricks around interrupt latency for PIC32MZ
300 us is about what can be is achieved on PIC32MX when running at 80 MHz,
and having to do 2 jumps to get into ISR code.
 
PIC32MZ should have the possibility to be faster than PIC32MX,
PIC32MZ have a CPU register for memory address of every ISR vector, so should need only one jump to get into ISR code. Then there is a set of SRS registers available for every priority level.
Make sure to tell compiler that FPU will not be used in the high priority interrupt code.
 
Read carefully chapter 14 in XC32 Compiler User Guide, Datasheet and  Family Refreence Manual, Interrupt section.
 
   Mysil