Communicating with another Arduino over i2c

[Captain Starfish]

*like*

[teoman]

Let us pick your brain and describe what we have achieved so far. Well mostly mlapaglia did the hard work of compiling and uploading while I helped a bit with the code.

We can now read the M codes (can also read G codes but there are a lot of those and we thought that pestering the poor rambo with every Gcode would not be wise). And the M code data can be passed over to the Auxiliary Arduino. Although the Arduino can now see all of the M codes, we thought that it would be best if we crated our own M codes. The M7XX series
seems to be empty. So we shall be inserting the special features we want it to there. Such as M701 S1 -> switches on cabin heating M701 S0 switches it off etc etc...

mlapaglia wants to do something very cool by displaying the temperature and layer height via LED's. What would be the best place to hack in to that? CUrrently we can only read when the Gcode initiates a bed heat up etc.. but we need to find a place that gets the temp data but not too fast like 1 or 0.5 Hz. For this i was thinking the LCD display routine but it will need further pondering.

[mlapaglia]

Here's a quick vid, sorry for calling it i two c lol.

[youtube]http://www.youtube.com/watch?v=9R7oJB_O8sQ[/youtube]

Here's the i2c pinout on the RAMBO:

Blue = GND
Yellow = SCL
White = SDA

[img]http://i.imgur.com/uxRKgyH.jpg[/img]

[teoman]

Nicely done wires.

[Eric]

Congrats on getting things to work, guys!

^^ this

Where you see "unsigned char" assume "byte".

You can treat anything as a series of bytes.

For example, your float (call it fMyValue) could be sent:

Code: Select all

// in the global space, not in a function, put this:
typedef unsigned char byte;  // now we can call things byte or unsigned char interchangeably.

// in your function, at sending time, put this:
byte *tempArray = (byte *)(&fMyValue);  // creates a byte pointer that points at your variable
for (int i=0; i<sizeof(float); ++i) {
    i2cWrite(*(tempArray+i));
}

Do the same on the receiving side to spoon the incoming bytes into the variables.

What you're actually doing here is using the hardware's internal float format as a communications protocol to an external device. Which makes me cringe as a professional, as it only works if there's a compatible arduino with the same internal format on the other end. Communcations protocols should be well defined and not make low-level hardware assumptions about what they're talking to.

[mlapaglia]

Nicely done wires.

I sleeved a computer back in 2011 and I've ended up sleeving everything since then, much more pleasant!
http://i.imgur.com/Z2kH7.jpg
http://i.imgur.com/bgeQ5.jpg
http://i.imgur.com/AwblO.jpg

Congrats on getting things to work, guys!

^^ this

Where you see "unsigned char" assume "byte".

You can treat anything as a series of bytes.

For example, your float (call it fMyValue) could be sent:

Code: Select all

// in the global space, not in a function, put this:
typedef unsigned char byte;  // now we can call things byte or unsigned char interchangeably.

// in your function, at sending time, put this:
byte *tempArray = (byte *)(&fMyValue);  // creates a byte pointer that points at your variable
for (int i=0; i<sizeof(float); ++i) {
    i2cWrite(*(tempArray+i));
}

Do the same on the receiving side to spoon the incoming bytes into the variables.

What you're actually doing here is using the hardware's internal float format as a communications protocol to an external device. Which makes me cringe as a professional, as it only works if there's a compatible arduino with the same internal format on the other end. Communcations protocols should be well defined and not make low-level hardware assumptions about what they're talking to.

How do we abstract the float, move it to an external library that both ends share?

[teoman]

It is more or less what you are doing with serialize on any modern programming language.

Plus the processors and compilers are identical. It is not the most elegant solution obviously. But it is the one with the least overhead.

[Eric]

Nicely done wires.

How do we abstract the float, move it to an external library that both ends share?

One approach is interchange standards (http://en.wikipedia.org/wiki/IEEE_floating_point). But that's overkill here.

Another simple approach is converting the float to a string (and back again), which is pretty portable but increases message size.

Often the best approach for a simple project like this is to sidestep the problem at the design stage by encoding your information as integer values.

For instance, if you wanted to send a temperature value, you can define your protocol to be an integer representing 1000th's of a degree:

float fTempFloat = 123.12345;
long iTempLong = (long) (fTempLong * 1000); // value will be 123123
//*transmit iTempLong, 4 byte integer*

//*receive iTempLong, 4 byte integer*
float fTempFloat = iTempLong/1000; // if you actually need it to be a float value again.

If you only needed 10ths of a degree, you could use a short instead of a long integer.

[Captain Starfish]

Congrats on getting things to work, guys!
What you're actually doing here is using the hardware's internal float format as a communications protocol to an external device. Which makes me cringe as a professional, as it only works if there's a compatible arduino with the same internal format on the other end. Communcations protocols should be well defined and not make low-level hardware assumptions about what they're talking to.

Thank you. I know exactly what I'm doing there. Minor point: it ain't a dependency on the processor internals as the AtMEGA micros (to my knowledge) don't have any floating point support. This is all in compiler land. Your point still stands, of course, in an ideal world we'd stack protocols on top of protocols until nothing got done but it got not done cleanly. If there was any chance of this protocol having to work between little and big-endian architectures or between an Arduino and a 64 bit processor then sure, the raw pointer scrape won't work. But we've already established the architecture on both ends is the same.

Eric, remember, you yourself made the same assumption (Arduino to Arduino) a few posts earlier with the "10k should be fine" comment.

As another software engineering professional (is this where we start swinging e-wangs? ), if I was doing this on a larger capacity hardware platform I would be adding a serialisation library with common headers but separate implementations for different architectures to take care of endian, layout and size issues. But it's an Arduino, space is at a premium, the application scope is limited and the assumption that both ends are the same is valid: so there's nothing to cringe about with this approach in this application.

Moving on.

Temp readings - these are initiated as a host request M105 once a second already. Tempting though it is to have the M105 handler emit all the info when it gets polled, it means munting the logic, going off-protocol with the mcodes and saves you nothing if you're running standalone. To me, then, the clean answer would be to keep it as a poll/response so that your display arduino would send the M105 and an M114 back to the RAMBo once a second to get the info you need. Of course this clutters things up a little so you could modify the appropriate handler for a new M7** code that gave you the info you need in one call.

[Eric]

Obviously I've offended you, which wasn't my intention. I did acknowledge it would work in this case. Doesn't change my opinion, and you don't have to embrace it. Yes, I'm aware of endian and other portability issues between platforms.

Let's not even try to suggest hardware and software engineering are the same thing. 10KΩ is a fine starting value for simple cases. The minimum value is based on output pins current-sinking ability and the maximum value is based on operating frequency and collective capacitance of the devices on the i2c bus. Find an i2c spec document, I guarantee there will be an entire chapter on the subject of pullup resistors if you want to do the math.

Anyway, enough hijacking. Back to being happy that they got it to work. The "hello world" moment is always fun. Everything after that is gravy.

[teoman]

No offence on my part.

I believe it was a very respectful technical discussion where the hobby level of implementation was criticized from a professional perspective. The reasons why it would only work in this precise example were brought to light and I believe people who read the discussion were educated.

No name calling slandering or ridiculing was involved like in some other forums i used to visit and i thank all parties involved behaved nicely.

So moral of the story is. This will work but it is not the proper way of doing things. If you try this with an arduino due, raspberry pi, beaglebone, linuxcnc etc there are no guarantees that it will work properly. Should one have the need to implement this with another platform please re-read what Eric and Capt. Starfish wrote.

[Captain Starfish]

Nah no offence, just playing, is all good Eric

Nice summary, teoman.