search

usedbytes / neopixel_i2c

AVR-based i2c-slave Neopixel driver
GNU General Public License v2.0
31 stars 5 forks source link

Problem communicating with raspberry pi #3

Closed cambazz closed 7 years ago

cambazz commented 7 years ago

Hello,

I replicated the circuit, programmed an attiny85, and connected it to my rasberry pi.

I am using "i2cset -y 1 0x40 reg_adress value" notation. Unfortuntely I could not get to leds to light, exceot one of them is always green, at boot. I then hooked up a usbee logic analyzer, to SCL, SDA and PB3. I can clearly see scl and sda, and then the pb3 generating led patterns, but leds will just not work.

I also get write failed, like half of the time. When I get write error, the PB3 will not generte led pattern.

What is the i2c speed that this program expects? Is it the default 100khz?

usedbytes commented 7 years ago

Hi,

Sorry to hear you're having problems - here's a few ideas.

(Assuming you haven't changed the code) When the chip starts up, it should show a red scrolling pattern on the LEDs until you send something over i2c. If you just plug in power and no i2c, do you see this? If so then the neopixel side of things is fine. If not then perhaps the fuses aren't set right, did you run make fuses? (it sets up the 8 MHz internal oscillator with no divider).

Once the neopixel part is fine, there's some things to try on the i2c side.

The Pi i2c master has a bug (https://www.raspberrypi.org/forums/viewtopic.php?p=146272) which impacts clock stretching (which my slave code implements). Basically, the AVR will hold the clock pin low while it's busy. This is part of the i2c protocol, and the Broadcom hardware in the Pi is buggy in this regard. Paradoxically, the best way I've found to workaround this is to actually increase the i2c frequency. So, if you've got the neopixels working as above, I'd try setting the i2c frequency to 400 kHz and see how you get on. The AVR code itself doesn't really have any limitations on i2c frequency - it should work at any frequency, and it uses clock stretching to get its work done.

If you've got some other chip (say an Arduino or something) which you can use as an i2c master, you could try sending the i2c commands from that, just to check if it's the Pi's i2c hardware that's causing you trouble.

On your logic analyzer, does the AVR acknowledge the i2c transfers (SDA goes low in the 9th clock cycle)?

Does i2cdetect -y 1 show the AVR at the right address?

cambazz commented 7 years ago

So, it was the make fuses - and now it works.

I have read about the clock stretching problem, the last forum post is at 2015. So far I have not experienced problems (like failure to write - that i got previously)

So, I would like to modify your software to drive 5 leds only, and talking a similar protocol like PCA9685. The reason I would like to do this is to save space in a hobby robotics setup. The only difference is that PCA9685 uses 2 bytes per channel, and your implementation uses 1 bytes per channel. I can also get the MSB of the pca9685s data.

Thank you for opensourcing your code.

Best regards, C.

usedbytes commented 7 years ago

Great, glad it's solved. If you think your modifications should be merged here just send a pull request and I'll take a look.

The actual LED driving is from https://github.com/cpldcpu/light_ws2812, so if you add a new LED type it would probably be best to send a pull request to cpldcpu, and then I can update my submodule.