thanks for the tip with the diode, I already had a diode on the pull up, but adding a second one did the trick quite well.
The minimum voltage of 2V in high state isn't a problem at all. The CEC bus is idle on high and active on low, This means that every device on the bus (including our own circuit) is pulling the bus high with a 27kOhm resistor while receiving/waiting for a transmission.
So if your circuit is pulling the CEC hight state to something > 3V the "logical 1 voltage" will always be equal or above this voltage, since every other pull up should be secured by a diode (ok not counting the leakage through the input pins, but this should be minimal). There is nobody really outputting a "logical 1 voltage", just all the pull up resistors resistors are bringing back the wire to high state. That's the reason why a transition of low to high can take up to 5 times longer than a transition of high to low and only on high to low a negative overshoot of 300mV is allowed.
For transmission all you have to do is turning your pull up off and pulling the wire down to 0V while being prepared that a current of max 3.6V/(27kOhm/10)=~1.3mA is flowing through your pull down.
Did I get it right or is there anything wrong in my thoughts?
When I think about it now, could I underestimate the leakage of the other input circuits? The input leakage of the MSP430 is something about 5nA, measured when connecting 3V to the pin, and I expect other devices to have about the same.
Anyway on the MSP430 you won't have this problem at all, according to the documentation everything above 1.35V is considered as high and everything below 0.75V as low.
Not the best etch in history, but it works! I added connections to the DDI i2c bus for use with Wire.h, though I have not tested it. There is also a pin connected to the hotplug wire, which again I have not yet tested.
One of the things I did was remove all the pins left of the CEC pin, so I had less bridging to worry about. Feedback is welcome, I am by no means any kind of expert on PCB layout.
Hi everybody
I was playing with RainShadow CEC bridge for a few weeks before I've discovered this thread. I have HTPC, Panasonic TV and CEC bridge and the goal is to control HTPC playback with tv remote. I can successfully control TV (switch on/off, etc) via CEC, but could not transfer any tv-rc controls via bus. So far my best "handshake" with TV is below:
Beside from the adress exchange it looks like that your TV asks you what kind of vendor you are. You report that you have vendor id 10 01 03 (whatever this is). Then the TV requests that you execute a vendor specific command, which is reqjected by you. Then the TV requests to execute a vendor specific command with a vendor id, which is again rejected by you.
I would try to send a [“Activated”] message to the TV instead.
10 01 03 is related to vendor-specific command, not "Device Vendor ID", which was Panasonic (00 80 45)
Rejection of vendor-specific commands I've taken from the log on previous page (5), which happens between real Panasonic receiver and TV.
Will try Menu Status "Activated" command anyway - thanks
I'm clicking arrow menu buttons, can see that led green light on TV is blinking (so the command is received), but nothing is transferred via cec line.
My understanding is that I've responded to all of the requests correctly. Moreover, I'm sure device works ok, because I can switch TV on issuing '04' command.
Maybe the problem is that I'm using my own piece of code, written in C#. Do you guys have kind of standard module, that can communicate to CEC devices?
I'm working on a C++ object to sit atop what Phil has done, to initially provide a basic set of responses to other devices. Nothing usable yet. I'd like to have some standard based communication mechanism between this object and code running on the PC, so the arduino could hold some basic state (like display name, what is supported...) and pass along other things for the PC side to handle.
I'd be interested in seeing what you've got in C# if you want to post a link.
Any opinions on the format for sending and receiving packet data and settings between the arduino and pc? There is the option of sending the bytes binary, with a small header, or something text based like the RainShadow device.
1 byte for the length of the packet, followed by the packet data.
Special events are transmitted with the msb of the length byte set:
0x01-0x0F Length of the following packet
0xF0 Transmission suceeded
0xF1 NAK received while Transmitting
0xF2 Arbitation lost.
etc..
Just before Christmas I got the idea to use CEC for HTPC control. A few weeks ago I discovered this topic which I think is very elegant. I ordered an Arduino Duemilanove which was delivered last week and currently I am collecting the components required for the interfacing.
In order to avoid the HDMI header soldering I plan to cut an HDMI cable and wire it directly to a breadboard for now. Do you guys expect any problems with such a setup?
I'm using such a cable. You don't need to cut the cable in two halfs, just open the cable with caution and attach your cable to the needed wires. These wires for GND, CEC, Hotplug detect, I2C, etc. are non-shielded wires in opposite to the TDMS links, so you can easily identify them.
#Edit
Here the colors from my cable, yours may be different:
Today the parts arrived. I built the circuit on a breadboard according to Mike T's schematics. I noticed that Andres uses 3 additional resistors with his etch. Is there any reason for that?
I removed the shield of one side of the HDMI cable. Currently no soldering iron available so I cannot make the connections inside the cable. According to the schematics by Mike T, only the CEC pin and DDC/CEC ground pins are connected. So I can leave all other wires?
My etch has connections for the i2c pins as well as the hotplug and 5v pins. Those are not required, the CEC part of the etch is based on MikeT's design. I actually plan to update my design to allow the 5v pin to be turned off, as it makes the hdmi port appear "active" on my Samsung tv. Just haven't had any time for this project recently. I do have working code that reads and parses the EDID frames to determine the port ID, if anyone is interested I can post it.
I placed all components on a breadboard according the scheme. Connected the I/O pins with my Arduino. Now the only two connections to be made are the CEC en CEC ground wires (long yellow and green wires leaving the right side of the picture below). Currently waiting for a decent soldering station to connect the two wires to a cracked HDMI connector.
One of the nice aspects of the HDMI spec is that compliant devices are required to tolerate shorts on any wire, so in theory you have some reasonable assurance that you probably wont destroy your TV with this project... maybe.
