Jump to content
43oh

SvdSinner

Members
  • Content Count

    14
  • Joined

  • Last visited

About SvdSinner

  • Rank
    Member

Contact Methods

  • Website URL
    http://www.solidrockstable.com

Profile Information

  • Location
    Ames, IA
  1. Servos need their PWM not only to have a given duty cycle, but they also need a specified frequency (typically 50hz or 100hz). This fairly easy to do via the Timer system, and is much easier to debug without the abstractions of the AnalogWrite libraries. (IOW, coding against the registers is easier here) Just make sure you test each step of the timing with your scope. Make sure your source clock is the frequency you think it is, then make sure the CCR has the right frequency, and then confirm your duty cycle. (Sounds like a lot of work, but is much faster one step at a time rather than w
  2. I've got an F5229LP app that sets SMCLK to XT2 with a divider of 4. (XT2 = 25Mhz crystal, which is also the source for MCLK) When I initialize the clocks, HardwareSerial no longer produces an accurate Baud Rate, and it breaks terminal communication. I see that HardwareSerial.cpp contains: #define SMCLK F_CPU //SMCLK = F_CPU for now I've tried changing it to F_CPU / 4 but the situation did not improve. Here is my recreation code: (Uncomment initClocks(25000000l); and change HardwareSerial.cpp to see it fail) #include <WString.h> void initClocks(uint32_t mclkFreq); void SerialT
  3. I've gotten started on the re-write, but have fallen right back into the same issues I was having before. The current roadblock is the 3.3V line. The G2553s run theirs at nearly 3.6V, two of my F5529s run theirs at 3.08v, and the last F5529 and the Tiva run at about 3.23V. Alone, that isn't a problem, but it wrecks many debugging scenarios and makes launchpad to disparate launchpad I2C nearly impossible. The challenge is that I am running enough things in my project that none of the launchpads can supply the 3.3V line from their EX-FET voltage regulators. If I use external regulated 3.3V
  4. I'm port some code over to GCC (GNU_4.6.3:MSPGCC compiler inside CCS6.1) to take advantage of existing driver code for some of my devices. After clearing all basic errors, my build fails with this error: .../energia-0101e0014/hardware/tools/msp430/bin/../lib/gcc/msp430/4.6.3/../../../../msp430/bin/ld.exe: error: no memory region specified for loadable section `.noinit.crt0' gmake: *** [main.o] Error 1 gmake: Target `all' not remade because of errors. How do I fix that? NOTE/CLUE: I tried making a new, blank GNU_4.6.3:MSPGCC project in CCS, and it gets identical compile errors. Ho
  5. And I can't say thanks enough. I've spent decades in software and hardware, and -nothing- has flummoxed me more than trying to get I2C working on my F5529. As I mentioned in my OP, the code base I need to integrate is built on the TI compiler. I've spent a day or so on trying to port the Energia Wire library to the TI compiler, and another day on trying to convert the code base to GCC. Neither day ended with functional code, and I shelved the effort. (FWIW, I've never done any porting before, so my first attempts certainly don't guarantee either of these isn't possible.) It is madd
  6. Is eUSCI significantly better/easier to use than USCI? I actually bought a Tiva Launchpad but I haven't played with its I2C. If it is better, what should I expect?
  7. 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
  8. 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?)
  9. 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
  10. 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 se
  11. That code looks awesome. I skimmed through the docs, and saw you thought it might work with the newer ti compilers. Any guess on how long it would take for me to get BSP430 to work with the Ti compiler? Or, conversely, how hard it would be to move my application to the open source compiler? (It uses Timers A&B, ADC, GPIO, and acts as a USB client) Fwiw, I'm a professional . NET developer, and have been working with the MSP430 for home projects for the last couple of years. (IOW, I'm still a bit rusty with the detailed intricacies of compilers and the C/C++ tool chain.
  12. I'm really frustrated. I need to talk to some I2C sensors with my f5529, from an existing program that uses the TI compiler and CCS6. There are lots of libraries out there that work in slightly different configurations. (Energia wire library, on a G2553, etc.) The TI driverlib included with mspware is buggy, and doesn't even do basic things like handle NACKs. At this point, I've tried so many things that aren't working, I'm lost on what direction to spend my time. (IOW, what library and code patterns should I be using with the F5529/CCS/ti compiler) There are 4 main "unit tests
×
×
  • Create New...