For decades small 8-bit/16-bit microprocessors have been used in handheld remote control devices and have significant advantages in mobile device applications. They are relatively inexpen-sive, and perform well. Code optimization and sleep/wake feature reduces power consumption which increases battery life. A non-volatile memory may be employed to store many protocols to suit a large number equipment manufacturers. Additionally, both the processor firmware and the non-volatile memory may be reprogrammed to further improve user experience. However, a micro-processor is not an ideal choice for mobile devices. Typically, microprocessor based solutions are physically large: >15 mm2, require additional codebase, and could be expensive. Furthermore, mobile devices already incorporate at least one processor, the AP, which is capable of IR pattern generation.
Interestingly, many mobile device manufacturers employ a two processor scheme. The Appli-cation processor, AP, typically has 1 to 2 GB of RAM, 1 to 2 GHz clock, and multiple cores runs an OS, user applications. The second processor, called a Hub, is a small 8/16-bit low power device that is used to process data from peripherals such as a proximity detector, Ambient Light Sensor (ALS), accelerometer, or barcode emulation. This scheme is used to conserve battery power while offloading sensor specific tasks from the AP. Current hub technology is typically capable to generate IR remote control patterns; however, mobile device manufacturers don’t utilize the hub for this purpose. The hub has a rudimentary operating system that services “always-on” devices and sensors. Therein lies the problem; remote control requires all of the processing power during a transmission. In addition, from a software point of view, remote control transmission algorithm is not compatible with current hub technology employing an OS with a scheduler.
If an FPGA is combined with a microprocessor the result would be an Application Specific Integrated Circuit, ASIC. From a physical layer point of view, an ASIC has all the advantages of FPGAs and microprocessors combined into one device. The device is highly optimized, resulting in few unused circuits, static power consumption is low, package size is variable (≤ 36 mm2), and operation is tailored for high performance. Also, the OEM is not responsible to develop or manage HDL or firmware. ASICs have some significant disadvantages as a remote control solution in mobile devices. First off, as the name implies, they are “Application Specific”; which invariably results in a long development cycle which delays the time to market. ASICs can also be an expensive solution depending on the volume of devices sold.
An Application Processor could surely generate and output remote control patterns on a dedi-cated pin. A Serial Peripheral Interface, SPI, pin such as MOSI is an ideal choice to drive an exter-nal LED driver circuit. Advantages of using the AP are obvious: no additional hardware cost, no additional power consumption, easy software updates, and any pattern can be easily be generated. Additionally, if the MISO pin is connected to a specialized IR photodiode circuit, then a learning function can implemented to record the IR signal from an OEM remote control. The disadvantage of using the AP is less obvious, yet pose significant challenges.
The problem actually has more to do with the operating system and software architecture than with hardware. Currently, kernels have evolved to juggle processes on multi-core processors. Be-sides scheduling process execution, it balances core utilization, adjusts AP power management, handles interrupts, etc. The question becomes, how can a pattern be generated with exact timing, output on a particular pin while using a non-real time OS? One way would be to halt all processes and utilize 100% of the AP for pattern generation. Obviously, this solution is unacceptable. How-ever, refining this idea so that the pattern is generated in one core, leaving the three remaining cores to continue normal operation, seems much more reasonable.
The issue with this approach is that the OS would have to be built such that at any instant, a user “button push” event must cause a designated core’s processes be transferred to the other cores, then an RTOS or routine would run to generate the electrical waveform on a dedicated pin. From a hardware point of view, this sounds like a great solution, from the software side many chal-lenges exist. The scope of the project includes: modification of the OS and kernel, design of the stand-alone pattern generation routine, creating a comprehensive scheme to transfer processes between cores and adjust power management. Then custom software must be created to glue the OS pieces together and provide at least one method of interface to the application layer. The oldest and most common interface is Consumer.IR; however, new interfaces exist which improve and augment functionality.