Please check the FAQ and the mailing list archive before contacting us with problems. In case of a problem not covered there, or you discover a bug, use the mailing list. Please note that you will need to subscribe to the mailing list before posting to it. (To avoid spam, the mailing list is restricted to subscribers).
FYI: There is no M$ windows support and will not be (at least by us) so do not bother asking.
Refer to the electronic schematics and create your board either with real PCB layout or using a stripboard. Stripboards have a grid of drilled holes and copper stripes on one side. An example design for a test board can be found in the pictures section.
It can be quite tricky to build the MCU code, so you can find an already build image in the distribution tarball inside the "mcubin" folder.
To build it yourself, you will need wine and the CodeWarrior compiler installed.
In the mcu source directory, run: "./configure cw && make"
SDCC does not work at the moment, but to try it, run in the mcu source directory: "./configure sdcc && make"
In case you do not have access to real prommer hardware that supports the MCU, you can create a small prommer to program your board. You will naturally also need a PC with RS232 port to use the prommer, or a USB-to-serial adapter. We use Spgmr08 or bl08 as the prommer software.
Quick promming how-to using Spgmr08:
- Start promming software:
$ ./spgmr -P /dev/ttySnWhere n is 0 for COM1 and 1 for COM2 etc.
- Select CPU type: cpu jb8
- Power on the prommer
- Clear the security codes: scodes try blank
- Erase the flash memory: erase
- Power off the prommer
- Power on the prommer
- Clear the security codes: scodes try blank(NOTE: For a new, never programmed chip you need to repeat steps 4-8 two times)
- Program your hex image:
program from /path/to/my/usbirboy.s19
And you are all set!
Alternatively, you can do it in one go with bl08:
Note that the -r 1000 option resets the board if you have added the optional DTR-to-reset transistor to your prommer board.
The kernel module is only for 2.6.x or newer kernels. Note that if usbirboy is the only device you use in LIRC, you do not need to compile the LIRC devices. The usbirboy module is standalone and does not need any other driver to be available. (LIRC was included in some of the early 2.6 kernels but it seems to have been removed in the current kernel tree.)
Quick kernel module install how-to:
- Make sure you have USB enabled in the kernel configuration
- Check that the Makefile refers to the right installation path
- Make the module $ make
- Install the module (as root) # make install
- Load module (as root) # modprobe usbirboy(To enable driver debugging, use "modprobe usbirboy debug=1")
- Naturally you can add loading of the driver to your start-up scripts (varies between distributions)
After plugging it in, you should be able to see the device using the command:
The output should include these lines:
idVendor 0xfffe idProduct 0x0000 bcdDevice 0.21 iManufacturer 2 I made it! iProduct 1 IR BOY iSerial 0 bNumConfigurations 1
The usbirboy kernel module relies on devfs or udev to create its device node. If your system supports devfs or udev, you can skip this step.
If for some reason you do not have udev or devfs installed, you need to create the device node by hand:
Refer to the LIRC documentation about installing, configuring and using LIRC in your applictions.
In order to get the LIRC daemon to use the usbirboy kernel module, you need to start the daemon with this argument added:
Note: How to start the daemon and set the arguments varies between distributions.
Edit /etc/conf.d/lircd to include:
During the lirc package installation, answer "None" to the questions about "Remote control" and "IR transmitter". Then add these lines to /etc/lirc/hardware.conf:
Do not forget to include your remote control(s) in /etc/lirc/lircd.conf.
Feel free to send us your success stories =D
The kernel module was created using usbskeleton from the linux kernel USB core.
The kernel module is only for 2.6 or newer kernels. Feel free to submit patches to make it 2.4 compatible.
The MCU code was originally developed using CodeWarrior since we thought there was no native Linux compiler for this MCU. This was not true and the current MCU code can be compiled using SDCC. Unfortunately we were not able to compile working MCU code using SDCC.