gpio_direction_output速度跟不上，如何直接控制寄存器？

你用的什么操作系统？实际的用途就是用IO口来做类似PWM波的操作吗？

Steven Liu，您好！我们使用的是linux系统，我想用8个IO口组成一个并口传输数据，当数据量比较大的时候使用gpio_direction_output函数时内核就会比较卡，请问写驱动时怎么可以直接操作寄存器来控制IO口的电平？

在Linux的user space可以通过devmem2 + 物理地址 + w + 值的方式来直接写入数据。

例如 devmem2 0x44e10040 w 0x00000001，就是往0x44e10040这个地址上写0x00000001。

之前在做测试debug的时候用这种方式写过GPIO的寄存器来做拉高拉低的操作，但是考虑到系统的时延，我很怀疑，这个能不能达到你想要的速率和效果。而且这中做法，个人感觉还是会受到当时的系统状态的影响的。可以考虑用我们的PRU的GPO来做这种输出吗？PRU的GPO基本上是可以保证很低时延的输出的。可以参考下面的例子。

Steven Liu，您好！我原来的驱动是使用的gpio_direction_output函数来控制GPIO的，现在发现有延时，要是按照你的提议使用PRU来修改驱动的话是不是改动比较大？而且我对PRU不是太熟悉，请问如何在原来驱动不需要大的改动情况下，有什么方法可以更好的操作GPIO？

ni现在控制GPIO的玩法和PRU的玩法差异还是很大的，而且PRU模块只有AM3356/7/8/9有。

如果就是用原来driver玩GPIO的话，这个delay和系统状态有关，很难固化下来。感觉目前能做的就是用devmem2的访问方式直接去写寄存器，看看这样的操作你是否能跟的上你的应用需求，如果这样也不行的话，那就比较悬了。

话说，一般有这种实时性IO口的应用场景，为啥不采用实时操作系统，诸如sysbios之类的，或者裸跑呢。如果你的GPIO口是为了在Linux下做个PWM之类的功能，建议就直接使用相关的现成模块比价好。普通GPIO口的实时控制在Linux系统下确实不好控制时延。