Android platform Application Gpio analog IR control car DTV

Digital TV-dtv for us is already not a new thing, in the car electronic DTV mostly in the form of modules independent existence, is worthy. In the car market, customer demand is diverse, if the DTV also do car navigation main PCB up, or not flexible, do not have to DTV is different PCB board, which for after-sale maintenance, development is not a good way.

DTV at home, we are generally through the remote control to operate, of course, now some Android TV box can be controlled by mobile phone, there is a apk remote control, through the same WiFi hotspot TV box, you can use mobile phone to operate also quite convenient. But in the car, how to operate the DTV? In the car, the general space is relatively narrow, the use of remote control is very inconvenient, so we need to control to navigate the main control up. The NEC protocol is the most commonly used protocol in the remote control, and the following is an example of the NEC protocol to learn how to use GPIO to simulate IR key messages.

A key message from NEC consists of a data header, a client code, a customer code counter code, a key value, a key-value inverse code, and a stop bit, which does not introduce duplicate codes. The header is a 9ms + 4.5ms high or low combination, followed by a 4-byte value, which is the 32bit 0, 1 combination. The Gpio port of the IR port is usually a high level by default, and most of the decoding drive is to use the drop along trigger interrupt. The main point here is to compile a series of IR pulses. The code that combines this string of pulses is as follows:

   Gpio_write_one_pin_value (simulate_ir_gpio_hdle, 0, "Simulate_ir_gpio");    	
		  DELAY10US (900);//9ms
   Gpio_write_one_pin_value (simulate_ir_gpio_hdle, 1, "Simulate_ir_gpio");    	
		  DELAY10US (450)//4.5ms
		 
   //ir Customer code:0x807f,  NEC IR protocol  
   sendbytedata (0x80);  DVB header_code0 
   sendbytedata (0x7F);  DVB header_code1 

   sendbytedata (irdata);
   Sendbytedata (~irdata); 
   Gpio_write_one_pin_value (simulate_ir_gpio_hdle, 0, "Simulate_ir_gpio");    	
			DELAY10US (a); 
   Gpio_write_one_pin_value (Simulate_ir_gpio_hdle, 1, "Simulate_ir_gpio");    	

There is a problem here, is to make up this pulse need more than 50ms, the standard of a complete message is probably 108ms-110ms. This requires us to send 4 bytes of data and stop code in the middle of the task can not be scheduled, because the task of a dispatch of the code will have a wide gap in the width of the receiver will be interpreted as a wrong remote value. So how do we try to make sure? In Linux there is a spinlock, that is, the spin lock, once the lock can be assured that the process of course execution is not scheduled preemption. So in the above code before and after the lock and cancel the lock operation, the author in the actual operation, in nearly hundreds of operations, the success rate of sending IR key value is hundred percent. The associated code for the lock is as follows:

#include <linux/spinlock.h>
spinlock_t		lock;

  Spin_lock_init (&lock);

   Spin_lock (&lock);
 For your process//////////////////
   spin_unlock (&lock);

On top of Android, it can be controlled by IOCTL, which can be encapsulated in service for upper application.