Silly iPod Remote
If things go as I hope, the following will take an iPod with it’s serial RX line connected to RB0 and skip it forward one track when the tactile switch RA0 on my dev board is pressed:
program ipod_next_track_test
dim buttonstate as byte
Soft_Uart_Init(PORTB, 1, 0, 9600, 0)
main:
while true
if Button(PORTA, 0, 1, 1) then
buttonstate = 255
end if
if buttonstate and Button(PORTA, 0, 1, 0) then
Soft_Uart_Write(0xFF 0x55 0x03 0x02 0x00 0x08 0xF3)
buttonstate = 0
end if
wend
I just have to make an appropriate cable and I can test it. (The one I had made broke.)
Now, if that works I can get to work on making the EUSART on the chip respond to the Honda Music Link with enough intelligence to make it think that an iPod is present.
Then, if that works I can get to work on making some of the commands received from the HML act as the aforementioned button press, and I’ll have negated the function crappyness of the HML.
After that point I can make up a cheesy little PCB for the circuit and a PIC16F688 (the smallest PIC I could find with an EUSART) to sit permanently in the car. It shouldn’t need much more than the PIC, a crystal (because I’m not sure the mikroElektonika stuff can set the frequency on the internal oscillator), either a LM78L05 or small switching regulator, headers for the DIN connector cables, and a couple of caps. If I’m bored enough I might even make it my first SMT board.
Hmmm, based on how I am interpretting your words and code, I think you will find a problem… unless you like skipping a lot of songs.
I would advise thinking of things on smaller terms. A key press which consists of a press and unpress. The waveform looks like a tiny square wave with an active and inactive period. And indicate a min length of press for a real event to qualify. That way only skip one song not 20 or no false positives becuase of a noisy line.
Of course, if you already meant to do this, great and ignore this.
Thanks for the idea, but I’m pretty certain it’ll work. Button() debounces things. The third argument to it is the debounce time in ms. Here’s the example of using it to flip the state of PORTD:
So, you can see I pretty much just ripped that off. Button() will only return 0 or 255.
Oh, I guess I could have read this. The debouncing is done in software? Crazy.
Download this, open the help file, look under the Libraries, then in one of them (Utilities, I think) there is just one call, Button(). It explains it a bit better.
And I thought the point of putting something like a 10K resistor at a switch (to ground, if the switch normally ties the signal line to 5V or whatnot) to keep the switch from bouncing? Or is that just to act as a drain and establish a definite state when the switch is not depressed?
Actually, in the case you describe the 10k resistor to ground would be a pull down resistor. It’s to establish a steady 0V or ground when the pin is not tied high. It is of a high value to also limit the current that can flow from the power rail to ground when the switch is closed.
I *think* that’s what I was thinking when writing that earlier. I think.
Yeah, the 2nd part of your earlier comment. It is basically to establish a default value rather than having a floating input. Doesn’t do much to prevent switch bouncing, but that doesn’t appear to be a problem anyway.
It doesn’t require much overhead to do the filtering in software, basically ignore state changes that are shorter than some specified amount of time… but I always figured it was easier to just use a capacitor and free up the cycles.
In large-scale manufacturing, though, where every capacitor costs money and code is free after it is written, I can see why it would be done this way.
Ahh, now I’m seeing how a cap could be used to smooth out bouncing. That makes sense.
Yeah, PICs are interesting things, it seems. and the mikroBasic seems to make it really easy to do some things. Here I was wasting my time before on trying to write a decoder for the iPod serial protocol, and I think I’ll just do it by hand (I think I’ve got enough captures to get a good start) and just throw whatever in there in basic. If I use the dev board as a prototype harness it’ll be really easy to make the actual device.
Oh, and a recruiter from your new employer has contacted me. I might be going down that path now…
I just got my first iPod a few days ago (a shuffle that I got for free :D) so I got to thinking about the data interface through the headphone jack. I’ve got plans for interfacing with my Prius’ touch-screen as well as headphones that I can “dock” it on with maybe some buttons over the cans or something.
Good luck with the job prospect. I know a few other people who might be coming on board as well. One big happy family. If you want/need a recommendation, let me know (and let me know what job it is for) … or did I already make that offer? It’s been a crazy couple of weeks and my brain is full.
Thanks. You already made the offer, but I’m not completely certain I’ll need it yet. I’ll let you know. :) Mind if I get your personal email address, though? Mine is c0nsumer@nuxx.net, as in LJ info. This is for an internal sysadmin position. Some of the need-to-know stuff is a bit new to me, but it shouldn’t be a problem.
Oh, and just so you know, a friend of mine from online is working on a IEbus to iPod (with a PIC sitting in between) dev board. Complete with IEbus communications hardware. If he might have a spare one available, I can let you know…
Thanks. You already made the offer, but I’m not completely certain I’ll need it yet. I’ll let you know. :) Mind if I get your personal email address, though? Mine is c0nsumer@nuxx.net, as in LJ info. This is for an internal sysadmin position. Some of the need-to-know stuff is a bit new to me, but it shouldn’t be a problem.
Oh, and just so you know, a friend of mine from online is working on a IEbus to iPod (with a PIC sitting in between) dev board. Complete with IEbus communications hardware. If he might have a spare one available, I can let you know…
I just got my first iPod a few days ago (a shuffle that I got for free :D) so I got to thinking about the data interface through the headphone jack. I’ve got plans for interfacing with my Prius’ touch-screen as well as headphones that I can “dock” it on with maybe some buttons over the cans or something.
Good luck with the job prospect. I know a few other people who might be coming on board as well. One big happy family. If you want/need a recommendation, let me know (and let me know what job it is for) … or did I already make that offer? It’s been a crazy couple of weeks and my brain is full.
Ahh, now I’m seeing how a cap could be used to smooth out bouncing. That makes sense.
Yeah, PICs are interesting things, it seems. and the mikroBasic seems to make it really easy to do some things. Here I was wasting my time before on trying to write a decoder for the iPod serial protocol, and I think I’ll just do it by hand (I think I’ve got enough captures to get a good start) and just throw whatever in there in basic. If I use the dev board as a prototype harness it’ll be really easy to make the actual device.
Oh, and a recruiter from your new employer has contacted me. I might be going down that path now…
That’s one thing with mikroBasic, though… It really abstracts things away from you, so there’s a good chance that it will take a bit more time than just doing it in hardware does, but as I really don’t know asm, I figure it’s a good way for me to Just Get Stuff DoneTM.
That’s one thing with mikroBasic, though… It really abstracts things away from you, so there’s a good chance that it will take a bit more time than just doing it in hardware does, but as I really don’t know asm, I figure it’s a good way for me to Just Get Stuff DoneTM.
Yeah, the 2nd part of your earlier comment. It is basically to establish a default value rather than having a floating input. Doesn’t do much to prevent switch bouncing, but that doesn’t appear to be a problem anyway.
It doesn’t require much overhead to do the filtering in software, basically ignore state changes that are shorter than some specified amount of time… but I always figured it was easier to just use a capacitor and free up the cycles.
In large-scale manufacturing, though, where every capacitor costs money and code is free after it is written, I can see why it would be done this way.
I *think* that’s what I was thinking when writing that earlier. I think.
Actually, in the case you describe the 10k resistor to ground would be a pull down resistor. It’s to establish a steady 0V or ground when the pin is not tied high. It is of a high value to also limit the current that can flow from the power rail to ground when the switch is closed.
Download this, open the help file, look under the Libraries, then in one of them (Utilities, I think) there is just one call, Button(). It explains it a bit better.
And I thought the point of putting something like a 10K resistor at a switch (to ground, if the switch normally ties the signal line to 5V or whatnot) to keep the switch from bouncing? Or is that just to act as a drain and establish a definite state when the switch is not depressed?
Oh, I guess I could have read this. The debouncing is done in software? Crazy.
Thanks for the idea, but I’m pretty certain it’ll work. Button() debounces things. The third argument to it is the debounce time in ms. Here’s the example of using it to flip the state of PORTD:
So, you can see I pretty much just ripped that off. Button() will only return 0 or 255.
Are you talking about mechanical switch bouncing? That’s what debouncing capacitors are for: cleaning up the noisy square waves you get as you press and release the button.
it was more like i was thinking if someone slightly depresses the button and doesn’t mean to make a full press, it may be detected as a real press. a real press would usually be held a certain amount of time.
anyway, consumer says he’s compensated for it.
it was more like i was thinking if someone slightly depresses the button and doesn’t mean to make a full press, it may be detected as a real press. a real press would usually be held a certain amount of time.
anyway, consumer says he’s compensated for it.
Are you talking about mechanical switch bouncing? That’s what debouncing capacitors are for: cleaning up the noisy square waves you get as you press and release the button.
Hmmm, based on how I am interpretting your words and code, I think you will find a problem… unless you like skipping a lot of songs.
I would advise thinking of things on smaller terms. A key press which consists of a press and unpress. The waveform looks like a tiny square wave with an active and inactive period. And indicate a min length of press for a real event to qualify. That way only skip one song not 20 or no false positives becuase of a noisy line.
Of course, if you already meant to do this, great and ignore this.