Jump to content
43oh

SvdSinner

Members
  • Content Count

    14
  • Joined

  • Last visited

Reputation Activity

  1. Like
    SvdSinner reacted to Rei Vilo in Easiest way to connect Launchpad to an Arduino?   
    You're welcome!
     
    Most of the times, a fresh pair of eyes spots the culprit easily! That's the very reason of the 43oh forum and community.
     
    The F5529 is powerful enough to acquire, filter and process data from the sensors.
     
    For a complete IMU solution, have a look at the MPU6050 / MPU9150 / MPU9255 sensors that combine magnetometer + accelerometer + gyroscope + processing unit. The result is the sensor calculates the Euler angles and quaternions so the main MCU has almost nothing to do. I managed to get the code available in this very forum to work easily.
  2. Like
    SvdSinner reacted to Rei Vilo in Easiest way to connect Launchpad to an Arduino?   
    Have a look at the http://reivilofischertechnik.weebly.com/smartdevices.html'>I

  3. Like
    SvdSinner reacted to Rei Vilo in Easiest way to connect Launchpad to an Arduino?   
    My HMC5843 is embedded in a weather station so I couldn't test it.
     
    However, here's a working Energia project for the HMC6352 that works fine. I've also included the library for the HMC5843.
    *** 18h HMC6352 2x Compass (sensor) 23.2 NE 25.1 NE 25.2 NE 25.3 NE 25.6 NE 25.3 NE 25.3 NE Archive.zip
     
    Energia uses plain C++. It just includes a hardware abstraction layer for all the peripherals.
     
    Have a look at the Wire.h and Wire.cpp files for the I
  4. Like
  5. Like
    SvdSinner reacted to Rei Vilo in Easiest way to connect Launchpad to an Arduino?   
    @@SvdSinner I'm trying to answer all your questions...
     
    Are you using the TI compiler?
     
    I'm using Energia with GCC.
     
     
    What value of Pull-ups are you using (I've tried 2K, 4.7K, 10K and even none)?
     
    10 k?
     
     
    Is there a way to scan the I2C bus for slaves?  IOW, is there a way to do bool IsSlavePresent(uint8_t address) implementation?  (Easily done with Arduino, and I've done it on a G2553, but I've never gotten this to work on the F5529.)
     
    As far as I remember for the MSP430, the standard scanning sketch lists all addresses, even if no corresponding slave is attached. 
     
     
    Are you using any of these devices:  Tiny RTC module, HMC5883L, MPU-6050,  I2C to parallel convert for 16x2 LCD, Arduino slave, Different model MSP430 slave?
     
    Tiny RTC module: don't know. But DS1307 doesn't work because it operates at 5V. I use the PCF2129A from NXP, 3.3V operated and built-in crystal.
    HMC5883L: yes
    MPU-6050: yes
    I2C to parallel convert for 16x2 LCD: yes with MCP23017
    Arduino slave: no
    Different model MSP430 slave: yes with TM4C LaunchPad
     
    Do you connect a logic analyzer?  If so do you change anything when you hook it up?  (IOW, does adding the logic analyzer require different pull-ups or anything similar?)
     
    Yes, Saleae 8 and 16 logic analysers.
     
    The logic analyser needs to be powered on, otherwise some interference may occur.
     
     
    How do you regulate the power on the 3.3v line?  (My launchpads get very quirky if their 3.3V line isn't precisely the same voltage as other things on the I2C bus.)
     
    I
  6. Like
    SvdSinner reacted to Rei Vilo in Easiest way to connect Launchpad to an Arduino?   
    How surprising!
     
    I'm using I
  7. Like
    SvdSinner got a reaction from zeke in Question about I2C, DriverLib and MSP-EXP430F5529LP   
    Schematic Issues:
    1)  No pull-up resistors.  Start by adding 10k pull-ups to both lines.  (Shouldn't matter which side of the level shifter you add them, but I'd try the 5v side first.)
    2)  No decoupling capacitors.  Add in caps between the 3v & 5v lines and GND.  Otherwise a spike/lull cuased by your LED matrix can cause all sorts of wierd issues.  Better safe than sorry.
    3)  You have no way to reset your slave device.  I'd recommend you use a GPIO with a transistor (high side switch) to allow your program to power-cycle the LED driver.  I haven't used that specific device, but I've seen other I2C devices get stuck holding down the SCL, and if you can't  power cycle it, it will block all I2C communications.  Remember that your slave doesn't reboot each time you restart your program.  Ideally, put the pull-up resisters after the switch, because some devices can function with the juice from the data lines long enough to not reset when you cut their Vcc line.
    4)  Consider adding points on your line to put an I2C sniffer.  (Hopefully, you have access to a logic analyser)  What you don't want is to have your lines getting wiggled every time you hook-up/remove testing tools.  
     
    Suggestions:***
    1)  Make sure everything is held securely while you get it working.  I use a chunk of cardboard and hot glue everything down to it.  You want to make sure nothing unexpected gets pulled out when things get bumped and cords get swapped.
    2)  Don't assume ANYTHING is working like you think it is.  Test your wiring connections for continuity.  Test all four lines with a VMM.  Test any pins/sockets/headers to make sure every pin has good contact. Huge amount of "problems" with I2C are just basic wiring problems.  
    3)  If you are starting from scratch, I'd recommend using the Energia code base and it's port of wire.h for I2C.  The TI I2C libraries are quite buggy (There are function in the driver library that simply don't work on an MSP430F5529 and will hang your program) and have an over-complicated programming model.  I'm currently trying to get wire.h to compile with the TI compiler, because I have some code that uses it 
    4)  Unit test every I2C call you expect to make.  Make a project that atomically does each function so you can prove the basics work before you integrate them into your code.  It is a bit of work, but much less work than trying to debug a program when you don't know which of the components are actually doing what you think they are.
    5)  Document every time things work correctly, preferably with source control.  If/when you break something as you add to the code, you want a clear place to return to if you don't like how your change turned out.
    6)  If you find a loose connector, etc.  Toss it out and use a better one.  Just because you can wiggle it and get it to work again for the moment, doesn't mean you won't spend more time & effort testing and wiggling it than it is worth.  (This advice might be more for me than you.  Can't tell you how many times I've been dumb enough to throw a bad connecter back into my parts bin so that I get to have the same problems again the next time I pull it out.)
     
    ***These suggestions mostly come from experiencing the pain of not using them.  Hope they help.  Troubleshooting I2C can be maddeningly complex if you don't work hard to ensure that your building blocks are solid.
     
  8. Like
    SvdSinner got a reaction from ElectricCowboy in Question about I2C, DriverLib and MSP-EXP430F5529LP   
    Schematic Issues:
    1)  No pull-up resistors.  Start by adding 10k pull-ups to both lines.  (Shouldn't matter which side of the level shifter you add them, but I'd try the 5v side first.)
    2)  No decoupling capacitors.  Add in caps between the 3v & 5v lines and GND.  Otherwise a spike/lull cuased by your LED matrix can cause all sorts of wierd issues.  Better safe than sorry.
    3)  You have no way to reset your slave device.  I'd recommend you use a GPIO with a transistor (high side switch) to allow your program to power-cycle the LED driver.  I haven't used that specific device, but I've seen other I2C devices get stuck holding down the SCL, and if you can't  power cycle it, it will block all I2C communications.  Remember that your slave doesn't reboot each time you restart your program.  Ideally, put the pull-up resisters after the switch, because some devices can function with the juice from the data lines long enough to not reset when you cut their Vcc line.
    4)  Consider adding points on your line to put an I2C sniffer.  (Hopefully, you have access to a logic analyser)  What you don't want is to have your lines getting wiggled every time you hook-up/remove testing tools.  
     
    Suggestions:***
    1)  Make sure everything is held securely while you get it working.  I use a chunk of cardboard and hot glue everything down to it.  You want to make sure nothing unexpected gets pulled out when things get bumped and cords get swapped.
    2)  Don't assume ANYTHING is working like you think it is.  Test your wiring connections for continuity.  Test all four lines with a VMM.  Test any pins/sockets/headers to make sure every pin has good contact. Huge amount of "problems" with I2C are just basic wiring problems.  
    3)  If you are starting from scratch, I'd recommend using the Energia code base and it's port of wire.h for I2C.  The TI I2C libraries are quite buggy (There are function in the driver library that simply don't work on an MSP430F5529 and will hang your program) and have an over-complicated programming model.  I'm currently trying to get wire.h to compile with the TI compiler, because I have some code that uses it 
    4)  Unit test every I2C call you expect to make.  Make a project that atomically does each function so you can prove the basics work before you integrate them into your code.  It is a bit of work, but much less work than trying to debug a program when you don't know which of the components are actually doing what you think they are.
    5)  Document every time things work correctly, preferably with source control.  If/when you break something as you add to the code, you want a clear place to return to if you don't like how your change turned out.
    6)  If you find a loose connector, etc.  Toss it out and use a better one.  Just because you can wiggle it and get it to work again for the moment, doesn't mean you won't spend more time & effort testing and wiggling it than it is worth.  (This advice might be more for me than you.  Can't tell you how many times I've been dumb enough to throw a bad connecter back into my parts bin so that I get to have the same problems again the next time I pull it out.)
     
    ***These suggestions mostly come from experiencing the pain of not using them.  Hope they help.  Troubleshooting I2C can be maddeningly complex if you don't work hard to ensure that your building blocks are solid.
     
  9. Like
    SvdSinner got a reaction from solipso in Question about I2C, DriverLib and MSP-EXP430F5529LP   
    Schematic Issues:
    1)  No pull-up resistors.  Start by adding 10k pull-ups to both lines.  (Shouldn't matter which side of the level shifter you add them, but I'd try the 5v side first.)
    2)  No decoupling capacitors.  Add in caps between the 3v & 5v lines and GND.  Otherwise a spike/lull cuased by your LED matrix can cause all sorts of wierd issues.  Better safe than sorry.
    3)  You have no way to reset your slave device.  I'd recommend you use a GPIO with a transistor (high side switch) to allow your program to power-cycle the LED driver.  I haven't used that specific device, but I've seen other I2C devices get stuck holding down the SCL, and if you can't  power cycle it, it will block all I2C communications.  Remember that your slave doesn't reboot each time you restart your program.  Ideally, put the pull-up resisters after the switch, because some devices can function with the juice from the data lines long enough to not reset when you cut their Vcc line.
    4)  Consider adding points on your line to put an I2C sniffer.  (Hopefully, you have access to a logic analyser)  What you don't want is to have your lines getting wiggled every time you hook-up/remove testing tools.  
     
    Suggestions:***
    1)  Make sure everything is held securely while you get it working.  I use a chunk of cardboard and hot glue everything down to it.  You want to make sure nothing unexpected gets pulled out when things get bumped and cords get swapped.
    2)  Don't assume ANYTHING is working like you think it is.  Test your wiring connections for continuity.  Test all four lines with a VMM.  Test any pins/sockets/headers to make sure every pin has good contact. Huge amount of "problems" with I2C are just basic wiring problems.  
    3)  If you are starting from scratch, I'd recommend using the Energia code base and it's port of wire.h for I2C.  The TI I2C libraries are quite buggy (There are function in the driver library that simply don't work on an MSP430F5529 and will hang your program) and have an over-complicated programming model.  I'm currently trying to get wire.h to compile with the TI compiler, because I have some code that uses it 
    4)  Unit test every I2C call you expect to make.  Make a project that atomically does each function so you can prove the basics work before you integrate them into your code.  It is a bit of work, but much less work than trying to debug a program when you don't know which of the components are actually doing what you think they are.
    5)  Document every time things work correctly, preferably with source control.  If/when you break something as you add to the code, you want a clear place to return to if you don't like how your change turned out.
    6)  If you find a loose connector, etc.  Toss it out and use a better one.  Just because you can wiggle it and get it to work again for the moment, doesn't mean you won't spend more time & effort testing and wiggling it than it is worth.  (This advice might be more for me than you.  Can't tell you how many times I've been dumb enough to throw a bad connecter back into my parts bin so that I get to have the same problems again the next time I pull it out.)
     
    ***These suggestions mostly come from experiencing the pain of not using them.  Hope they help.  Troubleshooting I2C can be maddeningly complex if you don't work hard to ensure that your building blocks are solid.
     
  10. Like
    SvdSinner reacted to pabigot in I2C basic functions on f5529   
    You can take a look at how BSP430 does it to see if that's helpful, though you'd have to refactor the I/O to do single bytes in interrupts rather than polled I/O, if you're doing enough I2C activity to be worth it.
×
×
  • Create New...