Quantcast

hardware pulse wave modulation - modified kernel module

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

hardware pulse wave modulation - modified kernel module

Software
Hi

I amended lirc_rpi.c (i.e., the source code of the kernel module) to support hardware pulse wave modulation. I am happy to let you know that the modified kernel module works in my hands.

The new kernel module has an additional parameter that can be provided when loading the module: pwmcarrier. If pwmcarrier=1 (which is mutually exclusive with softcarrier=1) then hardware pulse-wave modulation is used. The GPIO out pin needs to be 18 as this is to my knowledge the only pwm-enabled pin.

Tested on RPi3 with raspbian / Linux 4.4.13-v7+
- with a DVD player (38 kHz, duty cycle 50%)
- with a visible light LED to confirm the effect of 25% (=dim), 50% and 75% (=bright) duty cycle.

To whom should I send the source code for testing and possible merge into the productive code? Prior to merging, I will also clean it from too many printk statements and so, but only after the code has been reviewed by a maintainer. I can also provide a patch for the original version (https://github.com/raspberrypi/linux/blob/rpi-4.4.y/drivers/staging/media/lirc/lirc_rpi.c of today, SHA hash 7f7add4fb95315a58acae146a0eef2448f711390).

Best

A

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: hardware pulse wave modulation - modified kernel module

Alec Leamas


On 08/01/17 18:45, [hidden email] wrote:

> Hi
>
> I amended lirc_rpi.c (i.e., the source code of the kernel module) to support hardware pulse wave modulation. I am happy to let you know that the modified kernel module works in my hands.
>
> The new kernel module has an additional parameter that can be provided when loading the module: pwmcarrier. If pwmcarrier=1 (which is mutually exclusive with softcarrier=1) then hardware pulse-wave modulation is used. The GPIO out pin needs to be 18 as this is to my knowledge the only pwm-enabled pin.
>
> Tested on RPi3 with raspbian / Linux 4.4.13-v7+
> - with a DVD player (38 kHz, duty cycle 50%)
> - with a visible light LED to confirm the effect of 25% (=dim), 50% and 75% (=bright) duty cycle.
>
> To whom should I send the source code for testing and possible merge into the productive code? Prior to merging, I will also clean it from too many printk statements and so, but only after the code has been reviewed by a maintainer. I can also provide a patch for the original version (https://github.com/raspberrypi/linux/blob/rpi-4.4.y/drivers/staging/media/lirc/lirc_rpi.c of today, SHA hash 7f7add4fb95315a58acae146a0eef2448f711390).
>

Great work!

Now, this is a kernel module and belongs to the kernel. Eventually, it
should be filed at http://vger.kernel.org/vger-lists.html#linux-media.
However, just dropping things there doesn't always work - the list is
extremely high-volume.

One path is to use the get_maintainer.pl script (name out of the top of
my head) which when applied to the driver will give addresses to the
kernel maintainers. Sending the patch to them is a better option.

Another path is to contact the kernel maintainers on a distro. At least
the fedora maintainers has been very helpful when I have submitted some
patches.

If this takes too long time (as it certainly might), one option would be
that you renamed the driver and published it on github or so. I would be
happy to link to such a driver from he lirc website.

Cheers!

--alec

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: hardware pulse wave modulation - modified kernel module

Bengt Martensson-2
In reply to this post by Software
On 01/08/17 18:45, [hidden email] wrote:
> Hi
>
> I amended lirc_rpi.c (i.e., the source code of the kernel module) to support hardware pulse wave modulation. I am happy to let you know that the modified kernel module works in my hands.

Nice.
>
> The new kernel module has an additional parameter that can be provided when loading the module: pwmcarrier. If pwmcarrier=1 (which is mutually exclusive with softcarrier=1) then hardware pulse-wave modulation is used.

Actually, there are three cases of interest: HW modulation, SW
modulation, and NO modulation (some IR protocol, RF protocols for
sending with e.g. the TX-433 MHz module (wireless switch plugs etc,
Intertechno etc)). Preferably, no modulation should be selectable by
putting FREQUENCY = 0 in lircd.conf. Lircd supports that since around a
year, and so does "my" lirc_rpi
(https://github.com/bengtmartensson/lirc_rpi)

BTW, pwmcarrier is not a good name, since the present version can be
said to "generate a pwm-carrier in software".

> The GPIO out pin needs to be 18 as this is to my knowledge the only pwm-enabled pin.

Hmmm. When I looked into it around half year ago, I came to the
conclusion that the PWM0 channel can use GPIO12  and 16. while the PWM1
channel can use GPIO19 and 13. Hmmm. Not saying that you are wrong...


On 01/08/17 19:19, Alec Leamas wrote:
...

 > Now, this is a kernel module and belongs to the kernel. Eventually, it
 > should be filed at http://vger.kernel.org/vger-lists.html#linux-media.

Yes, in principle. But the lirc_rpi module, originally derived from the
serial driver by Aron Szabo, has been around for many years, I have made
an improved version (linked above), raspian has their own modifications,
which are not up-streamed (because there is no up-stream.) And no-one
seems to care...


 > If this takes too long time (as it certainly might), one option would be
 > that you renamed the driver and published it on github or so.

This is certainly a good idea. Does not contradict trying to
"officialize" it either-

Greetz,

Bengt

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: hardware pulse wave modulation - modified kernel module

Software
In reply to this post by Software
> Date: Sun, 8 Jan 2017 19:19:13 +0100
> From: Alec Leamas <[hidden email]>
> ...
>
> On 08/01/17 18:45, [hidden email] wrote:
> > Hi
> >
> > I amended lirc_rpi.c (i.e., the source code of the kernel module) to support hardware pulse wave modulation. I am happy to let you know that the modified kernel module works in my hands.
> >
> > The new kernel module has an additional parameter that can be provided when loading the module: pwmcarrier. If pwmcarrier=1 (which is mutually exclusive with softcarrier=1) then hardware pulse-wave modulation is used. The GPIO out pin needs to be 18 as this is to my knowledge the only pwm-enabled pin.
> >
> > Tested on RPi3 with raspbian / Linux 4.4.13-v7+
> > - with a DVD player (38 kHz, duty cycle 50%)
> > - with a visible light LED to confirm the effect of 25% (=dim), 50% and 75% (=bright) duty cycle.
> >
> > To whom should I send the source code for testing and possible merge into the productive code? Prior to merging, I will also clean it from too many printk statements and so, but only after the code has been reviewed by a maintainer. I can also provide a patch for the original version (https://github.com/raspberrypi/linux/blob/rpi-4.4.y/drivers/staging/media/lirc/lirc_rpi.c of today, SHA hash 7f7add4fb95315a58acae146a0eef2448f711390).
> >
>
> Great work!
>
> Now, this is a kernel module and belongs to the kernel. Eventually, it
> should be filed at http://vger.kernel.org/vger-lists.html#linux-media.
> However, just dropping things there doesn't always work - the list is
> extremely high-volume.
>
> One path is to use the get_maintainer.pl script (name out of the top of
> my head) which when applied to the driver will give addresses to the
> kernel maintainers. Sending the patch to them is a better option.
>
> Another path is to contact the kernel maintainers on a distro. At least
> the fedora maintainers has been very helpful when I have submitted some
> patches.
>
> If this takes too long time (as it certainly might), one option would be
> that you renamed the driver and published it on github or so. I would be
> happy to link to such a driver from he lirc website.
>
> Cheers!
>
> --alec

Thank you for your suggestions.

- I forked on github and committed my patch; see https://github.com/Al-/linux/blob/rpi-4.4.y/drivers/staging/media/lirc/lirc_rpi.c
- You remembered correctly; get_maintainer.pl is the script to find the maintainer, authors and so on. I will mail two of them: a maintainer, although focused on V4L/DVB, and the 'odd fixer' focused on LIRC.

Best

A

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: hardware pulse wave modulation - modified kernel module

Alec Leamas


On 10/01/17 07:45, [hidden email] wrote:

>
> Thank you for your suggestions.
>
> - I forked on github and committed my patch; see https://github.com/Al-/linux/blob/rpi-4.4.y/drivers/staging/media/lirc/lirc_rpi.c
> - You remembered correctly; get_maintainer.pl is the script to find the maintainer, authors and so on. I will mail two of them: a maintainer, although focused on V4L/DVB, and the 'odd fixer' focused on LIRC.

Yes... My experience is that really getting something into the kernel
will take a long time, especially if you are new to the kernel list.

However, people could start using your driver right away. For this to
work, you need to publish *only* the driver file on github together with
the out-of-tree Makefile. This way, users with kernel sources installed
could compile just your driver (fast!) and use it with whatever kernel
they have (as long as it's new enough to be compatible).

feedback obtained this way would of course  make it much easier getting
your driver into the kernel.

To avoid clashes in this scenario, you probably should rename "your
driver" and add instructions in a README to blacklist the existing driver.


Just my 5 öre,

--alec

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: hardware pulse wave modulation - modified kernel module

Software
In reply to this post by Software
> I amended lirc_rpi.c (i.e., the source code of the kernel module) to support hardware pulse wave modulation. I am happy to let you know that the modified kernel module works in my hands.
> The new kernel module has an additional parameter that can be provided when loading the module: pwmcarrier. If pwmcarrier=1 (which is mutually exclusive with softcarrier=1) then hardware pulse-wave modulation is used.

...

@Alec: thanks for the suggestion. I will prepare a stand-alone github project; hopefully this weekend.

@Bengt:
Thanks for your detailed comments.
1) 'pwmcarrier'
It is of course easy to change the parameter name; any suggestions?
2) GPIO18
As per the definition in wiringPi.c (see static uint8_t gpioToPwmALT[]; https://github.com/WiringPi/WiringPi/blob/master/wiringPi/wiringPi.c) the following GPIO support pulse wave modulation: 12, 13, 18, 19, 40, 41 and 45. As per https://sites.google.com/site/semilleroadt/raspberry-pi-tutorials/gpio (and other web pages) not all GPIO are connected, and GPIO18 is the (only?) available GPIO for hardware pulse wave modulation.
3) no modulation
There are three conditions to discuss. (i) pwmcarrier=1, i.e., the new code, accepts frequency=0 in which case a pulse wave modulation with 100% duty cycle is used. Your comment reminded me that I have not tested extreme duty cycles (1%, 99%, 100%); I plan this for the weekend. (ii) softcarrier=0 and pwmcarrier=0, in that case pulse wave modulation is always off, independent of the value set as frequency, which is of course not helpful if some remote controls require modulation and others do not. (iii) softcarrier=1; I have not touched this code and would need to dig into these parts of the code to answer.

Best

A

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: hardware pulse wave modulation - modified kernel module

Bengt Martensson-2
On 01/11/17 19:42, [hidden email] wrote:
...
> @Bengt:
> Thanks for your detailed comments.
> 1) 'pwmcarrier'
> It is of course easy to change the parameter name; any suggestions?

hwpwm? or hard-pwm, or hard_pwm? (Preferably not hardcarrier, which
suggest the negation of the existing softcarrier (which should be
removed, IMHO)).

> 2) GPIO18
> As per the definition in wiringPi.c (see static uint8_t gpioToPwmALT[]; https://github.com/WiringPi/WiringPi/blob/master/wiringPi/wiringPi.c) the following GPIO support pulse wave modulation: 12, 13, 18, 19, 40, 41 and 45. As per https://sites.google.com/site/semilleroadt/raspberry-pi-tutorials/gpio (and other web pages) not all GPIO are connected, and GPIO18 is the (only?) available GPIO for hardware pulse wave modulation.

The second link appears to concern RPi 1 only; RPi 2 and 3 has more GPIO
pins (40 vs 26 pin connector). So I consider the question still open.

> 3) no modulation
> There are three conditions to discuss. (i) pwmcarrier=1, i.e., the new code, accepts frequency=0 in which case a pulse wave modulation with 100% duty cycle is used.

OK, case settled; don't forget to test.

> Your comment reminded me that I have not tested extreme duty cycles (1%, 99%, 100%); I plan this for the weekend.
 > (ii) softcarrier=0 and pwmcarrier=0, in that case pulse wave
modulation is always off, independent of the value set as frequency,
which is of course not helpful if some remote controls require
modulation and others do not. (iii) softcarrier=1; I have not touched
this code and would need to dig into these parts of the code to answer.

As I said, "softcarrier" should probably be eliminated; setting
softcarrier=0 (default is 1) means that the hardware is supposed to
supply the modulation with an extra oscillator, and-ing the GPIO output
signal. It does not make the driver "frequency 0 capable". The case is
solved in my lirc_rpi: https://github.com/bengtmartensson/lirc_rpi

On 01/10/17 18:09, Alec Leamas wrote:

 > To avoid clashes in this scenario, you probably should rename "your
 > driver" and add instructions in a README to blacklist the existing
driver.

In free software, there are "always" versions of stuff. Creating a new
name will likely create as many problems as it solves. Just my 0.05€.

Bengt

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: hardware pulse wave modulation - modified kernel module

Alec Leamas


On 12/01/17 09:49, Bengt Martensson wrote:
://github.com/bengtmartensson/lirc_rpi
>
> On 01/10/17 18:09, Alec Leamas wrote:
>
>  > To avoid clashes in this scenario, you probably should rename "your
>  > driver" and add instructions in a README to blacklist the existing

Just so that users can blacklist existing driver (if there is one),
while using the new. Nothing else.

--a

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: hardware pulse wave modulation - modified kernel module

Software
In reply to this post by Software
> > I amended lirc_rpi.c (i.e., the source code of the kernel module) to support hardware pulse wave modulation. I am happy to let you know that the modified kernel module works in my hands. The new kernel module has an additional parameter that can be provided when loading the module: pwmcarrier. If pwmcarrier=1 (which is mutually exclusive with softcarrier=1) then hardware pulse-wave modulation is used.

> @Alec: thanks for the suggestion. I will prepare a stand-alone github project; hopefully this weekend.
See https://github.com/Al-/lirc_rpi_hardpwm
The repository includes
- lirc_rpi.c; I chose not to rename as I copy the new module over the existing, stock lirc_rpi.ko
- Makefile; the path to the raspberry kernel directory needs to be adjusted
- README with compile, install and use instructions as well as limitations
- lircd.conf that I use to test various duty cycles

> > @Bengt:
> > Thanks for your detailed comments.
> > 1) 'pwmcarrier'
> > It is of course easy to change the parameter name; any suggestions?
> hwpwm? or hard-pwm, or hard_pwm? (Preferably not hardcarrier, which
> suggest the negation of the existing softcarrier (which should be
> removed, IMHO)).
Renamed to hardpwm

> > 2) GPIO18
> > As per the definition in wiringPi.c (see static uint8_t gpioToPwmALT[]; https://github.com/WiringPi/WiringPi/blob/master/wiringPi/wiringPi.c) the following GPIO support pulse wave modulation: 12, 13, 18, 19, 40, 41 and 45. As per https://sites.google.com/site/semilleroadt/raspberry-pi-tutorials/gpio (and other web pages) not all GPIO are connected, and GPIO18 is the (only?) available GPIO for hardware pulse wave modulation.
> The second link appears to concern RPi 1 only; RPi 2 and 3 has more GPIO
> pins (40 vs 26 pin connector). So I consider the question still open.
You are correct; on RPi3 (and RPi2?) not only GPIO18 but also three of the other hardware-pwm-enabled GPIO are connected to physical pins: to pin 12 (GPIO18, PWWM0), 32 (GPIO12, PWWM0), 33 (GPIO13, PWWM1) and 35 (GPIO19, PWWM1). I tested those total four pins; all work with my module (without any change to the code as I had copied that part from wiringPi).

> > 3) no modulation
> > There are three conditions to discuss. (i) pwmcarrier=1, i.e., the new code, accepts frequency=0 in which case a pulse wave modulation with 100% duty cycle is used.
> OK, case settled; don't forget to test.
I was too optimistic: while my code accepts frequency 0 (for no modulation), this value is filtered out by the calling function in the pre-existing code. Any frequency outside 20 kHz - 500 kHz is ignored and 38 kHz are used as default value. I could change this, but this would break buggy, but possibly existing lircd.conf files (that include freq=0, but the common 38 kHz should be and is used). As workaround, 100% duty cycle can be used. I added this to the new hardware pwm code.
What is the recommendation of the group: should I introduce the minor modification that frequency=0 is correctly honored if hardware pwm is used; despite that this potentially breaks existing conf files if they start to use hardware pwm? Or even for softcarrier=1 as well?

> > Your comment reminded me that I have not tested extreme duty cycles (1%, 99%, 100%); I plan this for the weekend.
100% duty cycle works; this is no modulation. Extreme duty cycles (1%, 99%) also work. The accuracy deteriorates as a compromise, with the accuracy permitted by the frequency of the PWM master clock (19.2MHz), between accuracy of carrier frequency, accuracy of duty cycle and high divisor. Extreme (unreasonable?) duty cycles such as 1% or 99% lead to a substantial error (depending on the frequency, up to approximately 5% and down to approximately 95%, respectively).
 
> As I said, "softcarrier" should probably be eliminated; setting
> softcarrier=0 (default is 1) means that the hardware is supposed to
> supply the modulation with an extra oscillator, and-ing the GPIO output
> signal. It does not make the driver "frequency 0 capable". The case is
> solved in my lirc_rpi: https://github.com/bengtmartensson/lirc_rpi
I agree that freq=0 should be honored by the driver. IMO the parameter softcarrier should remain. This allows users with a hardware oscillator to switch modulation off in lirc_rpi, and still use downloaded lircd.conf files (that specify the correct frequency, not 0).

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: hardware pulse wave modulation - modified kernel module

Bengt Martensson-2
On 01/14/17 15:43, [hidden email] wrote:
...
>>> 1) 'pwmcarrier'
>>> It is of course easy to change the parameter name; any suggestions?
>> hwpwm? or hard-pwm, or hard_pwm? (Preferably not hardcarrier, which
>> suggest the negation of the existing softcarrier (which should be
>> removed, IMHO)).
> Renamed to hardpwm

Gr8!

>
>>> 2) GPIO18
>>> As per the definition in wiringPi.c (see static uint8_t gpioToPwmALT[]; https://github.com/WiringPi/WiringPi/blob/master/wiringPi/wiringPi.c) the following GPIO support pulse wave modulation: 12, 13, 18, 19, 40, 41 and 45. As per https://sites.google.com/site/semilleroadt/raspberry-pi-tutorials/gpio (and other web pages) not all GPIO are connected, and GPIO18 is the (only?) available GPIO for hardware pulse wave modulation.
>> The second link appears to concern RPi 1 only; RPi 2 and 3 has more GPIO
>> pins (40 vs 26 pin connector). So I consider the question still open.
> You are correct; on RPi3 (and RPi2?) not only GPIO18 but also three of the other hardware-pwm-enabled GPIO are connected to physical pins: to pin 12 (GPIO18, PWWM0), 32 (GPIO12, PWWM0), 33 (GPIO13, PWWM1) and 35 (GPIO19, PWWM1). I tested those total four pins; all work with my module (without any change to the code as I had copied that part from wiringPi).
>
>>> 3) no modulation
>>> There are three conditions to discuss. (i) pwmcarrier=1, i.e., the new code, accepts frequency=0 in which case a pulse wave modulation with 100% duty cycle is used.
>> OK, case settled; don't forget to test.
> I was too optimistic: while my code accepts frequency 0 (for no modulation), this value is filtered out by the calling function in the pre-existing code. Any frequency outside 20 kHz - 500 kHz is ignored and 38 kHz are used as default value. I could change this, but this would break buggy, but possibly existing lircd.conf files (that include freq=0, but the common 38 kHz should be and is used). As workaround, 100% duty cycle can be used. I added this to the new hardware pwm code.
> What is the recommendation of the group: should I introduce the minor modification that frequency=0 is correctly honored if hardware pwm is used; despite that this potentially breaks existing conf files if they start to use hardware pwm? Or even for softcarrier=1 as well?

Lircd mishandled frequency = 0 until recently. See ticket 132:
https://sourceforge.net/p/lirc/tickets/132/ . However this was fixed in
August 2015, so I assume that it is present in Lirc version 0.9.4 and
later. (Alec, can you confirm?) Suggestion: "Only supported for 0.9.4
and later".

Greetz,

Bengt

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
Loading...