SvdSinner 3 Posted April 6, 2015 Share Posted April 6, 2015 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. Quote Link to post Share on other sites
oPossum 1,083 Posted April 6, 2015 Share Posted April 6, 2015 Give software IIC a try. The hardware IIC on MSP430 is poorly designed and hard to use. It is the only peripheral on MSP430 that I never use. I avoid it. http://forum.43oh.com/topic/2358-software-iic-master-in-c-c-class-and-c-template/ Quote Link to post Share on other sites
SvdSinner 3 Posted April 6, 2015 Author Share Posted April 6, 2015 Is that software implementation based on timers & interrupts or polling? Since I have to resend readings every 2ms, anything based on polling is too risky. (And sending bad data to an aircraft is bad, M'Kay?) Quote Link to post Share on other sites
oPossum 1,083 Posted April 6, 2015 Share Posted April 6, 2015 It does not use timers or interrupts. All functions return immediately - there is no polling. Clock stretching is *not* supported. Quote Link to post Share on other sites
spirilis 1,265 Posted April 6, 2015 Share Posted April 6, 2015 Short answer to your original post's subject: Use a 3.3V arduino. Hook SCL on arduino to SCL on MSP430, SDA on arduino to SDA on MSP430, hook the GND's together, and have a ~1-4K ohm pullup resistor between SCL-Vcc and SDA-Vcc. Quote Link to post Share on other sites
dubnet 238 Posted April 6, 2015 Share Posted April 6, 2015 @@spirilis You may want to take another look at the original post.... Quote Link to post Share on other sites
spirilis 1,265 Posted April 6, 2015 Share Posted April 6, 2015 @@spirilis You may want to take another look at the original post.... I did read it. His post is all over the place so I started with the subject Fwiw- I just spent a lot of time writing my own USCI I2C driver for a new arduino 1.6-based MSP430 core and have a lot of the quirks fresh in my head. Although I haven't yet had the time to fully vet the slave support. Using a Saleae Logic16 (logic analyzer supporting up to 100MHz samplerate) which has been utterly indispensible for debugging I2C. Quote Link to post Share on other sites
dubnet 238 Posted April 6, 2015 Share Posted April 6, 2015 I did read it. His post is all over the place so I started with the subject LOL... I am so glad I purchased a Saleae. Money well spent. Mine came in very handy when trying to make a 2553 talk via I2C to a touch keypad controller. You would think that by now I2C would be plug and play. Quote Link to post Share on other sites
spirilis 1,265 Posted April 6, 2015 Share Posted April 6, 2015 LOL... I am so glad I purchased a Saleae. Money well spent. Mine came in very handy when trying to make a 2553 talk via I2C to a touch keypad controller. You would think that by now I2C would be plug and play. You know, one could probably make a coin or 2 building an I2C offload comms engine using MSP430 or similar. Sell on tindie for profit! Lol Sent from my Note 10.1 tablet using Tapatalk Quote Link to post Share on other sites
SvdSinner 3 Posted April 6, 2015 Author Share Posted April 6, 2015 Short answer to your original post's subject: Use a 3.3V arduino. Hook SCL on arduino to SCL on MSP430, SDA on arduino to SDA on MSP430, hook the GND's together, and have a ~1-4K ohm pullup resistor between SCL-Vcc and SDA-Vcc. Sadly, none of my Arduinos (Mega, Leonardo, Uno, Pro Mini) are 3.3v. That, and my entire post was about AVOIDING using the LaunchPad's I2C Quote Link to post Share on other sites
dubnet 238 Posted April 7, 2015 Share Posted April 7, 2015 @@oPossum Do you know if TI fixed their weak MSP430 I2C in the Tiva series MPUs? @@SvdSinner Sorry for my contribution in terms of defocusing your thread. IF per chance I2C is better implemented in the Tiva series then perhaps a MSP432 would be a possibility since it uses some of the MSP430 peripherals and a M4 core to achieve performance and low power. Quote Link to post Share on other sites
spirilis 1,265 Posted April 7, 2015 Share Posted April 7, 2015 @@oPossum Do you know if TI fixed their weak MSP430 I2C in the Tiva series MPUs? @@SvdSinner Sorry for my contribution in terms of defocusing your thread. IF per chance I2C is better implemented in the Tiva series then perhaps a MSP432 would be a possibility since it uses some of the MSP430 peripherals and a M4 core to achieve performance and low power. MSP432 uses eUSCI for I2C, just like the FRAM MSP430's so it's no different in that regard. It didn't borrow much from Tiva beyond using the same CPU core (and configured slightly different too). Sent from my Note 10.1 tablet using Tapatalk Quote Link to post Share on other sites
dubnet 238 Posted April 7, 2015 Share Posted April 7, 2015 MSP432 uses eUSCI for I2C, just like the FRAM MSP430's so it's no different in that regard. It didn't borrow much from Tiva beyond using the same CPU core (and configured slightly different too). Wasn't sure if they took all the peripherals (good and bad) from the 430. Good to know. Quote Link to post Share on other sites
Rei Vilo 695 Posted April 7, 2015 Share Posted April 7, 2015 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. How surprising! I'm using I SvdSinner 1 Quote Link to post Share on other sites
SvdSinner 3 Posted April 8, 2015 Author Share Posted April 8, 2015 How surprising! I'm using I Quote Link to post Share on other sites
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.