IIC in microblaze

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

formatting link

Reply to
didaSofi
Loading thread data ...

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 
 Click to see the full signature
Reply to
Tim Wescott

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
Reply to
rickman

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
Reply to
GaborSzakacs

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 
 Click to see the full signature
Reply to
Tim Wescott

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.

Reply to
Richard Damon

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

--

Rick
Reply to
rickman

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

Reply to
Theo Markettos

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
Reply to
rickman

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.