PLIB PORTS PinWrite与PLIB PORTS PinSet有什么区别？

记录在案？http://MyCHIPCDeave/COMQue:PLIB端口



      以下为原文

    as documented ?
http://microchipdeveloper.com/harmony:plib-ports
 

那有什么微妙的差别呢？PiBixPosissPoWrand（PoxsIdIy0，PothChhannEngC，PoxsS.BiPosiPosi4，1）将一个“1”写到RC4PLIB PosisSpISET（PoxsSIDID0，PothChhannLya，PoxsS.BiToPase2）设置RA2 PIN高（我假设与端口VS LAT有关的东西，但我不确定……）



      以下为原文

    funny
what's the subtle difference in there, then?
PLIB_PORTS_PinWrite (PORTS_ID_0, PORT_CHANNEL_C, PORTS_BIT_POS_4, 1)
Writes a "1" to RC4
PLIB_PORTS_PinSet (PORTS_ID_0, PORT_CHANNEL_A, PORTS_BIT_POS_2)
Sets RA2 pin high
 
(I assume something related to PORT vs LAT, but am not sure...)

聪明，没有什么关于LAT写，所以它可以。从语法，它看起来像使用PICSET，我们不必指定1在辩论结束。两个都做同样的事情，然而，为什么微芯片创建两个功能？它可能是LAT相关的吗？



      以下为原文

     
clever, there is nothing about LAT write so it could be.
from the syntax, it looks like using Pinset we don't have to specify 1 at the end of arguments.
both are doing the same thing, however, so why microchip create two functions? could it be LAT related?
 
 

实现揭示了令人震惊的差异：PunSe:PixLe: Prime:PbIbPosisSpSSET（）可以设置一个PIN，而PLIPHPurthsPin（）可以清除一个PIN，而PLIPBIX PosisPoWrice（）可以同时做到这两个！太棒了！-）http://MyCHIPCDeave/COMPION: PLIB API PosiSIS是一个更好的链接。



      以下为原文

    Implementation reveals the shocking difference:
 
PinSet:

PLIB_INLINE_API void PLIB_PORTS_PinSet(PORTS_MODULE_ID index, PORTS_CHANNEL channel, PORTS_BIT_POS bitPos)
{
PORTS_PinSet_MCU32_PPS(index, channel, bitPos);
}PLIB_TEMPLATE void PORTS_PinSet_MCU32_PPS( PORTS_MODULE_ID index , PORTS_CHANNEL channel , PORTS_BIT_POS bitPos )
{
*(&LATBSET + (channel - 1) * 0x40) = 1<
}
PinClear:
PLIB_INLINE_API void PLIB_PORTS_PinClear(PORTS_MODULE_ID index, PORTS_CHANNEL channel, PORTS_BIT_POS bitPos)
{
PORTS_PinClear_MCU32_PPS(index, channel, bitPos);
}
PLIB_TEMPLATE void PORTS_PinClear_MCU32_PPS( PORTS_MODULE_ID index , PORTS_CHANNEL channel , PORTS_BIT_POS bitPos )
{

*(&LATBCLR + (channel - 1) * 0x40) = 1<
}
PinWrite:
PLIB_INLINE_API void PLIB_PORTS_PinWrite(PORTS_MODULE_ID index, PORTS_CHANNEL channel, PORTS_BIT_POS bitPos, bool value)
{
PORTS_PinWrite_MCU32_PPS(index, channel, bitPos, value);
}PLIB_TEMPLATE void PORTS_PinWrite_MCU32_PPS( PORTS_MODULE_ID index , PORTS_CHANNEL channel , PORTS_BIT_POS bitPos , bool value )
{
/* Atomic Implementation */
if(value == true)
{
*(&LATBSET + (channel - 1) * 0x40) = 1< }
else
{
*(&LATBCLR + (channel - 1) * 0x40) = 1< }
}
 
PLIB_PORTS_PinSet() can set a pin, and PLIB_PORTS_PinClear() can clear a pin, and PLIB_PORTS_PinWrite() can do BOTH! That's amazing! ;-)
 
http://microchipdeveloper.com/harmony:plib-api-ports is a better link.

如果您检查生成的程序集代码，我确信集合和清晰版本将生成更高效的代码。



      以下为原文

    If you examine the assembly code produced, I'm pretty sure the set and clear versions will generate more efficient code.
 

我一直在快速阅读，所以我错过了最新的参数，所以，现在它是有意义的，是的，我同意QHB是第一个更快。仍然怀疑写信给PORTx…（！）



      以下为原文

    I had been reading quickly so I missed the latest parameter
So, well, now it makes some sense, and yep I agree with QHB being the first one faster.
 
Still wondering about a Write to PORTx... (!)

我猜当PinWrite不确定在编写代码时设置或清除PIN时应该使用。如果有人确定，那么PinSet /晴朗应该被使用。



      以下为原文

    i guess PinWrite should be used when one is not sure of setting or clearing the pin while writing the code. if one is sure about it, then PinSet/Clear should be used.

如果我们谈论的是O1或更高，我相信你错了。我认为它们在大多数情况下是相等的。如果您提供一个常数第四参数toPLiBiPurthsPiWrrEnter（），编译器会将其优化为相同的代码ASPLIPHPORTSUPSESET（）OrpBixPosisSpIn（）。所有这些函数都是内联定义的，编译器将内嵌代码。然后，它能够识别类似的语句，并将其优化为两种情况中的一种。据我所知，编译器可以在-O1上完成这个操作。因此，PrimbPosisSpWordWrand（）与常数FoeTo参数和PLIPHPtassPin StUSER（）OrpBixPosisPin（）之间不会有区别。您可以在SSNOPS之间看到相同的11条指令，尽管一个示例使用2x PrCuffe（），另一个使用Pin StUSER（）和PcCurrar（）。如果您提供了一个变量第四参数toPLIPHPurthsPiWrrEnter（），则不能直接用PLIPHPurthsPin StUSER（）和PLIPBH.PursSpIn（）替换它。必须做你自己的if语句或其他什么，例如：我还没有测试过，但是这是相同的aspBixPosisPiWrnWrice（）正在做的。但是因为在其他情况下，调用不能逐个替换，它可能依赖于代码，甚至依赖于优化级别。例如，考虑这样的情况：这等于：我不知道编译器是否会将这两个例子与O-1相同的代码优化，因为编译器必须合并两个if情况（一个是代码，一个是在CopReWrE（）里面）。但我期望在更高的优化水平上也是如此。



      以下为原文

   

I'm believe you are wrong about this, if we talk about -O1 or higher. I think they are equal in most cases.
 
If you provide a constant fourth parameter to PLIB_PORTS_PinWrite() the compiler will optimize it to the same code as PLIB_PORTS_PinSet() or PLIB_PORTS_PinClear(). All those functions are defined inline and the compiler will inline the code. Then it is able to recognize statements like
if( constant_expression_evaluating_always_to_true_or_always_to_false ) {
    // some code
} else {
    // some other code
} and optimize it away into one of the two cases. As far as I know the compiler can already do this on -O1. Therefore, there won't be a difference between PLIB_PORTS_PinWrite() with constant forth parameter and PLIB_PORTS_PinSet() or PLIB_PORTS_PinClear().
 
I have attached two pictures with a short test. You can see the same 11 instructions between the SSNOPs although one example uses 2x PinWrite() and the other one uses PinSet() and PinClear().
 
If you provide a variable fourth parameter to PLIB_PORTS_PinWrite() you cannot directly replace it with PLIB_PORTS_PinSet() and PLIB_PORTS_PinClear() and you have to do your own if statement or whatever, for example:
if(variable) {
    PLIB_PORTS_PinSet( /*parameters*/ );
} else {
    PLIB_PORTS_PinClear(  /*parameters*/ );
}
I haven't tested that one, but that is the same as PLIB_PORTS_PinWrite() is doing. But since the calls can not be replaced one-by-one in other cases, it might be dependent on your code and even the optimization level. For example, consider a situation like:
if(variable) {
    // some code here
    PLIB_PORTS_PinSet( /*parameters*/ );
} else {
    // some other code here
    PLIB_PORTS_PinClear(  /*parameters*/ );
}
Which is equal to:
if(variable) {
    // some code here
} else {
    // some other code here
}
PLIB_PORTS_PinWrite(  /*parameters*/, variable );
I don't know if the compiler will optimize even those two examples to the same code with -O1, because the compiler would have to merge two if-cases (the one with your code, and the one inside PinWrite()). But I expect that it will be the same with higher optimization levels.
   Attached Image(s)