Jump to content
43oh

AaronInSpace

Members
  • Content Count

    43
  • Joined

  • Last visited

  • Days Won

    1

Reputation Activity

  1. Like
    AaronInSpace reacted to oPossum in SMCLK faulty on F2619?   
    I think that should be XIN (pin 8).
     
    I can't find any specific statement in the MSP430 spec sheets that says that, but it is typical for connection of an oscillator module to a microcontroller.
  2. Like
    AaronInSpace reacted to zeke in MCLK stuck high   
    Usually, replacing the msp430 is the quickest way of determining if there's a hardware issue.
     
    If you want to do a complete root cause analysis then you have to start fresh with code that you know will work.
     
    In this case, you want to exercise the DCO to make certain that it is operating fully and properly. I recommend that you try out the TI sample C program "clks". This is it:
     

    //****************************************************************************** // MSP430x26x Demo - Basic Clock, Output Buffered SMCLK, ACLK and MCLK/10 // // Description: Buffer ACLK on P5.6, SMCLK(DCO) on P5.5, MCLK on P5.4 and // MCLK/10 on P5.3. // ACLK = LFXT1 = 32768Hz, MCLK = SMCLK = CALxxx_8MHZ = 8MHz // //* External watch crystal on XIN XOUT is required for ACLK *// // // MSP430F261x/241x // ----------------- // /|\| XIN|- // | | | 32kHz // --|RST XOUT|- // | | // | P5.6|-->ACLK = 32kHz // | P5.5|-->SMCLK = 8MHz // | P5.4|-->MCLK = DCO // | P5.3|-->MCLK/10 // // B. Nisarga // Texas Instruments Inc. // September 2007 // Built with CCE Version: 3.2.0 and IAR Embedded Workbench Version: 3.42A //****************************************************************************** #include "msp430x26x.h" void main(void) { WDTCTL = WDTPW + WDTHOLD; // Stop Watchdog Timer if (CALBC1_8MHZ ==0xFF || CALDCO_8MHZ == 0xFF) { while(1); // If calibration constants erased // do not load, trap CPU!! } BCSCTL1 = CALBC1_8MHZ; // Set DCO to 8MHz DCOCTL = CALDCO_8MHZ; P5DIR |= 0x78; // P5.6,5,4,3 outputs P5SEL |= 0x70; // P5.6,5,4 options while (1) // 10 MCLK cycle loop { P5OUT |= 0x08; // P5.3 = 1 P5OUT &= ~0x08; // P5.3 = 0 } }
     
    Bust out your oscilloscope and measure the signals on pins P5:3,4,5 & 6.
     
    Make sure that they are what they ought to be.
     
    If they are then you can conclude that your program is doing something not quite right.
     
    If they are not doing what they ought to be then replace the chip and try again.
     
    Let us know how it goes.
  3. Like
    AaronInSpace reacted to zeke in MCLK stuck high   
    Is your msp damaged?
     
    Try swapping in another msp.
  4. Like
    AaronInSpace reacted to Fe2o3Fish in Strange Stack Issue   
    One thing that I do when I'm trying to isolate a problem in a single function is to
    take that function and compile it somewhere I can debug it; preferably on a similar
    architecture. If you have a Launchpad to EZ-430, I'd compile the function with
    some test data and debug it there.
     
    But, quite frankly, the function appears to be sound and I tested it on my laptop with
    no ill effects. If the algorithm works then something external is causing problems,
    either the system itself or the compiler.
     
    I'd suggest getting the listing of this function from the compiler with the assembler
    statements and see if everything is going where it should and in the right quantities.
     
    I also modified your for() loop for a bit of efficiency. You can get rid of both the
    'cur' and 'BYTE_HIGH_MASK' variables since they are not used. This might free
    up 4-bytes from your stack if you're pinched for space.

    for (i = 0; i < data_length; i+=2) { // Grab the highest 8 bits of the first 12 bit number *buffer++ = (unsigned char) ( ( data[i] >> 4) & BYTE_LOW_MASK); // Grab the lowest 4 bits of the first, highest 4 bits of the second *buffer++ = (unsigned char) ( ( ( data[i] << 4) & BYTE_LOW_MASK) + ( ( data[i + 1] >> 8) & BYTE_LOW_MASK)); // Grab the lowest 8 bits of the second number *buffer++ = (unsigned char) ( data[i + 1] & BYTE_LOW_MASK); }
    On an x86 I saved about 64-bytes of code. Will probably be higher on the 430.
    And yes, the output will be the same as your original loop.
     
    Personally, I'd return a -1 on an error at the top of the function simply because
    a zero could legitimately be passed in data_length. With no error, your function
    will return 0 as well.
     
    Somethings to think about...
     
    -Rusty-
  5. Like
    AaronInSpace reacted to Fe2o3Fish in Strange Stack Issue   
    Don't know how much experience you have with C on non-virtual memory machines
    but just because a crash occurs inside a function doesn't mean that said function is
    actually causing the crash. Do you have any interrrupts active when this function is
    running?
     
    If adding the 'int t = 63;' prevents the problem, is the problem averted if this definition
    is placed elsewhere within the function? I'm thinking that the value of 'i' could be getting
    corrupted while in the for() loop. With 'i' getting corrupted could lead to memory anywhere
    in the system to be FUBAR'd, including the stack.
     
    Any chance you're manipulating enough data in this function that the Watchdog is not
    getting "feed"?
     
    Have you tried stepping through the code with a debugger? The results?
     
    Just some thoughts... If they don't work you can have consultation fees refunded in full!!! :-)
     
    -Rusty-
  6. Like
    AaronInSpace reacted to gordon in LaunchPad as UART level shifter   
    Absolutely agree. FTDI does cost more, but the peace of mind that it just works, and will work when you need it most, priceless. That can be somewhat less told about Prolific and much less about CP2102 (speaking of Linux and FreeBSD experience).
  7. Like
    AaronInSpace reacted to rockets4kids in LaunchPad as UART level shifter   
    PL-2303 dongles can be had super-cheap, but the drivers give lots of people troubles. Dongles with the FTDI chip can save much hair-pulling.
  8. Like
    AaronInSpace got a reaction from bluehash in LaunchPad as UART level shifter   
    Has anyone ever used their LaunchPad as a tool to quickly hook up some external UART module (such as the XBee WiFi) to a PC? I tried just plugging the data out from the XBee to the TXD of the LaunchPad with a MSP430G2553 chip and the following code to disable the MSP430 and allow me to just pass-through:

    #include void main(void) { // Stop watchdog WDTCTL = WDTPW + WDTHOLD; P1DIR = 0; P2DIR = 0; while (1); }
     
    Didn't seem to work though. Any advice or remarks?
     
    EDIT: Aw, what the heck. Let's tell you what I'm up to and see if I'm on the right track. So I got an XBee WiFi module but didn't buy their whole development kit (overpriced and way more gear than I need). So I want to hook up the XBee through a UART to my PC. I thought the LaunchPad must be doing some level-shifting to TTL levels from 3.3V and so that I should hook the XBee up through the LaunchPad's TXD/RXD pins.
  9. Like
    AaronInSpace reacted to Mac in LaunchPad as UART level shifter   
    You might also consider using a clone Nokia CA-42 usb-to-serial adapter cable ($2.68, including shipping, from China) which uses the Prolific PL-2303 USB IC (3.3-5.0v serial I/O levels).
     

     
    I cut off the connector on the cell phone end of the adapter and install a 3.5mm stereo plug with Tx, Rx, and ground connections. Then I install a 3.5mm stereo jack on my project boards. This provides simple and inexpensive USB connectivity for everything from the smallest 6-pin PIC10F200 projects on up to my MSP430 Iambic Keyer project (with no USB software overhead).
     
    Regards, Mike
  10. Like
    AaronInSpace reacted to bluehash in LaunchPad as UART level shifter   
    Hmm.. won't disconnecting the two middle jumpers work out of the box? Just connect your zbee to the pc side of the debugger. I like this hack, but looks like we are limited to 9600
  11. Like
    AaronInSpace reacted to gwdeveloper in LaunchPad as UART level shifter   
    This turned out to be a good idea. I don't have one of the Xbee units, but I tested it with a bluetooth module I have been tinkering with. Turns out to be a good way to make a bluetooth serial port. It didn't seem to make a difference whether the cpu was off or not. I could connect it to the ezFet TXD/RXD with no issues. It also worked connecting directly to P1.1 & P1.2.
  12. Like
    AaronInSpace reacted to gwdeveloper in LaunchPad as UART level shifter   
    Sounds like a good idea. Did you try putting the cpu in LPM4 to shut it down?
  13. Like
    AaronInSpace reacted to HylianSavior in Remote video RC Car   
    I also looked into cameras for my quadrotor.
    Here's what I came up with:
    http://www.micro4you.com/store/modules/ ... -fifo.html
    http://www.emartee.com/product/41804/OV ... a%20Module
    There are other very similar cameras, but this one has a FIFO and a nice black PCB to block out light.
     
    Although I'm questioning whether the MSP430 can push frames fast enough for video... My initial guess would be no.
    As for trying out wifi, please do return with results. I still wouldn't recommend it on anything flying, but it'll probably be fine on an RC car that doesn't go too far away. Note that wifi tends to suck up a lot of power in return for that transmission speed.
  14. Like
    AaronInSpace got a reaction from zeke in anyone notice digi's new wifi module yet?   
    Well i ordered one yesterday along with a breakout board by sparkfun. Ill be sure to let you know how it went.
  15. Like
    AaronInSpace got a reaction from zeke in Learning Python   
    I am learning Python in college right now as an experienced programmer. We are using one of the books linked on that list you showed: http://www.greenteapress.com/thinkpytho ... ython.html
    It's a pretty good book but is a bit basic. Python is pretty darn easy to learn just sitting down and trying with Google at your side.
     
    I also use PyQt /PyQwt at work and its pretty neat. A lot easier than Java and Swing in my mind. The development in Python is freaking fast. I'd recommend it.
  16. Like
    AaronInSpace reacted to xmob in RC Car Electronic Speed Controller...control   
    Have you tried connecting your output to a servo?
     
    If the servo moves predictably, at least you have some confirmation that your code is on the right track.
  17. Like
    AaronInSpace reacted to HylianSavior in RC Car Electronic Speed Controller...control   
    Here's the basic method of using an ESC (make sure you're sending servo signals and not just any old PWM signal!):
    -Connect ESC to live power (you may or may not hear beeping)
    -After a bit, send a neutral servo signal - i.e. it would keep a servo dead center at 90 degrees
    -Sending signals above neutral should move it forward, while sending signals below neutral should move it backwards.
     
    At least that's how it works from what I remember. There's always a signal you need to send first to "arm" it. Try a program that does a sweep of a bunch of different PWM values.
  18. Like
    AaronInSpace reacted to HylianSavior in Remote video RC Car   
    I roughly calculated the bandwidth for live digital video over the 2.4 GHz band for my quadrotor a while ago.
    You get 250 kilobits per second, assuming no lost packets. Let's say a reasonably sized (smaller than VGA) compressed still image runs around 16 kilobytes, which equals 128 kilobits. You'd basically get ~2 fps on compressed data, assuming no error correction on lost packets. If you end up using something like a router with dd-wrt as a control board, you might get some better bandwidth with wifi, but wifi tends to be bad when things are moving about and causing interference.
     
    In short, if you want live video, analog is the (only) way to go, especially if you want an FPV plane. If you want the occasional still frame, digital might still work. I haven't seen any digital FPV systems on RC planes, though.
  19. Like
    AaronInSpace reacted to bluehash in Remote video RC Car   
    Well, if you use zigbee's, error correction is built in and independent of the packet(provided a packet is within the error correction range). I haven't tried it. Just something I read about digi's zigbees.
  20. Like
    AaronInSpace got a reaction from bluehash in Real Time Clocks   
    I have worked a bit with the NXP PCA8565 (http://www.nxp.com/documents/data_sheet/PCA8565.pdf) and it works nicely. Has everything I would want from one, but I have never used the timer or alarm side of it. Just the timekeeping portion. Works over I2C.
  21. Like
    AaronInSpace reacted to zeke in Brake Signal Light   
    Uhm, from a power dissipation point of view, using a linear regulator to drop 12V to 3V would be a rather hot proposal. Literally.
     
    Depending on the current draw of the circuit, you would have (12-3)Volts * Amps = Power dropped across the regulator. It comes out as heat.
     
    Might I suggest a switching regulator to do the same thing?
     
    Here's a part to prime your imagination.
     
    Just a thought to consider.
  22. Like
    AaronInSpace reacted to bluehash in Remote video RC Car   
    if you want real time video, the analog way is the best. Once you digitize it, you wil need to take bandwidth into consideration. You do get serial jpeg cameras which you can hook onto a zigbee and get wireless vide, but that will limit your framerate to maybe 3-4 images/second.
     
    http://www.sparkfun.com/products/9334
  23. Like
    AaronInSpace reacted to thanhtran in Remote video RC Car   
    I've not heard of any RC plane / RC heli guys doing any FPV by packet video yet (except the AR Drone, but its video is pretty jerky from what I've seen). From what I've seen, they all use analog video transmitter for FPV. They even complained about the latency of the GoPro HD camera with its video out mode transmitted via analog transmitter being not fast enough. I didn't see any problem with this camera though.
  24. Like
    AaronInSpace reacted to longhorn engineer in Non-ADC-driven PWM servo control with Launchpad   
    I know this post is close to a week old but you need to make sure the grounds between the Launch pad and the servo are connected.
  25. Like
    AaronInSpace reacted to RobG in Non-ADC-driven PWM servo control with Launchpad   
    I took your code and tested it with my servo.
    First one keeps the servo near the center point, second one, see the video (works as expected.)
    The only difference between LP's 3.6V and 5V is the speed at which the servo is turning.
    One suggestion, try adjusting 20ms delay and see if that helps.
     
    BTW, there was a fellow who had a similar problem.
     


×
×
  • Create New...