Again I have to agree with Bart that it is best to keep the com port open during sessions but I have to add that you must close it before you quit you host app and you must also reset the irtoy from sample mode before you close the comport. The best way to reset the irtoy is to send it a string of 0xFF, 0xFF, 0xFF 0xFF, 0xFF, 0x00. This will work for every predicable, if unlikely case and for all the irtoy firmware (including mine.)
The problem of the irtoy not responding in the transmit mode is really a problem with the irtoy and the host not working together. If you give the irtoy what it wants when it wants it and nothing else then the transmit mode pretty much works well. At least from everything I have seen and I have send mind a lot of codes without trouble.
Atomic mode firmware for the irtoy would be nice especially if it turns out the rPi is not able to send and receive fast enough.
Agree with Bart. I'm using the irtoy with other software and it plays from files ok. Not that there is anything different between playing from a file or from memory as for as the irtoy knows.
Short PGD and PGC together and then plug in the IR TOY. Do NOT use the update batch file, instead use this command line: fw_update -e -w -v -m flash -vid 0x04D8 -pid 0xFD0B -ix USBIRToy.v22.hex
You could put that in a batch file and add the pause command if you want to see all the feedback.
Unfortunately, the diolan bootloader is known to be bugged. There has been some talk about it on the microchip forum.
It did not matter with win XP but it appears some flavors of linux and windows just cannot handle the bugged diolan bootloader. This applies to all flavors of the bootloader and it is not a problem just with the dangerous prototypes variation.
I have attached the fixed bootloader hex (Edit: I found my fully corrected source too!) as per the instructions I found on the microchip web site. This will require a programmer to put into the 2550 unfortunately and there is no guarantee that it will fix the issue but there is some chance that it may based on what others have found.
Edit: Also found out that the inf file is also wrong. The PID needs to be changed to use microchip's standard cdc VID (0x000A) and the IR TOY needs to use the microchip inf file. If unmodified this will be signed and work with 64-bit windows and probably Windows 10.
Seen this discussed before on this forum and I'm pretty certain the deal is that none of these files are needed anymore. They can be deleted from the project. Seems someone created the mplabx project from a mix and match of the old mplab 8 project file and the new source code files.
I doubt the bootloader has been over written. It is designed so that it won't overwrite itself. Shorting the PGC and PGD pins together at power-up may bring the bootloader online.
If you are using REC&PLAY (AKA irtoy.exe) make sure that you have the non bugged version. For the NEC (LG) protocol the first BYTE value returned must not be 0. On the bugged version it is.
[quote author="ElectronicGuru"]Could it be, that the Toy crashes in case it just sits there (connected to USB, but no SW operating the toy) and receives IR signals from a remote? It seems that mine does that.
Thanks for insights[/quote]
Why not try some things out? Open a terminal can connect to the sample mode by sending an 'S' After you receive S01 back any else sent will be something that the IR TOY regards as a IR signal. Leave it over night or for how long and see what happens.
In my own tests if the ir toy is still working after several hours of being idle under windows I consider it bonus. I do expect that I will have to reset it to recommence testing with it. With the RPi which is not as aggressive with the IN endpoint spamming the ir toy seems to still idle without problem.
Somewhere here I saw talk about making the ir toy a HID class device. For times when it is going to be used as a always on always ready dongle that is what it needs to be. IMHO there needs to be two classes of firmware because people are using the ir toy now in two very different ways.
I've been doing a lot of the PC side coding and testing and I have repeated the exact same experiment with the RPi and I simply cannot get the ir toy to fail in normal operation. This is still with the older firmware too...
Don't know what the difference is but I had no problems repeatedly rebooting my RPi and having the ir toy work again without a replug. I tried this many times and it just worked without fail. I am just using the official firmware V22 though I have later versions. So, what is the difference here I wonder.
[quote author="ElectronicGuru"]Excellent hint! I switched of handshaking "h off" and everything is working fine. Seems that double buffering is buggy.[/quote]
Great that you got it to work better but again, the double buffering has nothing to do with the handshake.
