两个不同ISR中的端口访问，优先级高于另一个

HI，如果低级操作不是单周期的，则总是有可能出现问题……一个解决方案（从实时的观点来看是可接受的）是通过在临界段之后禁用中断并重新启用它们来使代码段成为原子。



      以下为原文

    Hi,
If low level operations are not single cycle, there is always a possibility of issue...
One solution (when acceptable from real-time point of view) is to make a section of code atomic by disabling interrupt before and re-enabling them after the critical section.
Regards
 

Hi，“LATASET＝LATAYA LATA0X掩码”，根据硬件设计是原子的，但是是否有其他依赖于更高优先级中断可能改变的任何状态信息的情况？例如，如果测试PORTA的值，然后执行LATASET=…那么组合操作不是原子的，即使每个语句本身都是原子的。迈西尔



      以下为原文

    Hi,
"   LATASET =  _LATA_LATA0_MASK; "
is atomic according to the hardware design.
But is there anything else that depend on any state information that may be changed by the higher priority interrupt?
E.g.  If testing the value of PORTA, and then doing LATASET = ...
then the combined operation is Not atomic, even if each statement is atomic in itself.
 
   Mysil

嗨，我会亲自检查汇编代码生成…问候



      以下为原文

    Hi,
 
I would personally check the assembly code generated...
 
Regards

是的，围绕着我的ADC CS集，ADC CS CLR：图形离线集：图形离线CLR：看起来还行吗？



      以下为原文

    yes been rooting around the assembly
 
for my ADC CS set:
! pbAdcCSSet();    // {LATASET=_LATA_LATA0_MASK;}
0x9D039360: ADDIU V1, ZERO, 1
0x9D039364: LUI V0, -16506
0x9D039368: SW V1, 56(V0)
 
ADC CS clr:
! pbAdcCSClr();    // {LATACLR=_LATA_LATA0_MASK;}
0x9D039AA0: LUI V0, -16506
0x9D039AA4: SW V1, 52(V0)
 
graphics DE line set:
! pbLcdDataEnableSet()   // {LATASET=_LATA_LATA6_MASK;}
0x9D049FE4: ADDIU V1, ZERO, 64
0x9D049FE8: LUI V0, -16506
0x9D049FEC: SW V1, 56(V0)
 
graphics DE line clr:
! pbLcdDataEnableClr()  // {LATACLR=_LATA_LATA6_MASK;}
0x9D049E48: LUI V0, -16506
0x9D049E4C: SW V1, 52(V0)
 
Seems ok?
 

是的，相同的代码和相同的寄存器：中断处理程序PROLCON代码应该是在进入时保存CPU寄存器的内容，并在中断EXORG代码中保存返回的内容。这样，V0和V1寄存器在从中断返回时返回正确的值。GistSet使用，然后可能发生奇怪的事情：例如，如果在ISR函数定义中指定SFR寄存器集的使用，但是SFR寄存器的使用没有被正确初始化，或者如果中断优先级7和中断优先级2被分配使用相同的SFR寄存器集，那么消息在5月1日发生。检查PRISS寄存器的内容并用数据表检查值是否有意义。检查ITCCON寄存器的内容，并检查MVEC位是否已正确设置。迈西尔



      以下为原文

    Yes, same code and same registers:
 
Interrupt handler Prolog code is supposed to save contents of CPU registers when entering, 
and put back what was there, in interrupt Epilog code.
Such that V0 and V1 registers get back their proper values when returning from interrupt.
 
If there is some mixup in SFR register set usage, then strange things may happen:
e.g. if use of SFR register set is specified in ISR function definition,
but use of SFR registers is not correctly initialized,
or if interrupt priority 7 and interrupt priority 2 is assigned to use the same set of SFR registers,
something like described in message #1 may happen.
 
Examine contents of:   PRISS  register and check with datasheet that values make sense.
Examine contents of:   INTCON register, and check that MVEC bit have been correctly set.
 
   Mysil

谢谢Mysil，是的，PrISS设置好了：中断函数头：ItCON.MVEC位设置通过：它似乎都设置了Huky DOORY，但是这个问题偶尔会发生，并在LCD上引起严重的打嗝。禁用任何对PoA的写入中断都会修复它，但我想所有的阴影。寄存器设置PIC32 MZ有这个不必要的



      以下为原文

    Thanks Mysil, yes PRISS is set up ok:
 
    PRISSbits.PRI1SS = 1;
    PRISSbits.PRI2SS = 2;
    PRISSbits.PRI3SS = 3;
    PRISSbits.PRI4SS = 4;
    PRISSbits.PRI5SS = 5;
    PRISSbits.PRI6SS = 6;
    PRISSbits.PRI7SS = 7;

 
Interrupt function headers:
void __attribute__((vector(_TIMER_3_VECTOR), interrupt(IPL2SRS), nomicromips)) Timer3Interrupt(void)
void __attribute__((vector(_DMA1_VECTOR), interrupt(IPL7SRS), nomicromips)) DmaHandler1(void)
 
INTCON.MVEC bit set via:
INTCONSET = _INTCON_MVEC_MASK; // set multi vector mode
 
It all seems to be set up hunky dory but this problem does happen sporadically and causes a nasty hiccup on the LCD.
 
Disabling interrupts around any writes to PORTA has fixed it but I thought with all the shadow register sets the PIC32MZ has that this shouldn't be necessary
 
 

编辑：这篇文章忽略了这个问题。我想这很清楚。您没有任何问题与端口寄存器写入或清除。你的问题是你不知道你什么时候写这个或写清楚。你的ADC代码只做了以下几点：你的图形LCD代码ALONE做如下：如果你的中断在错误的地方出现，结果是明显的：所以你的ADC的CS太早就被清除了。我不知道你的DISI是怎么做的。GN应该工作。如果设置CS线路，ADC和LCD如何知道，你想与哪两个通信？在中断之后，这种机制可能也会变得混乱。CS对ADC或LCD有意义，并对其进行帧通信？首先，是否有可能中断你正在使用ADC所做的事情，而与LCD进行通信，然后继续使用ADC的东西？如果答案是“否”，那么你需要通过禁用LCD中断之前的ADC代码部分原子，并在关键部分之后重新启用它们，如RISC所描述的。或者可以更改优先级设置，并将LCD中断置于与ADC中断相同的级别，这样它们就不能相互中断。在这两种情况下，中断可能彼此延迟。如果答案是“是”，那么您也可以检查LCD中断代码，CS是否已经设置，并且在LCD中断结束时仅在尚未设置CS时重置CS。然而，要小心，因为你可以很容易地犯很多错误，这是很难察觉的。



      以下为原文

    Edit: This post misses the issue. See below.
 
I think this is quite clear. You don't have any issue with writes or clears with the port register. Your issue is that you don't know when you want to do this write or clear.
 
Your ADC code alone does the following:
set chip select
do some ADC stuff (while chip select is set)
do some more ADC stuff (while chip select is set)
clear chip select
Your graphics LCD code allone does the following:
- LCD interrupt occurs
- set chip select 
- do some LCD stuff (while chip select is set)
- clear chip select
- LCD interrupt finished
The result is obvious, if your interrupt hits at the wrong place:
set chip select
do some ADC stuff (while chip select is set)
- LCD interrupt occurs
- set chip select 
- do some LCD stuff (while chip select is set)
- clear chip select
- LCD interrupt finished
do some more ADC stuff (WHILE CHIP SELECT IS NOT SET !!!)
clear chip select
So your CS for the ADC gets cleared too early.
 
I don't know how your design is supposed to work.
 
If you set the CS line, how does your ADC and LCD know, to which of the two you want to communicate? Probably this mechanism also gets confused, after the interrupt.
 
And does the CS have a meaning to the ADC or LCD and frame the communication?
 
 
And in the first place, is it even possible to interrupt the stuff you are doing with the ADC, and communicate with the LCD instead, and then continue with the ADC stuff?
 
If the answer is "No" then you need to make the ADC code section atomic by disabling the LCD interrupt before and re-enabling them after the critical section, as described by RISC. Or you could change the priority settings, and place the LCD interrupt at the same level as the ADC interrupt, so they cannot interrupt each other. In both of these cases, the interrupts may delay each other.
 
If the answer is "Yes" then you could also check in the LCD interrupt code, whether the CS is already set, and at the end of the LCD interrupt reset the CS only if it was not already set. However, be VERY careful with that, because you can easily make a lot of mistakes, which are hard to detect. 
 

上面的代码显示他们使用单独的芯片选择。而且，使用设置/清除寄存器，修改一个不应该影响另一个。



      以下为原文

   
The code posted above shows them using separate chip selects. And, using the SET/CLEAR registers, modifying one should not affect the other.

是的，ANDSRM，它们是分开的线，ADC CS是LATA0，LCD数据使能线是LATA6，没有LCD的CS线（无论如何我使用）问题是，有时，当我的LCD DMA中断处理器中断我的ADC中断处理程序，而它是切换LAT0（ADC CS），我想要设置LATA6低（L）CD数据启用后水平后廊），但回到ADC中断，完成设置LATA0低可以以某种方式反转LATA6，这扰乱了我的液晶显示时序。



      以下为原文

    Yes, andersm, they are separate lines, ADC CS is LATA0, LCD data enable line is LATA6, there is no CS line for the LCD (that I use anyway)
 
The issue is, sometimes, when my LCD DMA interrupt handler interrupts my ADC interrupt handler, while it is toggling LAT0 (ADC CS) I want to set LATA6 low (for LCD data enable after the horizontal back porch).
 
But on going back to the ADC interrupt, finishing setting LATA0 low can somehow invert LATA6 and this messes up my LCD timing.
 
 

这很清楚！提示：有两个芯片选择。



      以下为原文

   


That's very clear!
 
Hint: There are two chip selects.

我已经成功地使用Cabo逻辑分析仪捕获它，请参阅这里所示的附加图像错误：它应该如何正常运行：这里，LCD DE线被LCD DMA中断处理程序拉低，并且保持低电平。



      以下为原文

    I have managed to capture it using a cheapo logic analyser, please see attached image(s)
 
Error shown here:

 
 
How it should behave and normally does:

Here, the LCD DE line is pulled low by the LCD DMA interrupt handler and remains low

哦，对不起。当你写“同一个端口”时，我不知怎么地在读“同一个PIN”……所以，忘了我的帖子。



      以下为原文

    Oh, sorry. When you wrote "same PORT" I was somehow reading "same pin" ... 
 
So, just forget my post.

你能用一个设置在LATA写上的断点运行调试会话吗？如果所有端口A的写入都是使用LATASET/CLR/IV完成的，那么这个断点就永远不会被击中。



      以下为原文

    Can you run a debug session with a breakpoint set on LATA write? If all port A writes are done using LATASET/CLR/INV, then this breakpoint should never hit.

在使用之前，这两个序列都没有设置V1。我假设它设置在较早的地方，但是不可能看到代码的其余部分。



      以下为原文

   


None of these two sequences sets V1 before using it. I would assume it is set somewhere earlier. But, impossible to see the rest of the code is.
 

如果V1被“损坏”，当使用一个CLR寄存器时，如果V0被“损坏”，你仍然看不到LATA6的高值，那么你会看到一个丢失的ADC CS变低（写入错误的寄存器），或者可能是总线故障（？）似乎需要一个特定的组合（当使用SET/CLR/IV）时，如果两者都被“破坏”，V1位6将需要被设置，V0将需要是+8来击中IV寄存器-获得LaTaVIn＝BIT 0比特6 -导致CS反相（转到低）和LCD去反相（走高）似乎不太可能。组合-不知影子集不起作用，V0和V1“以特定方式导致写向反转的Read必须是比这样的行为更简单的东西——LATA＆AMP:= BIT0（清除CS），然后将有意义的LATA＝BIT0} BIT6（均为高）DMA-IRQ火灾。S HelelATA现在是1比特6，现在回到ADC ISR来完成LATA写和AMP；＝~BIT0LATA＝BIT0} BIT6＆AMP；0xFFFFFFEF= BIT6LATA BIT0＝0（OK），BIT6＝1（坏）DMA IRQ需要在第一个LATA Read和最终写入之间发生，一个小窗口是肯定的，但是它会发生在您显示的CLR／SET函数，但它们真的在ISR中吗？就我们所知，它们只是你所拥有的函数，但不是ADC ISR中使用的函数。



      以下为原文

    if V1 was getting 'corrupted', you still would not see lata6 going high because of a faulty value when using a CLR register
if V0 was getting 'corrupted', you would then see a missing adc cs going low (writing to wrong register), or possibly a bus fault (?)
seems like a specific combo is needed (when using SET/CLR/INV)-
if they both were 'corrupted', V1 bit 6 would need to have been set, and V0 would need to be +8 to hit the INV register- getting a LATAINV = bit0|bit6 - causing cs to invert (go low) and LCD DE to invert( go high)
seems like an unlikely combo- somehow the shadow sets not working, v0 and v1 'corrupted' in specific ways to lead to a write to the invert reg
must be something simpler than that
it certainly acts like this is being used-
lata &= ~bit0 (to clear cs)

and would then make sense-
lata = bit0|bit6 (both are high)
dma irq fires here
lata is now 1- bit6 now clear
back to adc isr to finish lata write
&= ~bit0
lata = bit0|bit6 & 0xFFFFFFFE = bit6
lata bit0 = 0 (ok), bit6 = 1 (bad)
the dma irq would need to happen between the first lata read and the final write, a small window to be sure, but it will happen

you showed the clr/set functions, but are they really in the isr? for all we know they are just functions you have but are not the ones used in the adc isr :)

如何清除中断标志？还使用原子集/ CLR/IV偏移寄存器或寄存器。位＝0？如何操纵ISRS以外的其他端口位？如果你显示代码，帮助你就容易多了。/ Ruben



      以下为原文

    How do you clear your interrupt flags? Also using the atomic SET/CLR/INV offset registers or register.bit=0?
How do you manipulate other port bits outside the ISRs?
 
It would be much easier to help you if you show the code.
 
/Ruben