LeMaker Guitar:IR

From BananaPro/Pi
Jump to: navigation, search

Other languages:
English • ‎中文(简体)‎

Introduction

GUITAR PMU(ATC2603C) Infrared Remote Controller (IRC) module Support RC5/9012/NEC(8-bit)/RC6 protocol, the sample clock is 32.576kHz. IRC is connected with an Infrared Remote (IR) receiver, only when the received key data is equal to the IRC_WK register's data, including NEC, 9012, RC5 and RC6 mode, can IRC wake up the system by generating a wake up signal to PMU.

IR format supported by Guitar PMU

9021 Protocol

The 9012 protocol adopts PDM (Pulse Distance Modulation). Each pulse is one Tm (560μs) 38kHz carrier burst, and LSB is transmitted first. Logic 1 takes 4Tm (2.25ms) to transmit, and logic 0 only takes 2Tm (1.12ms). A message is started by 8Tm (4.5ms) AGC burst, used to set the gain of the front IR receivers. Customer code and Command code length is both 8-bit, and they are transmitted twice to ensure the reliability of the transmission. And in the second time, Command code is inverted to Anti-code to verify the received messages.
9021.png
Below are some values for reference:
Recommended carrier duty-cycle = 1/4 or 1/3.
Tm = 256/Fosc = 0.56ms (Fosc=455kHz)
Repetition time = 192Tm = 108ms
Carrier frequency = Fosc/12
9021-1.png
When the key on the remote controller remains pressed down, the command will be transmitted only once, even a repeat code is transmitted every 192Tm as long as the key remains pressed down. This repeat code is 8Tm (4.5ms) AGC pulse followed by 8Tm (4.5ms) space and a logic 1 plus 1Tm (560μs) burst.
9021code.png

NEC Protocol(8 bit)

The NEC protocol adopts Pulse Distance Modulation. Each pulse is one Tm (560μs) 38kHz carrier burst, and LSB is transmitted first. Logic 1 takes 4Tm (2.25ms) to transmit, logic 0 only takes 2Tm (1.12ms). A message is started by 16Tm (9ms) AGC burst, which was used to set the gain of the front IR receivers. This AGC burst is followed by 8Tm (4.5ms) space, and then the Customer and Command code. Customer and Command codes are both 8-bit, they are transmitted twice for reliability; the second customer and command code are inverted to Anti-code to verify the received message.(BTW: The customer code may consists of 8bit customer code & 8bit customer anti-code or 8bit customer code & 8bit customer code, it is depending on the manufacturer.) The whole transmission time is constant because every bit is repeated with its inverted length.
Nec.png
Below are some values for reference:
Recommended carrier duty-cycle: 1/4 or 1/3
Tm = 256/Fosc = 0.56ms (Fosc=455kHz)
Repetition time = 192Tm = 108ms
Carrier frequency = Fosc/12
9021-1.png
When the key on the remote controller remains pressed down, the command will be transmitted only once, even a repeat code is transmitted every 192Tm as long as the key remains pressed down. This repeat code is a 16Tm (9ms) AGC pulse followed by a 4Tm (2.25ms) space and a Tm (560μs) burst.
Nec-code.png

RC5 Protocol

The RC5 protocol adopts Bi-phase Modulation (or Manchester coding) of 38kHz IR carrier frequency. Transmission time of each bit is 1.8ms in this protocol, in which half of the transmission time is for the 38kHz carrier and the other half being idle. Logic 0 is a burst in the first half of the transmission time, logic 1 is a burst of the second half of the transmission time; see in Figure 10-7 below. The pulse/pause ratio of the 38kHz carrier frequency is 1/3 or 1/4, which reduced the power consumption.
Rc5.png
Below are some values for reference:
1 bit-time = 3*256 /Fosc= 1.688ms (Fosc=455kHz)
Tm= 1 bit-time/2=0.844ms
Repetition time= 4*16*2Tm=108ms
Carrier frequency = Fosc/12
Rc5-1.png
The first two pulses are start pulses, both are logic 1. Half of the transmission time will be elapsed before the receiver recognizes the real start of the message. The third bit is a toggle bit, this bit is inverted every time a key is released and pressed again. This is how the receiver distinguishes whether the key remains pressed down or repeatedly pressed. The next 5-bit Customer code represents the IR device’s address, with MSB sent first. The following 6-bit command code is sent with MSB first, too.
One message is 14 bits in total, which adds up to time duration of 28Tm. Sometimes a message may be shorter because the first half of the start bit S1 is idle, and if the last bit of the message is logic 0 the last half bit of the message is idle too. As long as a key remains down the message will be repeated every 128Tm (108ms). The toggle bit will remain the same logic during these repeated messages. And this auto repeat feature can be configured by the receiver software.
Rc5-2.png

RC6 Protocol

The RC6 Protocol of mode 0 is supported only. RC-6 signals are modulated on a 36 kHz Infrared Red carrier. The duty cycle of this carrier is recommended between 25% and 50%. Transmission data is modulated using Manchester coding. This means that each bit (or symbol) will have both a mark and space in the output signal. If the symbol is 1, the first half of the bit time is a mark and the second half is a space. If the symbol is 0, the first half of the bit time is a space and the second half is a mark. The main timing unit is 1T, which is 16 times the carrier period (1/36kHz * 16 = 444μs)
1T =1*16 / 36kHz = 444μs
1Bit = 2T = 888μs
Total transmission time (22 Bits) = 23.1ms(message) + 2.7ms (no signal)
Repetition time = 240T = 106.7ms
Rc6.png
The RC6 Protocol frame can be separated into four fields: Header, Control, Information and Signal free field. The signal free field is not used.
Rc6-1.png
This leader bit is the start bit used to set the gain of the IR receiver unit, which has a mark time of 6T (2.666ms) and a space time of 2T (0.889ms).
Rc6-2.png
The normal bit, 0 and 1 are encoded by the position of the mark and space in the bit time, in which mark time is1T (0.444ms) and space time is1T (0.444ms).
Rc6-3.png
The trailer bit TR has a mark time of 2T (0.889ms) and a space time of 2T (0.889ms). Same, 0 and 1 are encoded by the position of the mark and space in the bit time. This bit functions like the traditional toggle bit, which will be inverted whenever a key is released. This bit separates a long key-press from a double key-press.
Rc6-4.png

Guitar IR Driver

The driver code is located in:
./linux-actions/drivers/input/keyboard/atc260x-irkeypad.c
The platform equipment resources is located in:
./linux-actions-bsp/linux-actions/arch/arm/boot/dts/lemaker_guitar_bbb.dts

Guitar PMU IR Configuration

In order to facilitate the development, and modular need, we need resources in a separate IR driver is extracted, so that a new transplant IR driver, only need to configure these resources can be completed without rewriting the driver code, those involved resources stored in the board-level file dts located in:
./linux-actions-bsp/linux-actions/arch/arm/boot/dts/lemaker_guitar_bbb.dts
configuration note:

atc260x-irkeypad{ /* IR device node */
size = <1>; /* The number of keys, and ir code, keycode must have the same number of members */
user_code = <40800>; /*IR customer code:0x9F60 equal 40800(decimal)*/
protocol = <1>; /* IR supported protocols, 0: 9021; 1: NEC8; 2: RC5*/
wk_code= <12>; /* IR wake key value codes, generally power key code */
period = <140>; /* Delay reporting bounce action, in ms */
ir_code = <12>;/* Each IR on the remote control key code */
key_code = <116>;/* Mapping function keys, and ir_code correspond to the android application */
compatible = "actions,atc2603c-irkeypad"; /* It used to bind drivers and equipment resources */
};

How to add a IR remote control

Get the protocol

It is nice if you can get the information from supplier, otherwise you have to refer the chapter 1 to get it. And in this way you need to an oscilloscope, observation the waveform of any of the remote control buttons, lead code determines the protocol supported by the remote control.
Default configuration of the remote control to LeMaker Guitar uses the NEC coding mode. Press any key on the remote control and measured the IR receiver OUT Pin the oscilloscope, look at the waveforms, such as:
Protocol.png
You can see its lead code is made up of low level of 9ms and 4.5ms of high level group, and we can determine that the remote control is the use NEC code, so the fields of the DTS protocol should be configured to 1.

Get the customer code

The customer code is followed closely behind the lead code and the waveform link follows:
Customer.png
From the picture above you can see, according to the format of the NEC protocol logic 1 and 0, the following 16 bit data is 0000 0010 0000 0010b, the data is from low to high, so the true customer code is 0100 0000 0100 0000b (0x4040), so the user_code of DTS fields should be configured to <16448>.

Replace the kernel.dtb file

After you configured the *.dts file, run make to compile the kernel and then copy the file ./build/s500/misc/kernel.dtb to LeMaker Guitar's /media/lemaker/misc.
Restart.

Verify the key_val

Of course it is better to get it from the supplier, and you can also use this *.ko file to try the Key_val one by one:
http://mirror.lemaker.org/atc260x-irkeypad.zip
The fixed code has been committed to the github at https://github.com/LeMaker/linux-actions
You can download the code and compile it yourself.

Replace the IR driver:
Remove the ole driver first:
rmmod atc260x_irkeypad
Load this new driver:
insmod atc260x_irkeypad.ko
Run the nex command to display the debug information:
echo 1 > /sys/kernel/debug/ir_debug/debug_on
And then, presh any key to the IR resiver, you can see the ir_val displyed on the screen, e.g:
Irkey.png
From the Pic we can see the key’s ir_val is 17. And the old_key_val and new_key_val is 0 which means there are no mapping value for this key.

Function code

Function code is one to one correspondence with key code, function code reflects the specific practical function, the applications will use this code to do it’s own thing.

Guitar PMU IR debug

Debug

IR debugging is relatively simple, first get to know the IR remote control keys corresponding to the key code, based on the need to achieve its key function reference android standard button mapping table, fill dts files.
Next, check whether there is an interrupt is generated. IR remote control at the device's receiver, the receiver with oscilloscope measurements pin if there is waveform parameters. If not, check the receiver power supply is normal, otherwise replace the remote control or IR receiver. If the waveform, there is analyze whether the waveform and dts under the same set of parameters, including protocol, user_code.
If you can generate an interrupt, access to the IR button key, basically be able to work, and the rest is input subsystem work, according to the configured dts mapping table, the key driver reported to the android system.

Questions note

For devices may be dormant, IR can not wake up the device.
1) First make sure wk_code is configured correctly, the key mapping must be POWER key.
2) Although the configuration of the wk_code, only PMU IR controller can trigger wake CPU, but may not be able to wake the android system, you must add POWER escalation actions IR driver resume function because android system consists reported POWER button to decide whether to perform late_resume wakeup operations.