Skip to content
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

Closed
puuu opened this issue Apr 28, 2017 · 6 comments
Closed

USIWire #125

puuu opened this issue Apr 28, 2017 · 6 comments

Comments

@puuu
Copy link

puuu commented Apr 28, 2017

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.

@SpenceKonde
Copy link
Owner

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!

@puuu
Copy link
Author

puuu commented May 11, 2017

Nice to hear, that you are interested in integrating.

I simply was thinking to have a Wire.h with a few #ifdefs to load the right Wire provider, e.g. #include <USIWire.h> for USI-based boards.

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"?
You may can have a look to the provided examples for testing ;-) .

@SpenceKonde
Copy link
Owner

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!

@puuu
Copy link
Author

puuu commented May 15, 2017

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 #include "USIWire.h" in Wire.h enough?

@SpenceKonde
Copy link
Owner

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.

@SpenceKonde
Copy link
Owner

In master now per PR #137

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants