Hi,
could you confirm that to use PWM from user space in a C language project, the only mode is throught sysfs interface ? I’m using BSP (not Torizon) “Toradex Embedded Linux Reference Multimedia Image (UPSTREAM) 6.2.0+build.6”.
Thanks
Hello @Massimo,
May I know what exactly is your use-case here?
Are you facing any issues in accessing the PWM through sysfs interface?
Hello Rudhi,
accessing PWM using sysfs from C program works fine, but it is slow for our application.
I verifyed that only to change the PWM period, it take about 100 microseconds.
Is there another method to speed up PWM control ?
Hello @Massimo ,
You mention that 100us is slow. May we know your timing requirements?
Maybe you can improve the timing by doing it in the kernel (developing a driver).
Also, we would like to know how you are measuring the time , so that we exclude that you are measuring the time it takes to open the sysfs file and then write (if you’re worried about speed you should keep the file open and just write to it when needed)
Best regards,
Josep
Hello @josep.tx,
to get the execution time, I set and reset a memory mapped GPIO, verifing time with an oscilloscope.
I retryed avoiding to open /sys/class/pwm/pwmchipX every time. In this way, only setting period, take about 25 microseconds. This time is normally doubled because I need to set also the duty.
It is better that before.
But why there isn’t a standard linux PWM driver avoiding to use sysfs ?
Thanks
Hello @Massimo
Does your application require that you change the PWM period and the duty in the control loop?
I ask because usually we only need to change the PWM duty to get the desired results (period changes can happen but usually are less frequent). In this case, the time you need to execute the procedure from userspace would be around 25us as you mention.
Having another kind of interface to the driver wouldn’t necessarily improve the timing of the accesses. The only thing that could potentially improve it from userspace would be some kind of memory-mapped access to the PWM registers, but this is something that I don’t think currently exists so it would need to be implemented.
Other alternatives for faster access would be to do the changes in a custom driver, but unless the entire control loop runs inside the kernel, the time to write the new values from userspace would probably be in the same ballpark as what you’re already getting. You need to consider that every time you need to cross the barrier between the kernel and userspace, there will be a delay inherent to that operation.
Regards,
Rafael
Hi @rafael.tx,
thank for your answer.
in a control loop where period is a constant and only duty must change (for example a D/A conversion), only the duty must be set, so we lost about 25 microseconds. But if duty is constant to 50% and I need to change period (for example to set speed on a stepping motor driver), both must be changed, so we lost about 50 microseconds.
Thanks about consideration on time to spend to call a kernel function from userspace.
If you’re thinking about running a control loop in linux you should be looking first at the variability of the timing due to the way the linux scheduler normally works. I think this will be your biggest problem, most likely the timing variation between two or three consecutive loop calls will be much more than 100us and this needs to be taken into consideration.
Things will improve by using the real-time patch, properly setting up the priorities of the necessary threads, and using some kind of memory-mapped PWM access like I suggested before. Another option would be to use a SoC that contains a cortex M4 and run the control loop directly on the M4.
In any case, none of these solutions are particularly easy and will require custom software implementation.
Hello @Massimo ,
Were you able to solve your issue with the info provided by @rafael.tx ?
Best regards,
Josep
Hello @josep.tx,
yes I have all the informations to take a decision about how to solve the problem.
Thanks