Deeming the current USB stack for the USB Ir Toy (v22 and v23) to be unstable/unreliable and due to the fact that firmware updates for the device seem to have stopped, I performed a quick search for open source USB stacks and found M-Stack. It appears to be maintained, unlike the stack included in the Toy's firmware, and suitable for the PIC 18F2550.
Would there be any advantage using this USB stack over the current one included in the firmware and has anyone attempted to use it already?
I'm no C programmer, I don't have a lot of knowledge about electronics, nor do I know how to build the Toy's firmware. Are there any intentions to work on the Toy's firmware again and would including this stack be an option?
For some reason my USB IR Toy doesn't come up after rebooting my Rasbarry Pi. Where /dev/ttyACM0 is nicely created when performing a fresh RPi start-up (i.e. disconnection and reconnecting the power), this isn't the case when telling the RPi to reboot. Instead, dmesg is giving me a series of usb 1-1.2: device descriptor read/64, error -32 errors:
OpenELEC:~ # dmesg ... [ 13.043818] usb 1-1.2: device descriptor read/64, error -32 [ 13.090780] systemd-udevd[196]: starting version 214 [ 13.227193] usb 1-1.2: new full-speed USB device number 5 using dwc_otg [ 13.403376] Console: switching to colour dummy device 80x30 [ 15.137466] pcm512x 1-004c: Failed to reset device: -5 [ 15.150748] pcm512x: probe of 1-004c failed with error -5 [ 15.215250] bcm2708-i2s bcm2708-i2s.0: Failed to create debugfs directory [ 16.937918] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup [ 16.939565] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [ 18.353850] usb 1-1.2: device descriptor read/64, error -32 [ 18.490409] input: lircd as /devices/virtual/input/input0 [ 18.573904] smsc95xx 1-1.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0x45E1 [ 18.609968] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 23.537379] usb 1-1.2: device descriptor read/64, error -32 [ 23.720572] usb 1-1.2: new full-speed USB device number 6 using dwc_otg [ 29.130120] usb 1-1.2: device not accepting address 6, error -32 [ 29.210534] usb 1-1.2: new full-speed USB device number 7 using dwc_otg [ 34.617042] usb 1-1.2: device not accepting address 7, error -32 [ 34.617331] hub 1-1:1.0: unable to enumerate USB device on port 2 [ 34.697232] usb 1-1.3: new full-speed USB device number 8 using dwc_otg [ 34.809228] usb 1-1.3: New USB device found, idVendor=2548, idProduct=1002 [ 34.809281] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 34.809300] usb 1-1.3: Product: USB-CEC Adapter [ 34.809315] usb 1-1.3: Manufacturer: Pulse-Eight [ 34.809331] usb 1-1.3: SerialNumber: v2 r8 [ 34.867145] input: Pulse-Eight USB-CEC Adapter as /devices/platform/bcm2708_usb/usb1/1-1/1-1.3/1-1.3:1.2/0003:2548:1002.0001/input/input2 [ 34.875723] hid-generic 0003:2548:1002.0001: input,hidraw0: USB HID v1.10 Mouse [Pulse-Eight USB-CEC Adapter] on usb-bcm2708_usb-1.3/input2 [ 35.124791] cdc_acm 1-1.3:1.0: ttyACM0: USB ACM device [ 35.141874] usbcore: registered new interface driver cdc_acm [ 35.141918] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
I had to make a drastic snip in the dmesg log because the forum deemed it "too spamy".
The device will properly show up again when unplugging and reconnecting the Toy in this state.
I'm running firmware v22 on the USB IR Toy.
What can be the cause of the problem and how can I fix it?
Update 1: Even a fresh start-up of the RPi will not always properly initialize the Toy, resulting in the same problems as above. Update 2: Forget the previous update. The Toy appeared to be completely dead, not functioning on any system any longer. It required me flashing the firmware again to get it up and running again. :-S
