Jump to content

roadrunner84

Members
  • Content Count

    1,370
  • Joined

  • Last visited

  • Days Won

    33

Reputation Activity

  1. Like
    roadrunner84 got a reaction from abecedarian in String conversion problem   
    Energia stores strings to be sent over serial in a buffer and sends them after running an iteration through loop().
    Best thing to do is stop using LPM4 (which kills off every clock domain) and see if things work.
    Then, if things work, try using LPM1, then LPM3, not LPM4.
    If you still have issues, the quickest solution is to delay a while after sending things over serial to make sure it's sent before going to low power mode.
     
    The problem with your reprogramming of the chip (I assume you're trying to update the programmer, not the msp430 itself) is you're using Windows 9, which has never been released for consumers. Try either upgrading to Windows 10 or downgrading to Windows 7. If that doesn't work, try to reinstall the drivers or using a different USB port.
  2. Like
    roadrunner84 got a reaction from yyrkoon in PWM from ADC joystick   
    //#include <msp430.h>
    #include <msp430g2553.h>
     
    /*
    * main.c
    */
     
    void main(void)
    {
    //int adcValue;
    WDTCTL = WDTPW | WDTHOLD; // Stop watchdog timer
     
     
     
    //This is ADC10 control register
    //4th bit turns on ADC
    //11 and 12 sets "16
  3. Like
    roadrunner84 got a reaction from LiviuM in Basic MSP430 GPIO Macros   
    You could consider using C++ template programming instead of C style defines.
    I haven't tested this, but it would go something like this:
    template <int port> void GPIO_IS_INPUT(int pin) { GPIO_SEL(port) &= ~(pin); GPIO_DIR(port) &= ~(pin); } template <> void GPIO_IS_INPUT<J>(int pin) { GPIO_DIR(J) &= ~(pin); } Now instead of passing port as a macro like function parameter, pass it as a template parameter
    GPIO_IS_INPUT<LED1_PORT>(LED1_PIN); I'm not entirely sure this will work though; the double-hash preprocessor operator is very tricky.
     
    You could go all the way with these templates and get gone with the macros entirely.
    If you really want no function call overhead, just make them inline.
  4. Like
    roadrunner84 got a reaction from LiviuM in Basic MSP430 GPIO Macros   
    You could consider using C++ template programming instead of C style defines.
    I haven't tested this, but it would go something like this:
    template <int port> void GPIO_IS_INPUT(int pin) { GPIO_SEL(port) &= ~(pin); GPIO_DIR(port) &= ~(pin); } template <> void GPIO_IS_INPUT<J>(int pin) { GPIO_DIR(J) &= ~(pin); } Now instead of passing port as a macro like function parameter, pass it as a template parameter
    GPIO_IS_INPUT<LED1_PORT>(LED1_PIN); I'm not entirely sure this will work though; the double-hash preprocessor operator is very tricky.
     
    You could go all the way with these templates and get gone with the macros entirely.
    If you really want no function call overhead, just make them inline.
  5. Like
    roadrunner84 got a reaction from LiviuM in Basic MSP430 GPIO Macros   
    You could consider using C++ template programming instead of C style defines.
    I haven't tested this, but it would go something like this:
    template <int port> void GPIO_IS_INPUT(int pin) { GPIO_SEL(port) &= ~(pin); GPIO_DIR(port) &= ~(pin); } template <> void GPIO_IS_INPUT<J>(int pin) { GPIO_DIR(J) &= ~(pin); } Now instead of passing port as a macro like function parameter, pass it as a template parameter
    GPIO_IS_INPUT<LED1_PORT>(LED1_PIN); I'm not entirely sure this will work though; the double-hash preprocessor operator is very tricky.
     
    You could go all the way with these templates and get gone with the macros entirely.
    If you really want no function call overhead, just make them inline.
  6. Like
    roadrunner84 reacted to Lyon in Extremely simple ARM assembly example with Tiva C?   
    HI,
     

    Well, while it is possible to do such small program as you do for MSP430, you must take into account the major differences between MSP430 and Cortex-M4: the latest imposes some discipline in program writing. This is due to hardware realization of the inside circuitry of Cortex.    First flash location is at address 0 and in this location must reside the address of stack pointer, even if it is not used. The second location is the address of startup routine; this must be also present; at startup the processor uses these two locations and then goes further, so you must provide them. This address and the rest of interrupt vectors must have the last bit set to 1, making it odd number, despite even alignment - this last bit is internal signal for thumb interrupt - as requested by ARM. Note this is compiler's job, but directed by you.   Next, after these two locations, there must be the rest of interrupt vectors locations, properly initialized. You need these also - otherwise you will be soon in trouble, at the first mistake. You must know also this processor is provided with a unusual big and complex debug and diagnostic machine - so fault interrupts must be really initialized and a code body provided for them. So this is why in general, you must use two files for every small program (and Valvano is best to follow and learn from):  - one is a startup.S, which is written only once; - the other one is main.S which is your program.   I understand your pain - this is not so simple - and using IAR is an add-on, since no example - of coarse you must read/learn IAR documentation - however an example written in IAR assembler can be found in TIVA/boot_loader/bl_startup_ewarm.S - you can copy/paste from that file a lot...   Hope this will help you,
  7. Like
    roadrunner84 reacted to jazz in Basic Question in using MSP430   
    I just don't see any reason for buying old MSP430G2 LP with not updatable firmware and limited support for 10$, when new MSP430F5529 LP based on eZ-FET Lite with updatable (open source) firmware can program all SBW devices for 13$.
  8. Like
    roadrunner84 got a reaction from energia in I2C for beginners   
    First of all, I2C has this oddity of using 7 bit addresses. When representing 7 bits in an 8 bit byte, it's never clear where to add the extra zero bit.
    Your device address is
    1001xxx
    But does this translate to
    01010xxx
    or to
    1010xxx0
    try using 89h instead of A2h, it might just work.
     
    Next thing, when writing 16 bit values over an 8 bit bus, make sure you have thew byte order (also called endianness) correct.
    Does 00FFh
    0000000011111111
    translate to 00h, FFh
    00000000 11111111
    or to FFh, 00h
    11111111 00000000
    so you could try either (or read back both addresses).
  9. Like
    roadrunner84 got a reaction from Fmilburn in It's Halloween Again   
    @@Fmilburn
    Nice wearable pcb! Would you consider replacing the 6-pin header with the 0.05" 4 pin header, or maybe even a tagconnect? then it would be even better looking and less susceptible to getting stuck to clothing with the header. You might even squeeze in one or two extra pads!
  10. Like
    roadrunner84 got a reaction from energia in Can SoftwareSerial library work with msp430g2553   
    It looks like you're using software serial, but try to initialize your GPS module using hardware serial.
    Should the setup not call nss.write() all the time, instead of Serial.write()?
  11. Like
    roadrunner84 got a reaction from pokmo in Reading data from 3.5mm audio jack   
    I was talking about OOK (on-off keying), while your latest schematic is talking about FSK (frequency shift keying).
     
    The difference is that FSK will send one frequency for high bits and another for low bits, while OOK will send one frequency for high bits and no frequency (DC, 0Hz) for low bits (or the other way around).
     
    So FSK has the added value of distinguishing high/low bits from an idle line. In the case of UART serial, you don't need this detection per se, because a high bit and an idle line are not distinguishable anyway.
     
    Then again, if you have the software to do FSK, just use it. If you make things from scratch, OOK might prove simpler to implement.
  12. Like
    roadrunner84 got a reaction from pokmo in Reading data from 3.5mm audio jack   
    I was talking about OOK (on-off keying), while your latest schematic is talking about FSK (frequency shift keying).
     
    The difference is that FSK will send one frequency for high bits and another for low bits, while OOK will send one frequency for high bits and no frequency (DC, 0Hz) for low bits (or the other way around).
     
    So FSK has the added value of distinguishing high/low bits from an idle line. In the case of UART serial, you don't need this detection per se, because a high bit and an idle line are not distinguishable anyway.
     
    Then again, if you have the software to do FSK, just use it. If you make things from scratch, OOK might prove simpler to implement.
  13. Like
    roadrunner84 got a reaction from energia in Reading data from 3.5mm audio jack   
    Easiest way is to use an opamp (there are msp430 with built in comparator/opamp) and use/abuse the opamp as a filter. Then "encode" serial commands (you have to go serial at some point!) by transmitting high bits as one frequency and low bits as another frequency (or no signal at all).
    Then you can use the output from the filter to acquire an analog voltage that is close to the desired levels.
    Essentially you're using discrete amplitude modulation (AM) with a modulation depth of 100%, this is the same as OOK (on-off keying).
    Note that such a system will have a low bandwidth, don't expect any rate in the order of kilobits.
    Also, you can see that this is roughly what the softmodem solution is doing; taking a signal, filtering it and shoving it down the msp's throat.
  14. Like
    roadrunner84 got a reaction from energia in Reading data from 3.5mm audio jack   
    Easiest way is to use an opamp (there are msp430 with built in comparator/opamp) and use/abuse the opamp as a filter. Then "encode" serial commands (you have to go serial at some point!) by transmitting high bits as one frequency and low bits as another frequency (or no signal at all).
    Then you can use the output from the filter to acquire an analog voltage that is close to the desired levels.
    Essentially you're using discrete amplitude modulation (AM) with a modulation depth of 100%, this is the same as OOK (on-off keying).
    Note that such a system will have a low bandwidth, don't expect any rate in the order of kilobits.
    Also, you can see that this is roughly what the softmodem solution is doing; taking a signal, filtering it and shoving it down the msp's throat.
  15. Like
    roadrunner84 reacted to enl in What's more precise: UART via crystal or DCO?   
    The guideline for picking a clock source and the required accuracy and stability is pretty straightforward, but in general, using the DCO is what you want. If you have the crystal in system, the DCO frequency can be compared to it and the bit rate divisor can be adjusted for best approximation.
     
    The error rate given describes the accumulated timing error, NOT the unreliability of the line, and can be used to determine whether there is likely to be data errors in transmition due to timing issues.
     
    To add a little background, the bits are sent and received in nominally identical time slices. The first edge of the start bit is used to synchronize the process, and, from then on, the receiver examines the line at the middle of each bits allotted time slice. For 8 bit data, with a start and a stop, the total time used is 9.5 bit times, and if the timing slips more than 0.5 bit times in that, then the receiver may lose synchronization on the later bits and the stop bit. This will trigger an error state if the receiver expects the bits faster than the sender provides them, and the bit the receiver sees as the stop isn't the appropriate stop state, and confusion will result from a number of possible ways for the synchronization to fail leading to bits being read as the wrong position in the data.
     
    THis 0.5/9.5 ratio means that the maximum difference in bit rate , for reliable operation, is 5.5%.  THis isn't bad, but does require a decent clock  at both ends. If both clocks are off by 3% in different directions, then there will probably be loss of synchronization. This is the total difference, and, if one clock is very close, the other tan take substantially all of the error (this is not an unusual case, but is not always the case)
     
    The clocks for the MSP430 that make sense here are, as you said, the DCO and a 32KHz crystal. The Crystal is accurate to about 0.01% worst case. The DCO is accurate to maybe 3% typical. On the other hand, as you noted, due to the need to produce the serial clock by dividing the control clock, at bit rates that are greater than about 5% of the clock rate, there will be bit rates that can not be generated to meet the requirement. For historical reasons, the standard bit rates don't play well with power-of-two frequencies like 32768Hz.
     
    The situation is improved (and this is where the more favourable looking that expected error bound for the crystal comes from) by dithering the clock when you can't get an exact match: The basic rate is higher than needed, and some bits are stretched by a clock to minimize the accumulated error. This works well, but, if done at both ends of the line, can fail when the bitrate is about 1/5 of the clock rate (6Kbs with the 32KHz crystal). This is a rough number, not exact, since it depends on the details of how the bit time adjustment is done. If one end is dead stable, and an extra stop bit is thrown in, it works quite well up to  maybe 1/3 of the clock rate (9600bps with a 32KHz crystal).
     
    All of that said, I usually just use the factory calibrated DCO frequency and have no problem. I don't even bother with checking the exact frequency.
  16. Like
    roadrunner84 got a reaction from sq7bti in SPI and I2C on same pin   
    No you can't, since your SPI device can send data through P1.6 to your MSP430, you can't make certain that no accidental START token is present on the pins during SPI mode.
    Also, I2C pins are common-collector; they use a pull up resistor and only pull the line down. While SPI is push-pull; it driver the line either high or low. Driving the line high while your I2C device (accidentally, after interpreting a START token) pulls it low might cause damage to the driver on either side of the line.
    A way to maybe make it possible is by having some external hardware to disable SCL while in SPI mode. Since in SPI mode you'd have your CS# line low, you could use a single transistor to have P1.6 disconnect from your SCL net during SPI mode.
    +3v3 | | +-+ |2| |k| |2| +-+ | +-+----------> to device SCL pin | |/ C MSP430 CS# pin--| NPN-transistor |\ E | | MSP430 P1.6 ------+------------< to device MISO pin
  17. Like
    roadrunner84 got a reaction from Apr30 in What's more precise: UART via crystal or DCO?   
    The lower your source clock frequency, the less accurate you can tune your baud rate. So using a 32kiHz source would be less favourable.
    But the crystal is more stable than an RC oscillator (like the DCO), even if the RC oscillator is temperature compensated.
    So using a high frequency source (like the DCO) will help you get a more accurate clock, but it would be less stable than using the crystal.
    The best way would be to regularly tune your internal oscillator to a stable external crystal clock source. This is where PLL comes in to play.
    I think you can use the LFXT as a PLL source to your DCO, but I'm not sure.
     
    As you may have noticed, I kept talking about stability and accuracy, not about reliability. If you want your UART to be reliable, you would prefer the baud rate to be as close to the desired baud rate as possible, with as little jitter or drift as possible.
    For real world scenarios, that drift and jitter is barely a problem when using a baud rate as low as 9600Bdps.
    Also note that in the case of the msp430g2 Launchpad, you cannot go higher without using an external UART to your PC or other peripheral, because the emulator does not support higher baud rates.
     
    I'd err on using the DCO over the LFXT, because you can get a better approximation of the desired baud rate.
  18. Like
    roadrunner84 got a reaction from Apr30 in What's more precise: UART via crystal or DCO?   
    You can make FLL in software, this is the basic process.
    Count a set number of LFXT/ACLK ticks in DCO/SMCLK ticks: Set a timer (can be the watchdog) to fire every X ticks of ACLK, set another timer to run on SMCLK. Reset both timers. Sample the second timer when the first timer fires.
    Now you know how many SMCLK ticks go in X ACLK ticks, since ACLK is derived from the LFXT, you can tune your DCO (SMCLK source) to get closer to the desired value.
     
    This of course takes time, time you may not have. But if you can spare a bit, add this FLL before every message you send over UART. If that's too heavy, sample every second or minute. Alternatively (if you don't need the reset on watchdog) have the timers run continuously in the background and do this stuff in the ISR.
  19. Like
    roadrunner84 got a reaction from Apr30 in What's more precise: UART via crystal or DCO?   
    The lower your source clock frequency, the less accurate you can tune your baud rate. So using a 32kiHz source would be less favourable.
    But the crystal is more stable than an RC oscillator (like the DCO), even if the RC oscillator is temperature compensated.
    So using a high frequency source (like the DCO) will help you get a more accurate clock, but it would be less stable than using the crystal.
    The best way would be to regularly tune your internal oscillator to a stable external crystal clock source. This is where PLL comes in to play.
    I think you can use the LFXT as a PLL source to your DCO, but I'm not sure.
     
    As you may have noticed, I kept talking about stability and accuracy, not about reliability. If you want your UART to be reliable, you would prefer the baud rate to be as close to the desired baud rate as possible, with as little jitter or drift as possible.
    For real world scenarios, that drift and jitter is barely a problem when using a baud rate as low as 9600Bdps.
    Also note that in the case of the msp430g2 Launchpad, you cannot go higher without using an external UART to your PC or other peripheral, because the emulator does not support higher baud rates.
     
    I'd err on using the DCO over the LFXT, because you can get a better approximation of the desired baud rate.
  20. Like
    roadrunner84 got a reaction from Apr30 in What's more precise: UART via crystal or DCO?   
    The lower your source clock frequency, the less accurate you can tune your baud rate. So using a 32kiHz source would be less favourable.
    But the crystal is more stable than an RC oscillator (like the DCO), even if the RC oscillator is temperature compensated.
    So using a high frequency source (like the DCO) will help you get a more accurate clock, but it would be less stable than using the crystal.
    The best way would be to regularly tune your internal oscillator to a stable external crystal clock source. This is where PLL comes in to play.
    I think you can use the LFXT as a PLL source to your DCO, but I'm not sure.
     
    As you may have noticed, I kept talking about stability and accuracy, not about reliability. If you want your UART to be reliable, you would prefer the baud rate to be as close to the desired baud rate as possible, with as little jitter or drift as possible.
    For real world scenarios, that drift and jitter is barely a problem when using a baud rate as low as 9600Bdps.
    Also note that in the case of the msp430g2 Launchpad, you cannot go higher without using an external UART to your PC or other peripheral, because the emulator does not support higher baud rates.
     
    I'd err on using the DCO over the LFXT, because you can get a better approximation of the desired baud rate.
  21. Like
    roadrunner84 got a reaction from Apr30 in What's more precise: UART via crystal or DCO?   
    The lower your source clock frequency, the less accurate you can tune your baud rate. So using a 32kiHz source would be less favourable.
    But the crystal is more stable than an RC oscillator (like the DCO), even if the RC oscillator is temperature compensated.
    So using a high frequency source (like the DCO) will help you get a more accurate clock, but it would be less stable than using the crystal.
    The best way would be to regularly tune your internal oscillator to a stable external crystal clock source. This is where PLL comes in to play.
    I think you can use the LFXT as a PLL source to your DCO, but I'm not sure.
     
    As you may have noticed, I kept talking about stability and accuracy, not about reliability. If you want your UART to be reliable, you would prefer the baud rate to be as close to the desired baud rate as possible, with as little jitter or drift as possible.
    For real world scenarios, that drift and jitter is barely a problem when using a baud rate as low as 9600Bdps.
    Also note that in the case of the msp430g2 Launchpad, you cannot go higher without using an external UART to your PC or other peripheral, because the emulator does not support higher baud rates.
     
    I'd err on using the DCO over the LFXT, because you can get a better approximation of the desired baud rate.
  22. Like
    roadrunner84 got a reaction from Apr30 in What's more precise: UART via crystal or DCO?   
    The lower your source clock frequency, the less accurate you can tune your baud rate. So using a 32kiHz source would be less favourable.
    But the crystal is more stable than an RC oscillator (like the DCO), even if the RC oscillator is temperature compensated.
    So using a high frequency source (like the DCO) will help you get a more accurate clock, but it would be less stable than using the crystal.
    The best way would be to regularly tune your internal oscillator to a stable external crystal clock source. This is where PLL comes in to play.
    I think you can use the LFXT as a PLL source to your DCO, but I'm not sure.
     
    As you may have noticed, I kept talking about stability and accuracy, not about reliability. If you want your UART to be reliable, you would prefer the baud rate to be as close to the desired baud rate as possible, with as little jitter or drift as possible.
    For real world scenarios, that drift and jitter is barely a problem when using a baud rate as low as 9600Bdps.
    Also note that in the case of the msp430g2 Launchpad, you cannot go higher without using an external UART to your PC or other peripheral, because the emulator does not support higher baud rates.
     
    I'd err on using the DCO over the LFXT, because you can get a better approximation of the desired baud rate.
  23. Like
    roadrunner84 got a reaction from NurseBob in MSP430G2553 LPM4 works by current doesn't go bellow ~ 75 ?A   
    True, but lowing the voltage to 1.8V forces you to lower the clockspeed in those slivers of time you're not in LPM4, because you can't run at high speeds on that low a voltage.
  24. Like
    roadrunner84 got a reaction from sporkey in EXP430(G2553) Problem with Timer1 using ACLK (SOLVED)   
    As I read the datasheet, after P2SEL = BIT6; P2.6 will be a timer output, but only if you write P2DIR = PIN6; too. So your crystal isn't oscillating anymore.
    If you write P2SEL |= BIT6; the crystal will be functioning because you set a bit that was already set. But if you add P2DIR |= BIT6; then you switch to an undescribed situation; it looks like you want the pin to behave like XOUT, not XIN.
  25. Like
    roadrunner84 got a reaction from sporkey in EXP430(G2553) Problem with Timer1 using ACLK (SOLVED)   
    I think your problem is related to the crystal.
    The crystal is connected to P2.6 and P2.7, but you overwrite P2SEL and P2DIR with non-default values.
    As a result, the crystal is not controlled correctly anymore and ACLK is dead.
    To avoid this problem, try to use |= and &=~ as much as possible to set or clear bits.
    P1SEL |= BIT1; // set SEL1 bit 1 P1SEL &= ~BIT2; // clear SEL1 bit 2 P1SEL |= (BIT1 | BIT2); // set SEL1 bit 1 and 2 P1SEL &= ~(BIT1 | BIT2); // clear SEL1 bit 1 and 2 P1SEL = (P1SEL | BIT1) & ~BIT2; // set SEL1 bit 1 and clear bit 2
×