When this…<\/p>\n
sendCommand(mode2, 0)
\nsendCommand(playButton, 0)
\nsendCommand(relButton, 0)<\/tt><\/p><\/blockquote>\nWhich supposedly sends these commands…<\/p>\n
const mode2 as byte[5] = (0x03,0x00,0x01,0x02,0xFA) 'Simple iPod Remote
\nconst playButton as byte[5] = (0x03,0x02,0x00,0x01,0xFA) 'Play Button
\nconst relButton as byte[5] = (0x03,0x02,0x00,0x00,0xFB) 'Release Button<\/tt><\/p><\/blockquote>\nGives me this in the serial console…<\/p>\n
Received: 0xFF 0x55 0x03 0x00 0x01 0x02 0xFA 0xFF 0x55 0x03 0x02 0x00 0x01 0xFA
\nReceived: 0xFF 0x55 0x03 0x02 0x00 0x00 0xFB <\/tt><\/p><\/blockquote>\n…I know it’s time to go home.<\/p>\n
And yes, as suggested earlier<\/a> I just went ahead pre-calculated the checksums. I also just bundled the packet lengths in there too, and I read that first bit to determine how many bits have to be sent so that packets of arbitrary length may be sent simply by defining them as a constant. <\/p>\n
It’s sending back to the PC properly, but not to the iPod. I think that’s because of some weirdness with the pins I chose to use. It worked fine on the PIC16F88, but for some reason that thing cooked this morning. (It now reports itself as some 12F part, likely indicating that some of the bits which indicate the part type have failed.)<\/p>\n
Now to get the part running from the internal oscillator instead of a crystal and responding to commands from the serial port. (Both of these should be fairly easy.)<\/p>\n
After that I can start building the list of responses I want sent to the Honda Music Link (initial by-hand decoding of a sample conversation between my iPod and the HML can be seen here<\/a>). Then once that’s all set it’s time to plug it into the car and hope things work as designed. If that<\/em> works it’s time to design the PCB and see about producing a dozen or so.<\/p>\n