I was looking to convert your project over to function with an Xbox One (It mostly works!). Would I just need to modify the handlers.c file for the correct keypad commands? Also does this support the use of "&" to have multiple key commands at the same time? One of the commands is Windows key and M for the menu which I'm guessing I could use "KEY_CTRL&KEY_ESC&KEY_M"?  I also modified common.h to change the name of the board to Xbox One. Am I missing anything? I haven't set up to program the board quite yet, but I'm a little unfamiliar with the process. Do I just need to boot the Firmware using the process you outlined (DFU jumper solder etc.)? If that's the case, what is the sw folder for? Do I install both?

Something I noticed is that if I'm on a different input, the keyboard shortcuts still override the TV controls which isn't ideal (maybe just the select button?) and it is difficult to change inputs on the TV.  Maybe a future feature could be "muting" the keyboard and allow for normal functionality of the remote if a menu is present or if it isn't on the proper input, or could there be something else at hand. I've programmed in the past, but forgive me, it has been a while so I'm a little slow going through the code, but I have some training in computer science.

Hello,

You can define new handlers, and then associate them to a CEC opcode in main.c. If you just need to remap keys, you can change the content/length of the array in handlers.c. I just adapted the keyboard library from teensyduino with a Lookup Table, as a quick'n'dirty keyboard implementation. I am pretty sure it doesn't support multiple keypresses at the same time as is. The keyboard library does support up to 6 keys with modifiers though. You would have to change the mapping table and the cecKeyDown function. Changing the call to usb_keyboard_press() may be enough., but I never tried it... Otherwise, I guess you would have to use the usb_keyboard_send() function instead of usb_keyboard_press().

Changing the name is alright. I planned to have some kind of EEPROM configuration for that, but I have yet to find the time and an easy way to do it.

To boot the board in DFU, you need to solder the jumper on the board, and trigger a reset (you can either solder the on-board switch or just short the reset to ground with tweezers). The process is outlined in this app note: http://ww1.microchip.com/downloads/en/devicedoc/doc7618.pdf. I planned to add a feature to reboot in bootloader, but it is still on my ToDo list. To flash the board, I use the dfu-programmer tool (installed from apt in Debian). There is also an ICSP connector, for more serious programming, but I find DFU easier and faster to use. If you plan to do a lot of programming, soldering the switch to boot in DFU is a nice option.

The sw/ folder was just for testing HID stuff, for the configuration features that I planned to develop. For debugging output, you can use the hid_listen tool from PJRC.

I never had the issue you mention with the different inputs, since I only have one thing connected to my TV, but it makes sense since the CEC bus is shared by all the devices. There is a notification for the current input and the board is able to identify its own input using the EDID features, it shouldn't be really difficult to match the two and "disable" some features when on a different input.

Actually, in this project, I really focused on the difficult part, the CEC communication. I tried to make an easy to use library and then I built some "demo firmware" around that. It's free for people to use and modify to their needs. Feedback is always welcome, and I will try to improve the "demo" when I manage to find some spare time, but I really can't estimate when. It's also difficult to develop vendor-specific features or workaround since I don't have many TVs. Feel free to send me an email or open a github issue or pull request if you have a specific issue or question or a new feature you find would be nice to merge in the main project, I am always happy to help :)

this little do-dad is pretty cool, would love to see an IR  LED on this so we can intercept cec commands and do cool stuff over ir

Hello,

Sorry I did'nt reply earlier, I didn't get a notification and I lacked time for hobby projects these past months.

There are some GPIOs broken out, initially to control WS2812 LED strips, but you can wire an IR LED instead and write some firmware to send IR codes.

I would like my TV to behave like a monitor, that is, to turn on when the computer is on and awake, and off when it is off or asleep. I can handle the PC side of that (sending a command when the screen saver activates, for example) would this board work to send the relevant power on and power off commands to the TV? Thanks!

Hello,

If your TV supports CEC commands, you should be able to send turn on/off commands with this board. Some firmware development is required though, since the firmware currently only support TV => PC communication (using a keyboard emulation).

To make sure your TV supports the CEC features your need, you can try with a RaspberryPi if you happen to already have one, and the cec-utils package.

Hello. I am interested in your project. I spent a lot of time finding it. On the Internet there are projects with arduino but they are all outdated and no one is discussing them. There are schemes for connecting to the CEC line but without I2C. I’m interested in whether it is possible to make a CEC to UART converter on the basis of your device. Why do I have this, I have an HDMI ARC board that is controlled by an IR remote and a bluetooth TV. I would like to grab the volume control signal on the CEC bus and pass it to the amplifier controller.

Hello,

UART is not straightforward with this design... I use the hardware UART pins to read/drive the CEC line. You could probably use a software UART library if you don't have too high requirements.

I haven't tried the I2C part yet, so I can't say for sure that it works. Since the Atmega32u2 doesn't have any hardware I2C, I will have to use a software implementation but I have already done it on an other project and it went fine, so I believe it should work.

You can probably use the same schematic as a base for a more elaborate board. The hardest part on this project was the firmware/CEC library. As you mentioned, there a very few similar projects available, and most of them look unmaintained/dead, so I had to rewrite one from scratch, in C.

I don't have much time to work on the firmware right now, but the upcoming holidays should help and I will finally be able to release the firmware...

What part is that upside down HDMI connector? I've never seen one like it before but seems super useful for passthrough devices like this!

Hello !

The upside down HDMI connector is the hardest part to find actually. Molex used to make them, TE Connectivity is phasing them out, ... Sales were too low I guess.

I may have to change the design in the future if I don't manage to get a reliable source for theses parts though...

You can find them as "reverse HDMI connectors" on eBay or Aliexpress. Another good source/option seems to be to look for "PS4 HDMI connector", then you can find them on eBay, Amazon, ... but the footprint is a bit different.

Making a pass-through double sided board would be way more difficult without them.

Side note, this is not required for the CEC stuff to work. CEC is a multipoint bus shared by all the HDMI ports of the TVs. Assuming you have a free HDMI port, you can make a board with just the common HDMI connector, plug it in the unused port, and it should work the same way CEC2Usb does.

I've seen feed through with two vertical connectors.

Very clever approach. I've often wondered about hacking in CEC for some of my devices... I have a TV that claims to have CEC but it doesn't seem to work wiht a Fire TV Stick. This would be a fun way to play around -- sniffing what the TV is sending and finding a way to make it actually work.

Hello and thanks for you kind comment. The hardware part is quite simple, I just adapted it from the datasheet of the TDA9950. I think it should be possible to simplify it a little bit to use one I/O instead of two (but I have plenty, so I don't really care). The tricky part is the software. Fortunately, CEC is quite slow (in the milliseconds range) and supported in open logic analyzer softwares, like sigrok, which makes debugging easier.

I am currently refactoring the software to be able to reconfigure it at runtime and/or use the special modes, like the CEC-spy; but I haven't figured the best way yet. I plan post an update and to release the sources as soon as I have improved this.