请问我可以在程序中建立GPIO控制图吗？

请不要在同一个问题上开始多个话题。让我们继续你原来的话题。



      以下为原文

   
Please don't start multiple topics about the same question. Let's just continue in your original topic.

的确.@OP。您需要学习PIC18的汇编语言来理解这一点。这是因为BCF和BSF指令采用一个常量的文字参数来指定位位置。您不能从变量中指定位位置。解决方法是使用带掩码的逻辑AND操作来设置位低，或者使用带掩码的OR操作来设置位高。例如，将设置GPIO寄存器的位6，并且值“0x40”可以来自变量。编辑：现在我们有两个par。关于相同问题的答案



      以下为原文

   
Indeed.
@OP. You need to study the assembly language of the PIC18 to understand this.
It's because the BCF and BSF instructions take a constant literal argument to specify the bit position. You can't specify the bit position from a variable.
The workaround is to use a logical AND operation with a mask to set a bit low, or logical OR operation with a mask to set a bit high.
e.g. GPIO |= 0x40;
will set bit 6 of the GPIO register, and the value "0x40" can come from a variable.
 
 
Edit: And now we have two parallel topics with answers about the same question...

对于两篇要求几乎相同的文章，我感到很抱歉；也许我是一个完美主义者，总是想把事情做得更好，做得最好；我会放弃尝试制作IO控件的地图，像我一样使用示例代码



      以下为原文

    sorry for two post with almost same requirement;
maybe i have been a perfectionist,always want to make things better and best;
i will give up trying to make a map of IO controls,just use sample codes as i have done

如果你从用户那里得到命令，你可能有一个跳转表来容纳用户命令。一个命令=一个跳转表条目。你可以在一个跳转表中有127个。看起来对我来说很重要。所以，我只想让每个动作在跳转表中都有不同的命令。比如说，读GP1上的ADC是一个命令，读GP2上的ADC是一个不同的命令，它将是最适合PIC16的。



      以下为原文

    If you get commands from the user you probably have a jump-table to accommodate user commands. One command = one jump table entry. You can have 127 of them in one jump table. Looks like a lot to me. So, I would simply make every action a different command with its own entry in the jump table. Say, reading ADC on GP1 is one command, reading ADC on GP2 is a different command etc. It'll be the most suitable for PIC16.
 

是的，您显示的与我在编码中所做的类似，但是除了IO的控制变量名称不同，如TRISXbits.TRISXX,LATXbits.LATXX之外，似乎有很多函数都具有几乎相同的代码。



      以下为原文

    yes,your shown is similar with what i have done in my coding,but seems to have many functions with almost same codes except only IO's control variables names are different,like TRISXbits.TRISXX, LATXbits.LATXX

这可以通过位掩码和指向各种端口SFR的指针的组合来完成，但是它通常比使用构建时声明的固定引脚慢两个数量级，因为它需要100个指令的数量级来转换任意引脚号和访问类型i输入所需的指针、掩码和位逻辑运算。你的PIC自然可以切换一个引脚，产生高达2MHz的方波，同时有两条指令可用来根据命令终止循环。我估计所提议的pin抽象层会以几十KHz切换一个pin，如果pin被选择一次，并且您添加代码来缓存指针和位掩码，那么直接使用它们，那么可能是几百KHz。如果不关心Arduino-land级别的性能缺陷，那么就去使用它们！



      以下为原文

    It can be done with a combination of bit-masks and pointers to the various port SFRs, but it will typically be two orders of magnitude slower than using a fixed pin declared at build time because it will need of the order of 100 instructions to translate an arbitrary pin number and type of access into the required pointer, mask and bitwise logic operation.
 
Natively, your PIC can toggle a pin to produce a squarewave at up to 2MHz, with a couple of instruction available to terminate the loop on command.  I estimate the proposed pin abstraction layer would toggle a pin at a few tens of KHz, maybe a few hundred KHz  if the pin is selected once and you add code to cache the pointer and bitmasks, then use them directly.
 
If you don't care about an Arduino-land level of performance suckitude, go for it !

那又怎么样？



      以下为原文

   


So what?

也许我们可以试试使用函数指针数组，这是个好主意吗？



      以下为原文

    maybe we could try using function pointer array,is that a good idea?

是的，如果你有很多命令，那么这是最好的调用方法。这就是跳转表的本质。



      以下为原文

   


Yes, if you have many commands, then it's the best way to call them. That's essentially what the jump table is.

不，访问将和缓存指针和掩码一样快，但是它会使用更多的程序内存，因为每个抽象的引脚需要四个函数，这是15个引脚X 4的函数，但是您节省了一些，因为6个数字只有引脚可以共享同一个哑模拟模式函数，并且您也可以。使用它作为RA3的虚拟输出和方向函数，因此您将节省7，留下53个实际需要的功能。即使将其限制为只有5个用户可访问的PIN，也就是20个功能。还有一个可怕的大交换机，它有25种方法，每个用户PIN和访问类型的组合都是一个，如果你使用定义了的宏来减少实际的重复源代码的数量，这是一个不太坏的方法。只要命令代码是相邻的整数，编译器就应该在PRO模式下生成相当好的代码。



      以下为原文

    No, Access would be about as fast as cached pointers and masks but  it would use more program memory as each abstractable pin would need four functions  That's 15 pins x 4 functions, but you save a few as the 6 digital only pins can share the same dummy analog mode function, and you can probably also use it for dummy output and direction functions for RA3, so you'll save 7, leaving  53  functions actually needed.   Even if you limit it to only the 5 user accessible pins, that's 20 functions. 
 
There's also the horrendously large switch with 25 cases approach - one for each combination of user pin and type of access - that's actually not too bad a way to do it, if you use #defined macros to minimise the amount of actual repeated sourcecode.  As long as the command codes are adjacent integers, the compiler should generate reasonably good code for that in PRO mode.

***



      以下为原文

    ****