I2C Communications?
Archiver
Posts: 46,084
Any way to make it faster? Can manually bit-banging the ports outrun
an i2cin/i2cout command?
Followup: Is there a non-microprocessor I2C device that can handle an
I2C transfer (read from one device, writing of the read data to
another device) for me?
an i2cin/i2cout command?
Followup: Is there a non-microprocessor I2C device that can handle an
I2C transfer (read from one device, writing of the read data to
another device) for me?
Comments
There is this chip
http://www.i2cchip.com/bl233_a.pdf
that you can 'program' with a script using the stamp
that then runs by itself. It requires a crystal though.
Since it has isolated i2c buses it may do what you require.
regards peter
Original Message
From: "jmccorm" <jmccorm@y...>
To: <basicstamps@yahoogroups.com>
Sent: Tuesday, March 23, 2004 3:16 PM
Subject: [noparse][[/noparse]basicstamps] I2C Communications?
> Any way to make it faster? Can manually bit-banging the ports outrun
> an i2cin/i2cout command?
>
> Followup: Is there a non-microprocessor I2C device that can handle an
> I2C transfer (read from one device, writing of the read data to
> another device) for me?
>
>
>
> To UNSUBSCRIBE, just send mail to:
> basicstamps-unsubscribe@yahoogroups.com
> from the same email address that you subscribed. Text in the Subject and
Body of the message will be ignored.
>
> Yahoo! Groups Links
>
>
>
>
>
or something similar. The BS2p does I2C transfers about 81 kBits/second
-- you're not going to bit-bang any faster than that on a BASIC Stamp
(SHIFTIN and SHIFTOUT can be used to synthesize I2C routines for
non-BS2p BASIC Stamps, but only runs about half as fast as I2CIN/I2COUT
on the BS2p).
-- Jon Williams
-- Parallax
Original Message
From: jmccorm [noparse]/noparse]mailto:[url=http://forums.parallaxinc.com/group/basicstamps/post?postID=7M9botpx7kJVKz1cDJDvj3s7f7QRKqo8Erv8Vc1BN_dQaT8zrcIgi7PbrYMiYKClJuTnyhYv0nbBlH4f]jmccorm@y...[/url
Sent: Tuesday, March 23, 2004 8:16 AM
To: basicstamps@yahoogroups.com
Subject: [noparse][[/noparse]basicstamps] I2C Communications?
Any way to make it faster? Can manually bit-banging the ports outrun an
i2cin/i2cout command?
Followup: Is there a non-microprocessor I2C device that can handle an
I2C transfer (read from one device, writing of the read data to another
device) for me?
> If you want faster you should write your own code running on an SX
> micro or something similar. The BS2p does I2C transfers about 81
> kBits/second -- you're not going to bit-bang any faster than that
> on a BASIC Stamp (SHIFTIN and SHIFTOUT can be used to synthesize
> I2C routines for non-BS2p BASIC Stamps, but only runs about half
> as fast as I2CIN/I2COUT on the BS2p).
About bit banging... I may have just had an epiphany. I have to
transfer data out to 8 I2C devices (MAX 6956s) at the same time. I'm
running a BS2P40, so I've got IO lines to spare.
If I try bit banging *eight at a time* (the low 8 lines for data, and
the high eight lines for clock... although the individual clocks may
be redundant), then I could get 8x the throughput with just toggling
OUTL and OUTH with the values. Think I could outrun a SHIFT IN/OUT and
I2C IN/OUT by toggling OUTL and OUTH to do eight transfers at a time?
you're going to do is going to use require you to do eight separate
reads/writes for your data pins, then a write to your common clock pin.
Where you're going to get killed is in the instruction fetch from the
EEPROM. Using I2CIN or I2C out can send several bytes with only a
single instruction fetch -- you can't do that with your manual method.
Your best bet, as I suggested earlier, is to create your own I2C
coprocessor that will let you send I2C data at the limits of that spec.
-- Jon Williams
-- Applications Engineer, Parallax
-- Dallas Office
Original Message
From: jmccorm [noparse]/noparse]mailto:[url=http://forums.parallaxinc.com/group/basicstamps/post?postID=Uc9zo8rAToLdXEvnGwD0smJpceg45zxKiBjexlYjJX0DdFfctMRbUgBwGORyJGGISuOtJ10DLRrsnO8]jmccorm@y...[/url
Sent: Tuesday, March 23, 2004 9:49 AM
To: basicstamps@yahoogroups.com
Subject: [noparse][[/noparse]basicstamps] Re: I2C Communications?
--- In basicstamps@yahoogroups.com, "Jon Williams" <jwilliams@p...>
wrote:
> If you want faster you should write your own code running on an SX
> micro or something similar. The BS2p does I2C transfers about 81
> kBits/second -- you're not going to bit-bang any faster than that on a
> BASIC Stamp (SHIFTIN and SHIFTOUT can be used to synthesize I2C
> routines for non-BS2p BASIC Stamps, but only runs about half as fast
> as I2CIN/I2COUT on the BS2p).
About bit banging... I may have just had an epiphany. I have to transfer
data out to 8 I2C devices (MAX 6956s) at the same time. I'm running a
BS2P40, so I've got IO lines to spare.
If I try bit banging *eight at a time* (the low 8 lines for data, and
the high eight lines for clock... although the individual clocks may be
redundant), then I could get 8x the throughput with just toggling OUTL
and OUTH with the values. Think I could outrun a SHIFT IN/OUT and I2C
IN/OUT by toggling OUTL and OUTH to do eight transfers at a time?
To UNSUBSCRIBE, just send mail to:
basicstamps-unsubscribe@yahoogroups.com
from the same email address that you subscribed. Text in the Subject
and Body of the message will be ignored.
Yahoo! Groups Links
This message has been scanned by WebShield. Please report SPAM to
abuse@p....
which I was referring. The SX micro (what we use in most BASIC Stamps)
is very fast. It has its own set of tools and programming boards.
http://www.parallax.com/sx/index.asp
-- Jon Williams
-- Applications Engineer, Parallax
-- Dallas Office
Original Message
From: jmccorm [noparse]/noparse]mailto:[url=http://forums.parallaxinc.com/group/basicstamps/post?postID=cYrmP82SwqCnVI5xVuGmewxhIHVM8mj9rxVItaXehVcYO4oYGIfvanSp_R16k2U742zHNoptsETmwA]jmccorm@y...[/url
Sent: Tuesday, March 23, 2004 10:13 AM
To: basicstamps@yahoogroups.com
Subject: [noparse][[/noparse]basicstamps] Re: I2C Communications?
--- In basicstamps@yahoogroups.com, "Jon Williams" <jwilliams@p...>
wrote:
> If you want faster you should write your own code running on an SX
> micro or something similar.
BTW... a side question. The SX stuff. The website is very unclear about
all of it (if you know nothing about it). Does it work with the BS2P40
programming board? Or does it have its own programming boards? Or are
you on your own there? I realize, of course, it would take some
different programming software. (Which Parallax appears to provide for
free.
> Nope ... not gonna work. Why? Because pure bit-banging as you
> suggest you're going to do is going to use require you to do eight
> separate reads/writes for your data pins, then a write to your
> common clock pin. Where you're going to get killed is in the
> instruction fetch from the EEPROM.
Any difference if I combine my eight writes and eight reads by simply
utilizing the INL and OUTL variables to do them all at once, or am I
still killed in the overhead of doing it manually?
individually and these require instructions that must be fetched from
the EEPROM.
You keep insisting that you need more than 81 kbits/second -- how much
faster do you need to go (and stay within the I2C spec)?
-- Jon Williams
-- Applications Engineer, Parallax
-- Dallas Office
Original Message
From: jmccorm [noparse]/noparse]mailto:[url=http://forums.parallaxinc.com/group/basicstamps/post?postID=3BMSDUOjSKprWvQDgAjwLSDCt0_R75jnSmw1X7VNMr8g7AAweVwm_r1xJkMxFedkXCxfPeOB3oY9nO-N]jmccorm@y...[/url
Sent: Tuesday, March 23, 2004 10:18 AM
To: basicstamps@yahoogroups.com
Subject: [noparse][[/noparse]basicstamps] Re: I2C Communications?
--- In basicstamps@yahoogroups.com, "Jon Williams" <jwilliams@p...>
wrote:
> Nope ... not gonna work. Why? Because pure bit-banging as you
> suggest you're going to do is going to use require you to do eight
> separate reads/writes for your data pins, then a write to your common
> clock pin. Where you're going to get killed is in the instruction
> fetch from the EEPROM.
Any difference if I combine my eight writes and eight reads by simply
utilizing the INL and OUTL variables to do them all at once, or am I
still killed in the overhead of doing it manually?
> You keep insisting that you need more than 81 kbits/second --
> how much faster do you need to go (and stay within the I2C spec)?
Here's what I'm doing...
I'm reading in 9 bytes of data from a 24FC515 EEPROM.
I'm writing those same 9 bytes of data to a MAX6956.
(These two operations will set the intensity/color for 6 RGB LEDs.)
NOTE: 9 bytes = 6 RGB LEDs * 3 elements per LED * 1 nibble of
intensity per element
NOTE: With overhead, that should be 13 bytes for the read, and 12
bytes for the write, or 25 bytes (200 bits) for the operation.
I have to do a row across, which will be 8 sets of these operations,
which will control 48 LEDs. (This is a minimum objective. Really, I'd
like to do 96 LEDs across, which would be 19 sets of the above
operation, but I'd consider that highly unrealistic using my current
methods.)
NOTE: I realize that the 24FC515 exceeds the throughput capacity of
the I2C spec, but I wasn't counting on it... that isn't my bottleneck.
In any case, a row should be 1,600 bits for the operation.
Now these 48 LEDs... they're flying through the air. Really! And
they're moving so fast that they leave a trail of color behind them.
So, what we do is we change the color/intensity of the LEDs as they
are moving. Instead of a streak of a single color left behind them,
they can actually paint a picture in the air. (Similar idea: a
fantazein clock, except, on steroids.)
NOTE: The "trail of color" behind the LEDs is, of course, a function
of the human eye, and not so much a trick of physics here. Just for
anyone who read that and thought I was doing something REALLY crazy.
So, this row of 48 LEDs needs to change very quickly. I was shooting
for at least 100 times per second. It needs to change so fast because
of how long the human eye will hold an image, and the more times a
second it changes, the faster that I can move it and the more
resolution I can create along the axis of movement.
Should be well within a 400kbit/s transfer rate of an I2C bus. (Of
course, multiple buses could be used, but the bus really isn't the
bottleneck, from what I see.)
If you do see a better way of doing this, I'm all ears.
You're trying to move a lot of data in a very big hurry -- you might
want to program this app into an SX micro or PIC micro.
-- Jon Williams
-- Parallax
Original Message
From: jmccorm [noparse]/noparse]mailto:[url=http://forums.parallaxinc.com/group/basicstamps/post?postID=9lRsTQ-oZs-1aAvF246ts-VPn4JPR9ZTdLwybs6JD3XKGk8z4BWOY9qQeRjAf_LeWwiJqKLGfs8]jmccorm@y...[/url
Sent: Tuesday, March 23, 2004 11:03 AM
To: basicstamps@yahoogroups.com
Subject: [noparse][[/noparse]basicstamps] Re: I2C Communications?
--- In basicstamps@yahoogroups.com, "Jon Williams" <jwilliams@p...>
wrote:
> You keep insisting that you need more than 81 kbits/second -- how much
> faster do you need to go (and stay within the I2C spec)?
Here's what I'm doing...
I'm reading in 9 bytes of data from a 24FC515 EEPROM.
I'm writing those same 9 bytes of data to a MAX6956.
(These two operations will set the intensity/color for 6 RGB LEDs.)
NOTE: 9 bytes = 6 RGB LEDs * 3 elements per LED * 1 nibble of intensity
per element
NOTE: With overhead, that should be 13 bytes for the read, and 12 bytes
for the write, or 25 bytes (200 bits) for the operation.
I have to do a row across, which will be 8 sets of these operations,
which will control 48 LEDs. (This is a minimum objective. Really, I'd
like to do 96 LEDs across, which would be 19 sets of the above
operation, but I'd consider that highly unrealistic using my current
methods.)
NOTE: I realize that the 24FC515 exceeds the throughput capacity of the
I2C spec, but I wasn't counting on it... that isn't my bottleneck. In
any case, a row should be 1,600 bits for the operation.
Now these 48 LEDs... they're flying through the air. Really! And they're
moving so fast that they leave a trail of color behind them. So, what we
do is we change the color/intensity of the LEDs as they are moving.
Instead of a streak of a single color left behind them, they can
actually paint a picture in the air. (Similar idea: a fantazein clock,
except, on steroids.)
NOTE: The "trail of color" behind the LEDs is, of course, a function of
the human eye, and not so much a trick of physics here. Just for anyone
who read that and thought I was doing something REALLY crazy.
So, this row of 48 LEDs needs to change very quickly. I was shooting for
at least 100 times per second. It needs to change so fast because of how
long the human eye will hold an image, and the more times a second it
changes, the faster that I can move it and the more resolution I can
create along the axis of movement.
Should be well within a 400kbit/s transfer rate of an I2C bus. (Of
course, multiple buses could be used, but the bus really isn't the
bottleneck, from what I see.)
If you do see a better way of doing this, I'm all ears.
To UNSUBSCRIBE, just send mail to:
basicstamps-unsubscribe@yahoogroups.com
from the same email address that you subscribed. Text in the Subject
and Body of the message will be ignored.
Yahoo! Groups Links
This message has been scanned by WebShield. Please report SPAM to
abuse@p....