Go Down

Topic: HDMI CEC interface (Read 111374 times) previous topic - next topic

nospam2000

Hi Christian,

one of my goals was to integrate the CEC interface with VDR. I didn't know about the possibilities of the graphics cards, therefore my plan was to use a USB interface like the FTDI chip of the Arduino. Currently I'm using SDTV (no gfx card, just DVB-C with Activy hardware MPEG decoder). When more and more channels become available in German DVB-C TV, I will switch to HDTV with my VDR machine.

I2C without additional IRQ line always requires polling and depending how much of the protocol is implemented on the PC, the maximum polling interval is around 50ms. Is the I2C bus of the gfx card the same as used for DDC? I don't know, if I2C can be used in multi-master mode and if the gfx card could be used as I2C slave. Do you know if I2C slave mode or a IRQ line is supported by the graphics card?

Does the MSP430 have advantages compared to the ATmega168/328? Actually we don't need a ATmega168, we just need 5 I/O pins: CECin, CECout, SDA, SCL and HotPlugDetect, so a ATtiny could be used.

 MikeT

deathsimple

Hi,

yes i use the DDC bus for i2c communication. The advantage of the MSP430 is that you don't need seperate CECout and CECin pins, a digital io pin with the configurable pull resistor is sufficient to get the right voltages to drive the CEC wire. Beside the MSP430 i only need two resistors and a capacitor for the reset logic. Some other advantages are that it needs below 1mA for its power supply, so you can drive it directly from the 5V line inside the HDMI connector and it comes in a nice 14 pin DIL package, so no fumbling with SMD.

At least on ATI chipsets you could use DDC in multi master mode, but i doesn't do this. Packet level transfers are handled inside the MSP430 with a 32 byte ring buffer so with the low CEC bandwith polling it every 200ms for new data is more than enough.

I will try to make some pics of the prototype this weekend if i find enough time for it.

Bye,
Christian.

nospam2000

Hi Christian,

the separate in/out pins and the transistors are not really needed for the ATmega either, but it makes the hardware more reliable. The CEC bus can get very long because it's not just a point-to-point connection like DDC, all HDMI devices are connected to one long bus.

 MikeT

deathsimple

Hi Mike,

do you think this is really necessary? I don't know the ATmega very well, but Texas Instruments states in SLAA377 (http://focus.ti.com/lit/an/slaa377/slaa377.pdf) that the IO pins are CEC compliant, they only connect an additional 27kOhm pull up to 3,6V for testing purpose. I have a Samsung TV, Yamaha RXV465, Blu-Ray player, and two (laptop and desktop) PCs connected to it. Both PCs with my prototype circuit and they work quite reliable.

My biggest worry is the power supply, for the prototype I used a 10kOhm resistor instead of a real DC to DC converter. The MSP430 has an internal voltage regulator, so it isn't so bad as it sounds, but this internal regulator is only reliable in the in the 1,2-4,2V range, and I drive it with 5V+10kOhm resistor :( The result is that I end up with 3,9V on the CEC line instead of the wanted 3,6V. Really need to change that to a real linear regulator.

Christian.

nospam2000

Hi Christian,

you should put a diode between +3,9V and the CEC pull-up anyway, otherwise a pull-up of another device will drive a reverse current through your pull-up when your voltage is somewhat below the other device. With the diode, you will get down to an acceptable voltage of 3.2V.

The bigger problem is the input. The HDMI 1.3a standard says in chapter CEC 4, table 2:
Minimum Output Voltage Logic '1': 2.5V
Low to High Input Voltage Threshold Logic '1': <=2.0V

This doesn't work with Vcc=5V for the ATmega:
Input High Voltage=0.6*Vcc => 3V for Vcc=5V, 1.98V for Vcc=3.3V

When you just connect a TV and a HTPC, this will not be a problem, but when the number of devices grows, it gets more critical. The standard also says:
"The electrical specifications define CEC such that a maximum of 10 devices can interoperate in the worst- case scenario. In practice, many more may be expected to operate together as the worst case is highly improbable."

 MikeT

deathsimple

Hi Mike,

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.

Regards,
Christian.

AndrewNC

I created a working HDMI-CEC shield in Eagle CAD.


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.

Here is the PDF I used for the transfer:
http://www.andrewncarr.com/hdmi/hdmi-cec-shield4.pdf

Here are the Eagle files:
http://www.andrewncarr.com/hdmi/hdmi-cec-shield-eagle-files.zip

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.

ghuron

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:

Packet received: 0 -> 4
83
Packet received: 4 -> 15
84 30 00 04
Packet received: 0 -> 4
8C
Packet received: 4 -> 15
87 00 80 45
Packet received: 0 -> 4
89 10 01 03
Packet received: 4 -> 0
00 89 03
Packet received: 0 -> 4
A0 00 80 45 06 03
Packet received: 4 -> 0
00 A0 04
Packet received: 0 -> 15
80 00 00 10 00
Packet received: 0 -> 15
86 10 00

Is there anything unusual here? Am I doing something wrong? I would be glad to get any hints.
Thanks in advance for help!

deathsimple

If i decode it correctly, the packet sequence you send looks something like this:

len:2 src:0x0 dst:0x4 opcode: 0x83 (Give Physical Address)
len:5 src:0x4 dst:0xF opcode: 0x84 (Report Physical Address) addr:3.0.0.0 device type:Playback Device
len:2 src:0x0 dst:0x4 opcode: 0x8C (Give Device Vendor ID)
len:5 src:0x4 dst:0xF opcode: 0x87 (Device Vendor ID)
len:5 src:0x0 dst:0x4 opcode: 0x89 (Vendor Command)
len:4 src:0x4 dst:0x0 opcode: 0x00 (Feature Abort) feature-opcode: 0x89 (Vendor Command)
len:7 src:0x0 dst:0x4 opcode: 0xA0 (Vendor Command With ID)
len:4 src:0x4 dst:0x0 opcode: 0x00 (Feature Abort) feature-opcode: 0xA0 (Vendor Command With ID)
len:6 src:0x0 dst:0xF opcode: 0x80 (Routing Change) original:0.0.0.0 new:1.0.0.0
len:4 src:0x0 dst:0xF opcode: 0x86 (Set Stream Path) addr:1.0.0.0

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 <Menu Status> ["Activated"] message to the TV instead.

Regards,
Christian.

ghuron

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 :)

AndrewNC

I've got working code to read the physical address from EDID, just need to clean it up, and I'll post it.

Started a vendor capability chart on the googlecode wiki, so we can share info on what vendors/models can do what.

ghuron

Chirstian, According to HDMI specs <Menu Status>[Activate] looks exactly what I need, but I've tried:
Packet received: 4 -> 0
8E 01

And it does not pass any rc command to hdmi bus.
Any ideas what I'm doing wrong?

AndrewNC

Ghuron:
Are you trying to send commands to the tv, or are you expecting the tv to send commands to your device?

What is the model of your panasonic?

ghuron

I'm trying to send it to the tv (->0), which is Panasonic TH-R42PY8

deathsimple

If <Menu Status>[Activated] isn't replied with a <Feature Abort> then all you have todo is convince the TV that you are the active source.

Try the following sequence:
1. Do the address algo stuff, at least send an <Report Physical Address> with your connector address, so the TV can make a mapping between connector<->cec address.

2. Send <Active Source> to switch the TV to your input connector.

3. Send <Image View On> or <Text View On> to confirm that you are the displaying device.

4. Send <Menu Status>[Activated] to tell the TV that you are ready to receive Button Commands.

Go Up