title: How to generate a steady 37kHz GPIO trigger from inside linux kernel?
body: <p>I have a micro controller taking care of infrared TX-carrier wave generation currently, but I started wondering if I could dispose of it, and do this work in linux side - thus bringing the cost of my embedded system down.</p>
  
  <p>I'm running on a Freescale i.mx233 (454MHz ARM9), and if I access registry directly through <code>/dev/mem</code>, I can achieve quite steady 5MHz triggering to a GPIO pin.</p>
  
  <p>Since I need 37kHz, I started looking ways of slowing it down, but it seems that at least <code>nanowait()</code> is way too rough for this purpose. 
  I found one solution of calling rand() in a for loop, and I seem to be able to generate 38,4kHz signal quite well, However there is some unacceptable jitter from time to time according to oscilloscope. (I understand that this is quite a bit waste of resources, but when the TX needs to be done, the system has no other tasks really)</p>
  
  <p>My questions:
  Freescales kernel code (3.8 branch) doesn't have CONFIG_PREEMPT_RT patches, so that is one thing maybe I should look into, but before that:</p>
  
  <ul>
  <li><p>Could I achieve more accurate performance, by writing a kernel module to drive the GPIO from inside the kernel ? I do need to read up on some data from user space (data to be sent), but other than that, I only need to trigger the led on specified frequency at the end of the GPIO, so the driver should be pretty simple.</p></li>
  <li><p>Can I force the priority of my driver, so that other tasks don't interrupt this gpio triggering ? (data sending takes currently roughly 400ms, and it's done very seldom)</p></li>
  <li><p>Is there some better way to create an interrupt say every 37kHz, so that I don't stall the system by SW ?</p></li>
  </ul>
  
  <p>Micro controller is perfect for this kind of tasks, but it would be nice to avoid this cost overhead if possible... </p>