IIC in microblaze

D

didaSofi

Guest
hello
I need your help please. I want to connect a gyrocompas(HMC5883L) with a
microblaze which is done by I2c and as microblaze does not have the bus
I2c. I must add it as a peripheral to the microblaze but I do not know how
in EDK
regards



---------------------------------------
Posted through http://www.FPGARelated.com
 
On Sun, 01 Mar 2015 10:10:45 -0600, didaSofi wrote:

hello I need your help please. I want to connect a gyrocompas(HMC5883L)
with a microblaze which is done by I2c and as microblaze does not have
the bus I2c. I must add it as a peripheral to the microblaze but I do
not know how in EDK regards
Click to expand...

You either need to find some I2C intellectual property that you can build
into your project, or you need to make an I2C controller.

AFAIK, I2C is a fairly straightforward interface as long as you have pins
that can be set to open-drain or tri-stated. I haven't had to do it
myself, but I've been on projects where we've had to bit-bang it from a
microcontroller, which was accomplished with minimal screaming.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com
 
On 3/3/2015 1:45 PM, Tim Wescott wrote:
On Sun, 01 Mar 2015 10:10:45 -0600, didaSofi wrote:

hello I need your help please. I want to connect a gyrocompas(HMC5883L)
with a microblaze which is done by I2c and as microblaze does not have
the bus I2c. I must add it as a peripheral to the microblaze but I do
not know how in EDK regards

You either need to find some I2C intellectual property that you can build
into your project, or you need to make an I2C controller.

AFAIK, I2C is a fairly straightforward interface as long as you have pins
that can be set to open-drain or tri-stated. I haven't had to do it
myself, but I've been on projects where we've had to bit-bang it from a
microcontroller, which was accomplished with minimal screaming.
Click to expand...

I2C is not terribly difficult, but the fact that you need to clock from
the actual clock line makes it a little more so. At least that is my
recollection from looking at the spec. If your system clock is fast
enough then you should be able to sample it all in your clock domain. I
guess I'm surprised you could do that reliably with bit banging.
Perhaps I am thinking of some different protocol... it's been too long,
lol. But I do recall there is a way to hang the bus. I think the
Intel version of I2C gets around that with a timeout.

--

Rick
 
didaSofi wrote:
hello
I need your help please. I want to connect a gyrocompas(HMC5883L) with a
microblaze which is done by I2c and as microblaze does not have the bus
I2c. I must add it as a peripheral to the microblaze but I do not know how
in EDK
regards



---------------------------------------
Posted through http://www.FPGARelated.com
Click to expand...

Do you have the EDK or are you just using the MicroBlaze MCS?

The EDK has an I2C peripheral. I think you'll find it under
IIC instead of I2C.

--
Gabor
 
On Tue, 03 Mar 2015 14:49:06 -0500, rickman wrote:

On 3/3/2015 1:45 PM, Tim Wescott wrote:
On Sun, 01 Mar 2015 10:10:45 -0600, didaSofi wrote:

hello I need your help please. I want to connect a
gyrocompas(HMC5883L)
with a microblaze which is done by I2c and as microblaze does not have
the bus I2c. I must add it as a peripheral to the microblaze but I do
not know how in EDK regards

You either need to find some I2C intellectual property that you can
build into your project, or you need to make an I2C controller.

AFAIK, I2C is a fairly straightforward interface as long as you have
pins that can be set to open-drain or tri-stated. I haven't had to do
it myself, but I've been on projects where we've had to bit-bang it
from a microcontroller, which was accomplished with minimal screaming.

I2C is not terribly difficult, but the fact that you need to clock from
the actual clock line makes it a little more so. At least that is my
recollection from looking at the spec. If your system clock is fast
enough then you should be able to sample it all in your clock domain. I
guess I'm surprised you could do that reliably with bit banging. Perhaps
I am thinking of some different protocol... it's been too long, lol.
But I do recall there is a way to hang the bus. I think the Intel
version of I2C gets around that with a timeout.
Click to expand...

IIRC it wasn't too bad if you were the bus master -- having a slow master
just made for a slow bus.

But, I wasn't the guy cursing the Phillips Semiconductor part and its
weirdly unusable interface, then figuring out that it could all be done
from I/O pins.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com
 
On 3/3/15 2:49 PM, rickman wrote:
On 3/3/2015 1:45 PM, Tim Wescott wrote:
On Sun, 01 Mar 2015 10:10:45 -0600, didaSofi wrote:

hello I need your help please. I want to connect a gyrocompas(HMC5883L)
with a microblaze which is done by I2c and as microblaze does not have
the bus I2c. I must add it as a peripheral to the microblaze but I do
not know how in EDK regards

You either need to find some I2C intellectual property that you can build
into your project, or you need to make an I2C controller.

AFAIK, I2C is a fairly straightforward interface as long as you have pins
that can be set to open-drain or tri-stated. I haven't had to do it
myself, but I've been on projects where we've had to bit-bang it from a
microcontroller, which was accomplished with minimal screaming.

I2C is not terribly difficult, but the fact that you need to clock from
the actual clock line makes it a little more so. At least that is my
recollection from looking at the spec. If your system clock is fast
enough then you should be able to sample it all in your clock domain. I
guess I'm surprised you could do that reliably with bit banging. Perhaps
I am thinking of some different protocol... it's been too long, lol.
But I do recall there is a way to hang the bus. I think the Intel
version of I2C gets around that with a timeout.
Click to expand...

There is no requirement to clock the data in on the rising edge of the
clock, there is a moderate amount of required setup time, and normally
a lot of hold time (since data changes with the clock high is how you
signal start and stop conditions). It is set up so that a simple slave
could do most operations on the rising edge of the clock (you can't
process start/stop conditions this way), but to be fully conforming you
need some filtering as you need to ignore narrow glitches on the signals.

You can build a compatible system that is totally synchronous to a fast
enough clock. You can probably be reasonably conforming to base speed
(100KHz) sampling at only a few MHz (you may have some issue with a
hostile master generating marginal, but valid, timing, but you could
talk to most devices).

Processors can bit bang as master (since the master can chose be be as
slow as it wants), but being a slave can be a bit harder without some
hardware support. There is a protocol in I2C designed to allow a master
to alert a slave (that might be a processor) that it is getting ready to
talk, to let the slave devote its attention to the bus.

Standard I2C has now time limit built into the cycle, so a device that
holds the clock low can hang the bus. There are variations (like SMB)
where devices are supposed to have an upper limit on how long they can
do this, so as long as they follow the protocol the bus can't be hung
(but a broken device can still hang the bus).

One suggestion is to look at opencores as it has a number of I2C cores,
provided you can live with on open source license.
 
On 3/3/2015 10:07 PM, Richard Damon wrote:
On 3/3/15 2:49 PM, rickman wrote:
On 3/3/2015 1:45 PM, Tim Wescott wrote:
On Sun, 01 Mar 2015 10:10:45 -0600, didaSofi wrote:

hello I need your help please. I want to connect a gyrocompas(HMC5883L)
with a microblaze which is done by I2c and as microblaze does not have
the bus I2c. I must add it as a peripheral to the microblaze but I do
not know how in EDK regards

You either need to find some I2C intellectual property that you can
build
into your project, or you need to make an I2C controller.

AFAIK, I2C is a fairly straightforward interface as long as you have
pins
that can be set to open-drain or tri-stated. I haven't had to do it
myself, but I've been on projects where we've had to bit-bang it from a
microcontroller, which was accomplished with minimal screaming.

I2C is not terribly difficult, but the fact that you need to clock from
the actual clock line makes it a little more so. At least that is my
recollection from looking at the spec. If your system clock is fast
enough then you should be able to sample it all in your clock domain. I
guess I'm surprised you could do that reliably with bit banging. Perhaps
I am thinking of some different protocol... it's been too long, lol.
But I do recall there is a way to hang the bus. I think the Intel
version of I2C gets around that with a timeout.


There is no requirement to clock the data in on the rising edge of the
clock, there is a moderate amount of required setup time, and normally
a lot of hold time (since data changes with the clock high is how you
signal start and stop conditions). It is set up so that a simple slave
could do most operations on the rising edge of the clock (you can't
process start/stop conditions this way), but to be fully conforming you
need some filtering as you need to ignore narrow glitches on the signals.

You can build a compatible system that is totally synchronous to a fast
enough clock. You can probably be reasonably conforming to base speed
(100KHz) sampling at only a few MHz (you may have some issue with a
hostile master generating marginal, but valid, timing, but you could
talk to most devices).

Processors can bit bang as master (since the master can chose be be as
slow as it wants), but being a slave can be a bit harder without some
hardware support. There is a protocol in I2C designed to allow a master
to alert a slave (that might be a processor) that it is getting ready to
talk, to let the slave devote its attention to the bus.

Standard I2C has now time limit built into the cycle, so a device that
holds the clock low can hang the bus. There are variations (like SMB)
where devices are supposed to have an upper limit on how long they can
do this, so as long as they follow the protocol the bus can't be hung
(but a broken device can still hang the bus).

One suggestion is to look at opencores as it has a number of I2C cores,
provided you can live with on open source license.
Click to expand...

Looking at others' implementations of unknown quality is not a good
substitute for reading and understanding the spec.

--

Rick
 
rickman <gnuarm@gmail.com> wrote:
On 3/3/2015 10:07 PM, Richard Damon wrote:
One suggestion is to look at opencores as it has a number of I2C cores,
provided you can live with on open source license.

Looking at others' implementations of unknown quality is not a good
substitute for reading and understanding the spec.
Click to expand...

While I don't disagree, we've used the Opencores code successfully. Though
you'd have to know enough about the protocol to decide if it suits your use
case. The main motivation for us was having something that was reasonably
well tested, as opposed to something we made ourselves where we'd have to do
the testing.

Theo
 
On 3/5/2015 11:32 AM, Theo Markettos wrote:
rickman <gnuarm@gmail.com> wrote:
On 3/3/2015 10:07 PM, Richard Damon wrote:
One suggestion is to look at opencores as it has a number of I2C cores,
provided you can live with on open source license.

Looking at others' implementations of unknown quality is not a good
substitute for reading and understanding the spec.

While I don't disagree, we've used the Opencores code successfully. Though
you'd have to know enough about the protocol to decide if it suits your use
case. The main motivation for us was having something that was reasonably
well tested, as opposed to something we made ourselves where we'd have to do
the testing.
Click to expand...

I understand what you are saying, but how well was the core tested when
you got it? I never use code without a thorough verification no matter
what the source. In the case of open software I would expect it to come
with a test bench with a description of what is being tested and what is
not... just as I would write if it were my code. Otherwise I still have
to do that and that means I might as well write my own core for the most
part. In your case I suppose the fact that most errors were already
discovered makes the testing run quicker once you have your test bench,
not as many bugs to repair.

I'm not saying not to use others' code, I'm just saying it still needs
to be thoroughly vetted.

--

Rick
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top