Open GoogleCodeExporter opened 9 years ago
+1
Excellent idea!
Actually, I'm using Fabio's writeTo and readFrom routine on each of my I2C
libraries, resulting on duplicated code and lost space.
Thank you for considering Fabio's idea.
Original comment by Vilo.Rei
on 24 Jan 2011 at 7:13
Clearly, this is a valuable refactoring. How do we help push the changes into
the Wire library?
Original comment by clinton....@gmail.com
on 24 Jan 2011 at 4:26
Give the patch a try, look at the patch code and suggest improvements, if
everything looks ok, say so!
Original comment by fabio.va...@gmail.com
on 24 Jan 2011 at 5:40
Hi!
Fabio idea is good, it solves code repetition and especially solves the problem
of having multiple approaches (some better than others) to read/write registers
resulting in more stable code. This should be part of wire library.
-Has anyone noticed sketch size increase by a few bytes when compiling with
patched wire?
-Any reason having int* buff and not uint8_t*?
-I would suggest Overloading writeTo to allow using send(uint8_t*, uint8_t),
something like:
void TwoWire::writeTo(int dev_address, int reg_address, uint8_t* buff, int
quantity).
Regards,
Filipe Vieira
Original comment by fil.vie...@gmail.com
on 27 Jan 2011 at 1:34
1: if the size increase is just a few bytes.. that's ok.. as as soon as we run
more I2C devices they will share the writeTo and readFrom decreasing the total
memory consumption.
2: uint8_t is for unsigned ints.. there are I2C devices which gives you
negative values and you can write negative values to their registers.. that's
why I choose int .. what do you think?
3: yeah, me too. Anyone care to submit a patch?
Original comment by fabio.va...@gmail.com
on 27 Jan 2011 at 10:39
Probably that’s why there is void TwoWire::send(uint8_t data) and then void
TwoWire::send(int data) a simple type-cast to handle signed values... but in
the end it’s uint8_t just check twi_transmit(uint8_t* data, uint8_t length).
Nicer for writeTo and readFrom follow same design? (also less casting)
I've attached a modified patch.
Fil.
Original comment by fil.vie...@gmail.com
on 1 Feb 2011 at 2:31
Attachments:
Sure, internally it will use uint8_t but, as I think of readFrom and writeTo as
high level I used int. Your approach is good but isn't it slower? If users use
int you will call everytime two functions instead of one, isn't so?
Original comment by fabio.va...@gmail.com
on 1 Feb 2011 at 9:45
On Arduino forum (http://arduino.cc/forum/index.php/topic,50082.0.html),
wayneft advised that in twi.c there are functions twi_writeTo() and
twi_readFrom() so we should probably use them instead of relying on Wire
methods.
Original comment by fabio.va...@gmail.com
on 1 Feb 2011 at 12:54
I like these functions generally. The only request I would make it to pull the
available() and receive() calls out of readFrom(). That is, readFrom() should
request the data from the slave, but not actually read it into a buffer. That
makes it more flexible, for example if we add other receive methods. Also, do
you need the second beginTransmission() / endTransmission() pair in the
readFrom() code? I think you can just call requestFrom().
Also, the twi_writeTo() and twi_readFrom() in twi.c don't do the same thing
(they don't write to or read from a register within the slave device), so you
don't need to change the code to use them.
Original comment by dmel...@gmail.com
on 11 Feb 2011 at 5:31
Following dmellis comment and based on last patch I've made the following
changes to readFrom():
void TwoWire::readFrom(uint8_t dev_address, uint8_t reg_address, uint8_t *data,
uint8_t quantity)
{
beginTransmission(dev_address);
send(reg_address);
endTransmission();
requestFrom(dev_address, quantity);
*data = receive(); // receive a byte
}
works for me! Comments please...
Filipe
Original comment by fil.vie...@gmail.com
on 11 Feb 2011 at 11:36
Thank you David.
Filipe, how could that work with only a call to receive? What about quantity?
Or, am I missing something?
Original comment by fabio.va...@gmail.com
on 12 Feb 2011 at 9:54
Filipe: the readFrom() should receive any data at all, and shouldn't take a
*data parameter. It should just do the requestFrom() and let the caller get
the data using receive() and available().
Fabio: do you want to update and test the patch?
Original comment by dmel...@gmail.com
on 12 Feb 2011 at 5:05
Oh.. ok.. now I get what you mean David.
Personally, I think of readFrom() and writeTo() as high level access to reading
and writing from/to a register (or more) on a I2C device. The idea behind them
was avoiding code repetition and improving ease of use.
But, if we remove receive() from readFrom() we fail at both of them, requiring
more code to be written and making everything more complex.
My idea was to add those functions so that the user could just rely on them for
interacting with a I2C device and forget about anything else.
Also, would you explain what different receive methods could be implemented? I
don't see many different ways to do so.
Original comment by fabio.va...@gmail.com
on 12 Feb 2011 at 6:02
The problem is that you don't necessarily want to read the data into a buffer.
In general the Wire API is inconsistent with the rest of the libraries (e.g.
doesn't implement Stream). I might try to make it more consistent with them,
which would require change receive(), etc. It would easier to do that if it
wasn't integrated into this new function. Basically, the part we'd factor out
is the part for requesting the data (which is always the same), not the part
for actually reading it (which could happen in a few different ways,
potentially).
Original comment by dmel...@gmail.com
on 12 Feb 2011 at 6:22
Original comment by dmel...@gmail.com
on 24 Aug 2011 at 6:50
I've got an I2Cdev library that is built to do exactly this kind of
abstraction, up on GitHub here:
https://github.com/jrowberg/i2cdevlib
The only important bits are the I2Cdev.cpp and I2Cdev.h files. They might be a
little overkill for what you're going for, but they're working great for me and
the rest of those device libraries so far.
Original comment by jeffrowb...@gmail.com
on 31 Aug 2011 at 8:18
I don't know.. the more I dig into Wire and twi.c the more I think that they
are all an over complication.. and IMHO, adding yet another layer it's not a
good idea. When dealing with I2C performance and program memory are key factors
and your code (well designed and documented BTW) doesn't really help.
For what's my use of Wire in my own projects, the following library does about
98% of what I need while being extremely smaller, simpler and faster than Wire.
http://code.google.com/p/simplo/source/browse/trunk/libraries/fastwire/Fastwire.
cpp
Original comment by fabio.va...@gmail.com
on 31 Aug 2011 at 10:40
Original comment by dmel...@gmail.com
on 16 Dec 2011 at 10:08
Original issue reported on code.google.com by
fabio.va...@gmail.com
on 23 Jan 2011 at 4:08Attachments: