Jump to content
yyrkoon

Implementing an I2C slave device.

Recommended Posts

By default, the beaglebone buses have to operate at 100khz. It's been my impression that 400Khz is standard, and 800Khz is "fast" speed. Anyway, the beaglebone buses must be 100Khz, but ours doesn't. But from what I understand, with differential I2C, you don't need to worry about all of that. High speed may not work but 400Khz is supposed to work. But, thats why we're testing. To find out what we can get away with. Reliably.

Share this post


Link to post
Share on other sites
1 hour ago, zeke said:

If it matters, I have done I2C via 1Wire over that distance and farther.

If you slow the speeds down then you should be fine.

You're talking about the 1wire protocol or just one wire of I2C as in sda / scl ?

Share this post


Link to post
Share on other sites

I'm talking about both, actually.

The DS28EA00 has two GPIO lines.

Using 1Wire protocol, I turned them on and off in a way that looked like very slow I2C to the pressure transducer that was attached to those two GPIO lines.

Essentially, using the 1Wire protocol, I spoke I2C to a slave device.

Does that make sense?

Share this post


Link to post
Share on other sites
2 hours ago, zeke said:

I'm talking about both, actually.

The DS28EA00 has two GPIO lines.

Using 1Wire protocol, I turned them on and off in a way that looked like very slow I2C to the pressure transducer that was attached to those two GPIO lines.

Essentially, using the 1Wire protocol, I spoke I2C to a slave device.

Does that make sense?

Yes, and no. I know what you're saying, just not sure how that would work lol . . . But i really need to understand the low levels of both better anyway.

Share this post


Link to post
Share on other sites

It was a bit of a mind bender for me at first but then I just read the I2C spec and it did not specify that the communication *had* to be at 100kHz. 

The way I choose to understand things is that the I2C slave device has a communication state machine inside of it. All I have to do is put in one bit and turn the crank once. Then repeat. Over and over. Then the slave device will just do its job merrily. 

Share this post


Link to post
Share on other sites

Just in case I didn't make it clear, the speed of the simulated I2C-over-1Wire ends up being about 15kHz. 

It's not fast but it does work over long lengths of cable and that is pretty darn cool.

Share this post


Link to post
Share on other sites
2 hours ago, zeke said:

Just in case I didn't make it clear, the speed of the simulated I2C-over-1Wire ends up being about 15kHz. 

It's not fast but it does work over long lengths of cable and that is pretty darn cool.

I think if we're lucky, we should be able to do at least 100khz for 300M. I would be nice if we could go 400khz , or even 800Khz. I won't hold my breathe though . . .  I'm not exactly sure how Linux will handle less than 100Khz, but I know how to change the frequency. So I'll figure that out when,/ if I need to.

Eventually, we're considering open sourcing the hardware. So that'll be cool too. It'll be a cape with a few other features on it too such as an RTC, and external power management. The external power management right now is just a single GPIO that'll take a "pulse train" to enable. Eventually I want to change that to 1-wire for more flexibility. That'll be fun for me to figure out I think. When I get to it.

Share this post


Link to post
Share on other sites

My gut instincts tell me that your cable will have to be 50 ohm coaxial to get 100kHz over 300 meters. Only super slow speeds can go long distances i.e.: RS-485.

I would be inclined to use an msp430 on your cape to be the I2C interface master. You could talk to it with the BBB as if it was a slave serial device. That would isolate the BBB from the slow speed pathway. The BBB could just poll the MSP430 for any new data.

 

Share this post


Link to post
Share on other sites
20 hours ago, zeke said:

My gut instincts tell me that your cable will have to be 50 ohm coaxial to get 100kHz over 300 meters. Only super slow speeds can go long distances i.e.: RS-485.

I would be inclined to use an msp430 on your cape to be the I2C interface master. You could talk to it with the BBB as if it was a slave serial device. That would isolate the BBB from the slow speed pathway. The BBB could just poll the MSP430 for any new data.

 

You need to remember though. This isn't stock I2C, even though to the devices on each end, it looks like stock I2C. This I2C is on a 24v carrier, and runs over CANBUS hardware. Granted, the 24v is also used to power the devices, or can be.

 

Anyway, we won't know what to expect until we get a 1000 foot spool of cat5e, and cut off 100feet. I think the spool we currently have is nearly gone. So not so much to test with at this moment.

 

CANBUS is max 1Mbit/s though, and quite honestly I'm not exactly sure how mbit, and Khz correlate(compare) to one another. Something else I need to look into eventually. Anyway, got coding to do, I've pretty much been procrastinating starting on all of this, and now I have hardware in hand, with a test jig. I need to get busy writing code. It'll probably end up being something similar to how I handled the CANBUS project I was working on months ago. Two process halves, where the first half will be reading / writing registers, and writing this data to an intermediary file. Where a second half, which could be any number of interfaces, would probably start off as a simple C websocket server. For UI purposes.

Share this post


Link to post
Share on other sites

Whoops. I forgot that detail. I must be getting old.

So this is I2C over CANBUS then. Sorta. 

I have never worked with CANBUS. Can it cover that distance at that speed?

 

Share this post


Link to post
Share on other sites
11 hours ago, zeke said:

Whoops. I forgot that detail. I must be getting old.

So this is I2C over CANBUS then. Sorta. 

I have never worked with CANBUS. Can it cover that distance at that speed?

 

It's I2C over CANBUS, exactly. I've been told by my buddy that I was wrong, that the carrier is actually 5v, and that the 24vdc is for power only. Not quite sure how that works with only two "lines"( single twisted pair over cat5e ). But yeah I do not recall how long a distance CANBUS can handle, only that at the time I was told, it seemed ridiculously long when you consider how long a car is. I do know that the software protocol is 1Mbits max, which I'm not exactly sure is applicable to this situation or not.

 

EDIT:

So maybe reverse logic coms ? e.g. offset starting at 24vdc minus 5vdc when pulled low/ high or something ? heh yeah I'm lost ;)

Share this post


Link to post
Share on other sites

Even at the highest speed (1Mbps) the spec calls out 40M max bus length. Good for stretch limos or buses I suppose.  :)

Here is a snippet from a CANBUS page ( http://www.interfacebus.com/CAN-Bus-Description-Vendors-Canbus-Protocol.html ):

"A number of different data rates are defined, with 1Mbps (Bits per second) being the top end, and 10kbps the minimum rate. All modules must support 20kbps. Cable length depends on the data rate used. Normally all the devices in a system transfer uniform and fixed bit-rates. The maximum line length is 1Km, 40 meters at 1Mbps. Termination resistors are used at each end of the cable. The worst-case transmission time of an 8-byte frame with an 11-bit identifier is 134 bit times (that's 134 microseconds at the maximum baud rate of 1Mbits/sec)."

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×