Using I2C on the Make Contoller Board

Hi Bob

Did you have to make any changes to get the twiapi.c to compile? I am having issues with the two ARM include files generating hundreds if not thousands of errors, all to do with some of the statements like EQU in those files.

It turns out I did change those two files. In ioat91sam7x256.h, I moved the else from line 2744 to the line before the end of the file so the assembly EQU's fell within the #if 0.
In lib_AT91SAM7X256.h, I changed the void parameter on some function prototypes. I don't believe this change was required; I was probably experimenting with compiler warnings. Here is the diff output. Hopefully this will work for you, as I will not be able to check the forum for a few days.
Regards,
Bob

[bobf@www ARM7_AT91SAM7S]$ diff lib_AT91SAM7X256.h ~/fw131/heavy/controller/freertos/portable/GCC/ARM7_AT91SAM7S/lib_AT91SAM7X256.h
60c60
< void (*newHandler)() ) // \arg address of the interrupt handler
---
> void (*newHandler) (void) ) // \arg address of the interrupt handler
135c135
< void (*Handler) (void) ) // \arg Interrupt Handler
---
> void (*Handler) () ) // \arg Interrupt Handler


[bobf@www ARM7_AT91SAM7S]$ diff ioat91sam7x256.h ~/fw131/heavy/controller/freertos/portable/GCC/ARM7_AT91SAM7S/ioat91sam7x256.h
2744c2744
<
---
> #endif
4697c4697
< #endif
---
>

Thanks for the diffs Bob.
Moving the endif got rid of the errors and the compile/link
finished fine. I didn't bother with the void changes, they are
not necessary, but do get rid of a lot of warnings.
Nice work, much appreciated

I do not see an "attachment" on this page but could REALLY use this for my project Any tips?

It looks like Atmel has updated their software and their web site. The new software is at: http://www.atmel.com/[…]/at91sam7x-ek.zip. I haven't looked to see if they changed their twi files or not. You may need to make the changes noted in comments above to get the code to compile cleanly.

The link didn't paste correctly. It's: http://www.atmel.com/[…]/at91sam7x-ek.zip

Thanks SO much for the response Bob! I have the Atmel software but was hoping to get the wrapper class you created that makes sending messages easier. There was mention of a class called "twiapi.c". I have used classes from the Twi Eeprom sample they give with that code base. everything is in there but making the calls seems painful without a wrapper class.

I am trying to send I2C messages to some devices and do a basic I2C bus scan for starters to see what is wired up.

Again, thanks for your response!

The attachment is at: http://www.makingthings.com/[…]/view
For some reason, the attachment is no longer displayed when viewing the tutorial.

Thanks a million Bob! For my latest project I now realize I need to actually use the serial on the Make to send I2C commands wireless to a receiver module that decodes the I2C commands on a atmel168 then sends to the I2C device. I found a great tute on this and the guy is using the Wire classes. I wonder if somehow we can get the Wire class usable on the Make since it is an atmel based unit. I am going to hack around this code today. Thanks so much , again.

Oh and here is a link to this guy's code/project. I need to build basically the same receiver module. He used a very inexpensive $4 rflink chip instead of a xbee. Do you know what you gain from using xbee instead for this? It would be much cheaper to use the rflink chips.

http://jarv.org/wireless_blinkm.shtml

Best,
Ken

The rflink solution looks like a simple transceiver which doesn't provide any framing, error detection, or error correction. The BlinkM project had the CPUs do framing and checksums, but I don't know if there was any error correction. For a bidirectional link with retransmission and acknowledgements you would need two transmiters and two receivers. The xbee is a nice solution to work with, and provides great distance and reliability. I also like the fact that it has a bunch of analog and digital I/O's. I've used it for a remote control to CPU wireless connection, and CPU to CPU connections. You need newer versions of the xbee products if you want a CPU to a dumb controlled device connection.
 

     Thanks for the reply Bob. That is what I thought. I am not going to need bidirectional transmission but I may need a little more error correction than just a checksum. For a prototype I went ahead and grabbed a few from sparkfun.

     Do you think I need to add a encoder/decoder IC on each end as well? Not sure if XBee units do this internally and that is another plus?
This is an indoor project and all receivers will be well within 40 feet of the transmitter. I was looking at these in particular:

http://www.glolab.com/encdec/gl/ed4gp.html

So my transmitter would look like: Flex UI(http requests made to webservice running on Make V2 firmware) -> Encoder IC -> RF Link (on serial)
And my receiver component order would be : RF Link -> Decoder IC -> Atmeg168 IC -> Devices (I2C, A/D)

Thanks for any input. I am going to try it without encoder/decoder ICs first. It seems to be easy enough to add them to the mix as an afterthought.