danitool / openwrt-pkgs

my custom OpenWrt packages: lirc and others
GNU General Public License v2.0
9 stars 4 forks source link

irsend freezes on RT5350F #6

Open vinceb87 opened 7 years ago

vinceb87 commented 7 years ago

Hi,

I'm using both mode2 and irsend functions of the lirc library. The mode2 function from your driver works well on RT5350F. However, when I run irsend SEND_ONCE "remote" "code" The ralink freezes and I have no control over it. I have to wait some minutes and then command line prompt is back again. I put a receiver on a RPI in front of ralink's emitting IR led and I can see some IR data in reception. However, the data frame flow is not constant ; there is some time laps between data emissions. Also, I tried activating the IR led by hand

echo 0 > /sys/class/gpio/gpioXX
echo 1 > /sys/class/gpio/gpioXX

It works well : the IR led turns on and off without any time overhead and the command prompt doesn't freeze.

Any idea why it behaves like this?

Thanks

danitool commented 7 years ago

Hi, probably there is some trouble with the GPIO drivers in your platform (might be causing a kernel panic). Are you using lirc-gpio-generic or lirc-gpioblaster ?

lirc-gpio-generic is a bit different in Caos Chalmer (cc) branch

Also be care with the GPIO you're using, it should be a free gpio for avoiding hardware problems, and without pull-up/down resistors. In some implementations I made you need to sum the base to GPIO, I assume you're using the correct number otherwise it won't emit any IR light.

Right now I don't have any ramips device ready for testing, so I have no idea what's going on your device.

Regards

vinceb87 commented 7 years ago

Well, in fact, the GPIO I'm using is said to be a pull down on the Olimex Soc based on Ralink RT5350F. Would it be the problem? Thanks.

danitool commented 7 years ago

A pull down resistor shouldn't be a problem with the blaster if not connected to anything else. I only noticed troubles with the blaster when the CPU is under high CPU loads specially if they're sirq loads. But not to the extreme of being unresponsive for minutes .

Does your device has a good power source. The emitter doesn't consumes high power, but it draws lot of current for very short time periods. If the power source is limited then you need to add a big electrolitic capacitor to the blaster circuit (3300 uF) to avoid problems when feeding the whole thing.

vinceb87 commented 7 years ago

Hi,

I have a circuit like this

5V |--------------(CAPACITOR)----------------------------------------------|//GND
         |                         
         \---(R)----(IR led)---(N-channel Transistor)-------|//GND
                                         |----(R)-----------|//GND
                                         \----(R)-----------|GPIO PIN

The capacitor value is 470 uF.

Also, I already said it but when I drive the gpio with a script shell on the GPIO pin, the OS doesn't freeze. The only differences between the driver and the way I drive gpio is:

Oh! I forgot an important point. I am using a lab power supply and it shows an overhead of 400mA when IR led is ON but the whole consumption of my circuit is much below the current draw limit. Cheers, Vince

danitool commented 7 years ago

Assuming you choosed reasonable resistor values your circuit looks good to me. Anyway it shouldn't freeze your system in any case if you use a good power source.

Probably the problem is at the gpio driver. Do you receive any kernel error when using the LIRC driver?

danitool commented 7 years ago

Can you test the lirc-gpioblaster instead? https://github.com/danitool/openwrt-pkgs/tree/cc/lirc-gpioblaster

It's only for the transmitter, but it uses a bit different approach for managing the GPIO. This one uses gpiolib which should be a standard for all platforms.

The old lirc-gpio-generic from barrier breaker branch in my repository also uses the same approach.

vinceb87 commented 7 years ago

I removed the previous comment which error had nothing to do with the topic. I retrieved my "normal" behavior with os freeze when running irsend. I tried the lirc-gpioblaster (without the lirc-gpio-generic driver of course) and still have the same behavior.