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.

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

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.

Theo

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.

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

-- 

Rick

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.

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.

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

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

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 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.

-- 

Rick

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.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com