-
Notifications
You must be signed in to change notification settings - Fork 319
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
USIWire #125
Comments
Oh wow - that's fantastic! As you may know, the longterm plan is to distribute my core with an SPI and Wire library that (using a few #ifdefs) transparently picks the right SPI or Wire implementation for the chip in question, so that the user can just #include <Wire.h> and use it to talk to something - and on the 88 with real I2C, it'll use that, and on the USI-based ones, it'll use that, and on the ones with no hardware I2C master support, it'd do SoftWire. It's actually very nearly working for SPI (master only), but it was much harder for I2C, becuase I didn't have a decent I2C library to build it up from. Your USIWire sounds like it would be perfect for this, since you've actually implemented the whole API instead of just a few snippets of it. I hope to be able to give your USI library a spin this weekend and see if I can break it with my army of exotic USI-equipped ATTinys. What's your thoughts on the "Universal Wire" concept? Very exciting news, thank you much for writing this code, and for getting in touch with me! |
Nice to hear, that you are interested in integrating. I simply was thinking to have a I would be happy to have something like this, because it makes Android sketches/libraries more portable and there is no need for quirks on ATTiny boards. Did you already tested USIWire with your "army of exotic USI-equipped ATTinys"? |
there's a new branch UnifiedWire which has a first attempt at unifying Wire and USIWire! No support for things that need to use software master, hardware slave yet. That'll be harder. Same deal with that - it builds on everything it's expected to, but nothing has actually been tested. See also issue #53 - these are exciting times! |
Thanks, I was not aware of #53. The UnifiedWire branch, looks good. But why did you duplicated the code from USIWire.(h|cpp) to Wire.(h|cpp)? Would not be a simple |
I had tried to make that work, but was having trouble getting all the conditionals to resolve correctly. I finally sorted it out, but by that point I had already merged the files; I'm unsure if it will work if I don't do that, but I was getting sick of pounding it at that point. |
In master now per PR #137 |
Hi and thanks for ATTiny Core!
I use it with a ATtiny85 and since the ATtiny85 hardware is ideally to act as a I2C slave I was interested in using the ATtiny85 in one of my projects. Unfortunately, TinyWireS is not really stable, did not follow the current Wire API and did not fit my needs. Thus, I started to write a new USI I2C implementation: USIWire
It supports slave and master mode, fully support callbacks in slave mode and includes a test suite. The test suite test for example SMBus communication with other Arduino-Wire implementations. I tested it against an Arduino Leonardo with the ATtiny in slave and master mode.
@SpenceKonde: I also saw your pull request (adafruit/TinyWireM#3) on TinyWireM and integrated ATTiny1634 support in USIWire. Would be nice if you could give it a try. ;-)
I would be happy, if you would link to USIWire form your documentation. Also, we can discuss, if USIWire should be integrated in ATTiny Core.
The text was updated successfully, but these errors were encountered: