Jump to content

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 writing it all at once and wondering where in the chain something went wrong.)
  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 SerialTestText() { Serial.println("Back channel active."); char* selfTest = (char*) ("Performing Self Test."); while (*selfTest) Serial.print(*selfTest++); Serial.println(selfTest); } void setup() { // put your setup code here, to run once: // initClocks(25000000l); Serial.begin(115200); delay(10); //Turn on LED pinMode(RED_LED, OUTPUT); digitalWrite(RED_LED, true); Serial.println(' ');//Sacrificial character. (First character is often garbled.) SerialTestText(); } int _previous = 0; void loop() { // put your main code here, to run repeatedly: int _now = millis()/2000; digitalWrite(RED_LED, (int)(millis()/500) & 0x1); if (_previous != _now) SerialTestText(); _previous = _now; } void initClocks(uint32_t mclkFreq) { #ifdef __MSP430F5529__ //Enable XT2 P5SEL |= BIT3 + BIT2; UCSCTL6 &= ~XT2OFF; delay(100); //Give time for XT2 to settle // Assign the XT1 as the FLL reference clock UCSCTL3 &= ~0x7; UCSCTL3 |= 0x2;//FLL reference clock divider of 1 // Assign the XT2 as the MCLK reference clock UCSCTL4 &= ~0x7;//MCLK source bits UCSCTL4 |= 0x5;//Source = XT2 when available otherwise DCOCLKDIV UCSCTL5 &= ~0x7;//Clock divider of 1 (25Mhz) // Assign the XT2 as the SMCLK reference clock UCSCTL4 &= ~0x70; UCSCTL4 |= 0x50;//SMCLK UCSCTL5 &= ~0x70; UCSCTL5 |= 0x10; //Clock divider of 4 (6.25Mhz) // Assign the XT1 as the source for ACLK UCSCTL4 &= ~0x700; UCSCTL4 |= 0x100;//ACLK UCSCTL5 &= ~0x700; UCSCTL5 |= 0x100; //Clock divider of 16 (~4khz) #endif } How do I use HardwareSerial with a custom value of SMCLK?
  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 (running at 3.3v, with a shared ground and ), the launchpads start having problems communicating over USB. Loading and debugging fail quite often with "No USB FET found" in CCS. (The still show up properly in Device Manager.) Sometimes they'll work OK, but I haven't discovered the rhyme or reason why they work or fail on any particular attempt to upload code to them. From that point, I'll get a failed test, and I'll have no idea if the wiring was bad, or if the launchpad didn't like the 3.3V rail, or if the device didn't like the 3.3V rail, or (if powering things with the launchpad) if the launchpad couldn't supply enough to make it work properly. Any suggestions?
  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. However, a new "Energia Sketch" does not have this problem. What is the difference between an "Energia Sketch" and a regular project? If the end-functionality is identical, I can just switch project types, but I don't know if a sketch project has any "gotcha"s that I will regret later. In case anything else is useful, here is the full console output of a failed compile: **** Build of configuration Debug for project MyDevicesGCC **** "C:\\TI\\ccsv6\\utils\\bin\\gmake" -k all 'Building file: ../main.cpp' 'Invoking: GNU Compiler' "C:/.../energia-0101E0014/hardware/tools/msp430/bin/msp430-gcc.exe" -c -mcpu=430x -mmcu=msp430f5529 -D__MSP430_HAS_USCI_A0__ -D__MSP430_HAS_USCI_B0__ -D__MSP430_HAS_USCI_B1__ -D__MSP430_HAS_USCI_A1__ -I"C:/.../energia-0101E0014/hardware/tools/msp430/msp430/include" -I"C:/.../energia-0101E0014/hardware/msp430/libraries/Wire" -I"C:/.../energia-0101E0014/hardware/tools/msp430/msp430/include" -I"C:/.../ElectronicsProjects/FlightControlsGCC/MyDevicesGCC/HeadersGCC" -I"C:/.../energia-0101E0014/hardware/msp430/variants/launchpad_f5529" -I"C:/.../energia-0101E0014/hardware/msp430/cores/msp430" -I"C:/TI/ccsv6/ccs_base/msp430/include_gcc" -Os -g -gdwarf-3 -gstrict-dwarf -Wall -MMD -MP -MF"main.d" -MT"main.d" -o"main.o" "../main.cpp" In file included from C:/TI/ccsv6/ccs_base/msp430/include_gcc/msp430f5529.h:63:0, from C:/TI/ccsv6/ccs_base/msp430/include_gcc/msp430.h:760, from C:/.../energia-0101E0014/hardware/msp430/cores/msp430/Energia.h:4, from ../main.cpp:1: C:/TI/ccsv6/ccs_base/msp430/include_gcc/iomacros.h:70:0: warning: "__interrupt" redefined [enabled by default] <built-in>:0:0: note: this is the location of the previous definition In file included from C:/TI/ccsv6/ccs_base/msp430/include_gcc/msp430.h:760:0, from C:/.../energia-0101E0014/hardware/msp430/cores/msp430/Energia.h:4, from ../main.cpp:1: C:/TI/ccsv6/ccs_base/msp430/include_gcc/msp430f5529.h:4806:0: warning: "__MSP430_HAS_USCI_A0__" redefined [enabled by default] <command-line>:0:0: note: this is the location of the previous definition C:/TI/ccsv6/ccs_base/msp430/include_gcc/msp430f5529.h:4851:0: warning: "__MSP430_HAS_USCI_B0__" redefined [enabled by default] <command-line>:0:0: note: this is the location of the previous definition C:/TI/ccsv6/ccs_base/msp430/include_gcc/msp430f5529.h:5123:0: warning: "__MSP430_HAS_USCI_A1__" redefined [enabled by default] <command-line>:0:0: note: this is the location of the previous definition C:/TI/ccsv6/ccs_base/msp430/include_gcc/msp430f5529.h:5168:0: warning: "__MSP430_HAS_USCI_B1__" redefined [enabled by default] <command-line>:0:0: note: this is the location of the previous definition ../main.cpp: In function 'int main()': ../main.cpp:37:20: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings] ../main.cpp:49:13: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings] ../main.cpp:85:16: warning: unused variable 'repeats' [-Wunused-variable] 'Finished building: ../main.cpp' ' ' 'Building target: MyDevicesGCC.out' 'Invoking: GNU Linker' "C:/.../energia-0101E0014/hardware/tools/msp430/bin/msp430-gcc.exe" -mcpu=430x -mmcu=msp430f5529 -D__MSP430_HAS_USCI_A0__ -D__MSP430_HAS_USCI_B0__ -D__MSP430_HAS_USCI_B1__ -D__MSP430_HAS_USCI_A1__ -Os -g -gdwarf-3 -gstrict-dwarf -Wall -Wl,-Map,"MyDevicesGCC.map" -o"MyDevicesGCC.out" "./main.o" -T"../msp430f5529.ld" -Wl,--start-group -l"c" -l"gcc" -Wl,--end-group c:/.../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' collect2: ld returned 1 exit status gmake: *** [MyDevicesGCC.out] Error 1 gmake: Target `all' not remade because of errors. **** Build Finished ****
  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 maddening that TI can't support their own stuff with decent examples using their own compiler. And their "DriverLib" for F5529 is so bad it is laughable when it comes to I2C. If we focused on, say, the HMC5883L, would you be game for either posting some demo code, or looking at my (failed) example code? If I could see with my own eyes that I2C will work under Energia/gcc, I would be willing to go back to spending time porting the code base to Energia/gcc. However, I can't justify more I2C effort when I can't get a reliable basic demo working (or even be able to solidly identify where the process it is going wrong. If it is easier for me to post code, I can do that when I get home this evening.
  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 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.
  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 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.
  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" I need to have working to get back on track. 1) Master send 1 or more bytes to a slave 2) Master read 1 or more bytes from a slave with the pattern of MASTER sends START, SlaveAddr, Register to read from, (repeated) START, SlaveAddr, master reads 1 or more bytes from slave. 3) A routine to test if a functioning slave is responding on a given address. Other info: My F5523 is talking to a lot of sensors (Joysticks, head tracker, etc.) and ultimately generating signals that power the servos on an RC helicopter. Timing is important, so using LPM0 and interrupts as much as possible to play nicely with all the other interrupts going on is important. (Iow, preventing the other interrupts from happening in a timely manner would be bad) Can anyone point me in a good direction? (Code would be appreciated, but I most importantly need a strategy that somebody can confirm will actually work if I put time into it.)
×
×
  • Create New...