Feedback request on software-based PWM support

[ChrisStrykesAgain]

For those familiar with Wiring Pi, there's a "software PWM" function that allows you to use any DO pin for PWM outputs. Yes, that's janky, and no, that's probably not the right way to do it, but I've seen it used a ton in the community, and bought a robot kit that is reliant upon it to work. So, in an effort to use my kit with LabVIEW and not rework a ton of hardware, I wrote a library on top of Linx that accomplishes the task.

You can find it at https://gitlab.com/ChrisStrykesAgain/s-pwm/. I tested it on a Pi3 up to 6 channels and the waveform stayed coherent and the duty cycle was correct, but there's no technical reason you couldn't go beyond that. I just stopped there arbitrarily.

As far as packaging, right now, it's just a bunch of source code. If there's community interest I can actually create a build process to make it a bit nicer, but I didn't need to do it yet for my particular application. 

[jorgemondadori]

That is very nice! i will try in controller a h bridge here and post my feedback

[rolfk]

I haven't looked at your implementation yet but the software PWM is normally part of the Linux kernel GPIO driver. As such it is pretty fast since it can directly operate on the hardware without a lot of intermediate layers in between. It won't be able to reach extreme high PWM frequencies but to control a motor or similar through PWM it is usually more than enough.

The difficulty with the Linux GPIO driver is that it was changed several times in how it can be controlled from the user space. The previous version tried to allow controlling everything through read and write operations which makes it easy to control it from any process that has file access but it is kind of slow and clutters the device name space with many extra subfilenames for each device to control the specific different features. The newer version now requires use of IOCtrl calls to control those aspects and that limits the usability for environments that can issue IOCtrl calls. (no shell scripts for instance)

The old control through individual filenames allowed to actually control it directly through LabVIEW file IO nodes. The newer interface requires explicit calls to ioctl() through a Call Library Node to be able to control any attributes of the channel (IO pin). The Linx layer of course hides a lot of that but doesn't implement the necessary interface on other hardware than the Wiring based (Arduino) devices for anything but simple digital IO.