Jump to content
43oh

Easiest way to connect Launchpad to an Arduino?


Recommended Posts

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.

 

Link to post
Share on other sites

@@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 :D

 

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.

Link to post
Share on other sites

I did read it. His post is all over the place so I started with the subject :D

 

 

 

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.

Link to post
Share on other sites

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

Link to post
Share on other sites

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  :unsure:  

Link to post
Share on other sites

@@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.

Link to post
Share on other sites

@@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

Link to post
Share on other sites

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.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...