irsend freezes on RT5350F

[vinceb87]

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]

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]

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]

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]

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:

• the way I do it but that shouldn't have an impact
• the frequency at which the IR led starts/stops emitting. Could it be that at high frequency (driver), an electronic behavior creates this freeze that doesn't occur at low frequency (shell script)?

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]

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]

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]

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.