After 6+ frustrating months of struggling, I am giving up on using I2C with my launch pads (G2553 & F5529). Seemingly no matter what I try, I can't get it to work reliably with any of my peripherals. I've tried half a dozen various libraries, both ti compiler (CCS) and Energia/GCC based, with no great success. (The only test cases that I could get running were with two identical launchpads with single byte communication from verbatim example code.) Sadly, due to the wide variety of compilers, libraries, devices and pull-up resistor values that I have tried, I just can't put together a correct combination of them to make any progress.
On the other hand, I have no problems what-so-ever getting I2C to work on an Arduino. Stuff just works and driver libraries are readily available for all my I2C devices.
My main issue is that I have a big base of code written for my F5529 that needs to be able to talk to my I2C sensors. (FWIW, it pulls in various custom built controls/sensors and translates them into (selectable) USB-HID joystick output or RC transmitter PPM signals. It allows my simulator cockpit to be used on either a PC Flight simulator or an FPV Helicopter.)
I am now considering having an Arduino be a middle-man and handle all the I2C devices, and have the F5529 use a different protocol (SPI?UART?) to give commands/get sensor data to/from the Arduino.
Main Question:
1) Are their "gotchas" with using either SPI or UART with a F5529? In a perfect world, they would connect to the Arduino with simple-straight through wires, with nothing but a 3.3v/5v logic level converter between them and nothing to configure beyond baud rate. Which of these protocols would be easiest to use in a real-world bread-board scenario? (I'd welcome any real-world issues that people have had with either)
2) What would be the simplest proof-of-concept unit test I could do with an F5529 and an Arduino to test communication? (I2C was terrible for this, because of how many possible problems could make even the simplest test fail. I couldn't test only 1 thing at a time. I never knew if I when I iterated after a failed test and things still didn't work, if my change was right/wrong, or if the issue was caused by multiple things in the chain.) I need one "hello world" test that I know should work that I can use to get wiring, etc. setup and verified without any concern that the test itself isn't workable.
3) From a TILibraries (since my code base uses the TI compiler in CCS, I can't use Energia or GCC.) point of view, is SPI or UART preferable? I don't want another nightmare of discovering that the TI-libraries (like their I2C libraries and examples) are shoddy and nearly worthless. Plus, I'd prefer if and hardware components do what they are told to do when told to do so. (Unlike the I2C module that does things like command queuing and doesn't send a slave address until after your code sends its first byte of data, which makes debugging with a .)
Bonus question:
4) If anybody can provide an example of "real" I2C master code(at minimum meaning sending a slave address, then a register address, then a restart, then receive data, and handle basic issues like NACKs or a non-responsive slave with a graceful fail rather than hurling. Don't suggest the TI Examples as they horribly buggy, terribly designed and not functionally complete.) working on an F5529 and the TI compiler, I'd be thrilled. However, it would need to include a schematic of how it is hooked up and sample code: I've reviewed so many posts from people who "solved" their problem, but didn't include enough information to replicate what they did, I can't bear to do another shot-in-the-dark test.
Other info: My prototyping bench has all basic tooling with two inexpensive (reliable to about 12Mhz) logic analyzers, both have I2C/SPI/UART analyzer functionality. I've got multiple launchpads to play with (multiple G2553, F5529, and Arduinos and one Tiva 123), and multiple 3.3/5V logic-level converters (both I2C compatible and UART only). And, if I need it to get this to work, I don't mind buying something.