{"action":"created","issue":{"url":"https://api.github.com/repos/jackhumbert/qmk_firmware/issues/773","repository_url":"https://api.github.com/repos/jackhumbert/qmk_firmware","labels_url":"https://api.github.com/repos/jackhumbert/qmk_firmware/issues/773/labels{/name}","comments_url":"https://api.github.com/repos/jackhumbert/qmk_firmware/issues/773/comments","events_url":"https://api.github.com/repos/jackhumbert/qmk_firmware/issues/773/events","html_url":"https://github.com/jackhumbert/qmk_firmware/issues/773","id":178540270,"number":773,"title":"i2c, ws2812, timer3 conflict? ","user":{"login":"mannkind","id":41883,"avatar_url":"https://avatars.githubusercontent.com/u/41883?v=3","gravatar_id":"","url":"https://api.github.com/users/mannkind","html_url":"https://github.com/mannkind","followers_url":"https://api.github.com/users/mannkind/followers","following_url":"https://api.github.com/users/mannkind/following{/other_user}","gists_url":"https://api.github.com/users/mannkind/gists{/gist_id}","starred_url":"https://api.github.com/users/mannkind/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mannkind/subscriptions","organizations_url":"https://api.github.com/users/mannkind/orgs","repos_url":"https://api.github.com/users/mannkind/repos","events_url":"https://api.github.com/users/mannkind/events{/privacy}","received_events_url":"https://api.github.com/users/mannkind/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":13,"created_at":"2016-09-22T07:24:27Z","updated_at":"2016-09-28T05:21:09Z","closed_at":null,"body":"_This is not a bug or issue, it's just a question._\r\n\r\nI'm trying to use I2C to control the leds on the slave half of a hardwired lets split keyboard with ws2812 leds. It's working, for the most part, except for the led animations. The animations only seem to work on whichever half is the \"master\" keyboard.\r\n\r\n**Is there a conflict between the I2C/ISR and the Timer3/ISR?** \r\n\r\nI swear I've searched for the issue, but I've come up empty handed. I have a feeling this might be why all the examples I've found use one-wire serial communication between the two halves and connect the RGB_DI_PINs via the unused TRRS line."},"comment":{"url":"https://api.github.com/repos/jackhumbert/qmk_firmware/issues/comments/250074337","html_url":"https://github.com/jackhumbert/qmk_firmware/issues/773#issuecomment-250074337","issue_url":"https://api.github.com/repos/jackhumbert/qmk_firmware/issues/773","id":250074337,"user":{"login":"mannkind","id":41883,"avatar_url":"https://avatars.githubusercontent.com/u/41883?v=3","gravatar_id":"","url":"https://api.github.com/users/mannkind","html_url":"https://github.com/mannkind","followers_url":"https://api.github.com/users/mannkind/followers","following_url":"https://api.github.com/users/mannkind/following{/other_user}","gists_url":"https://api.github.com/users/mannkind/gists{/gist_id}","starred_url":"https://api.github.com/users/mannkind/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mannkind/subscriptions","organizations_url":"https://api.github.com/users/mannkind/orgs","repos_url":"https://api.github.com/users/mannkind/repos","events_url":"https://api.github.com/users/mannkind/events{/privacy}","received_events_url":"https://api.github.com/users/mannkind/received_events","type":"User","site_admin":false},"created_at":"2016-09-28T05:21:09Z","updated_at":"2016-09-28T05:21:09Z","body":"FWIW, I tried both `rgblight_animation_poll(timer_read());` and `rgblight_animation_poll(value_passed_via_i2c);` and the animations seem to work the same as the pre-change code as far as I can tell. The animations do diverge within a minute or two, even when using the value passed via I2C. \r\n\r\nI don't want to conflate the issues if they're unrelated, but I'm still having the erroneously reported keypresses issue when animations are occurring on the slave - it doesn't matter which half is the slave and the frequency of the issue _seems_ to be related to the speed of the animation. \r\n\r\nFor fun, here's an output from `matrix_print()` when the issue occurs; no keys are being physically being pressed.\r\n\r\n```\r\nr/c 0123456789ABCDEF\r\n00: 0000000000000000\r\n01: 0000000000000000\r\n02: 0000000000000000\r\n03: 0000000000000000\r\n04: 1100110000000000\r\n05: 1100110000000000\r\n06: 0000000100000000\r\n07: 0000000000000000\r\n\r\nr/c 0123456789ABCDEF\r\n00: 0000000000000000\r\n01: 0000000000000000\r\n02: 0000000000000000\r\n03: 0000000000000000\r\n04: 1100110000000000\r\n05: 1100110000000000\r\n06: 0000110000000000\r\n07: 0000000000000000\r\n\r\nr/c 0123456789ABCDEF\r\n00: 0000000000000000\r\n01: 0000000000000000\r\n02: 0000000000000000\r\n03: 0000000000000000\r\n04: 1100110000000000\r\n05: 1100110000000000\r\n06: 0011001100000000\r\n07: 0000000000000000\r\n```\r\n\r\nAll that said,  I don't know how much more of anyone's time I should waste if I'm the one of the only people trying to use this 'feature' :) There seems to be a decent work-around – I've tested the Serial setup and used the (now)spare conductor in the TRRS cable to control the LEDs. That seems to be working, LED animations included, without any major issues … though technically slower, I guess.\r\n\r\n"}}
{"actor":{"display_login":"mannkind"}}