Jump to content


  • Content Count

  • Joined

  • Last visited

Reputation Activity

  1. Like
    Yuri reacted to JWoodrell in Developing software for MSP430!   
    that tells me that the "Haptics_SendWaveform(erm_rampup);" is not a latching command.  if it is called continuously it will run the motor, but when its only called once (when its in the if loop) it does a single "pulse" to the motor then stops.   I may try to dig through your code to see what can be done to make the command latch for the duration of the waveform profile, but I don't have time right now
  2. Like
    Yuri reacted to JWoodrell in Developing software for MSP430!   
    I think I got it...  maybe.
    as soon as a something is recieved, you set "character" to that.
    #pragma vector=USCIAB0RX_VECTOR __interrupt void USCI0RX_ISR(void) {     character = UCA0RXBUF; // <--- here } since it is not sleeping your main loop is continuously running when not iN an interrupt.  you are saying if "character" is NOT "/R" then echo it out the TX...  however you never clear the "character" after you echo it out, so it just keeps spewing out the most recently recieved character in the main loop.   while(1) { __bis_SR_register(GIE); //__low_power_mode_0(); // Interrupts enabled if(character != '\r') // <--- this is the problem { write(character); //echo // <--- never clears "character" afterward if(character != '\b') { buffer[iterator] = character; iterator++; } } } I would add a line after the  "write(character); //echo" line that sets character back to "/r"
    if(character != '\r') { write(character); //echo character = '\r'; // <--- here or to "0" and change the outer if loop
    if(character && character != '\r') // <--- here { write(character); //echo character = 0x00; // <--- here but that is what I see as causing your new issue
    you will need to work with where put it depending on what other functionality you want (the '/b' section in the main loop)  but you can figure it out from there
  3. Like
    Yuri reacted to simpleavr in Developing software for MSP430!   
    Should that be in UCA0RXBUF?
    Create a volatile variable outside and may be in your main, check on it periodically for non-zero. And process command when non-zero, then set it back to zero to wait for next.
    static volatile uint8_t cmd=0; // Echo back RXed character, confirm TX buffer is ready first #pragma vector=USCIAB0RX_VECTOR __interrupt void USCI0RX_ISR(void) { while (!(IFG2&UCA0TXIFG)); // USCI_A0 TX buffer ready? // save RXed char before sending it back.. cmd = UCA0RXBUF; UCA0TXBUF = UCA0RXBUF; // TX -> RXed character }   And a typical low power application would do a loop to sleep, wait for interrupt to wake up and process command, like so, to save power.     replace __bis_SR_register(LPM0_bits + GIE); // Enter LPM0, interrupts enabled with while (1) { __bis_SR_register(LPM0_bits + GIE); // Enter LPM0, interrupts enabled switch (cmd) {     case xxx:.... }//swith }//while Just make sure you add
    __bic_SR_register(LPM0_bits); as the last line in your __interrupt void USCI0RX_ISR(void)
    This will allow you to wake up and immediately enter the "switch (cmd)" block upon receiving a character from PC.
  4. Like
    Yuri reacted to simpleavr in Developing software for MSP430!   
    In your Haptics_SendWaveform(..), you calls Haptics_OutputWaveform(..) which in turn calls timerdelay(..) in Timer.h
    The timerdelay(..) function will setup and enable Timer 0 w/ interrupt flag on. This will trigger the Timer_A0_ISR(..) interrupt handler we setup in main.c for handling uart Tx/Rx. I did not examine in detail but I am sure the interrupt handled will be called. I suspect this will cause a indefinite / very slow loop and the system is suspended.
    I had no luck compiling your code as the CTS/*.h is missing in your repo.
    I suggest you replace Timer.h functions (both timedelay and sleep) w/ delay_cycles(), or "for loops" to achieve delays. This will avoid contention problem w/ the s/w uart.
    Both functions (timedelay() and sleep()) just do up counts on CCR0, but on different clocks (ACLK and SMCLK), so may be you can approximate the time w/ delay_cycles().
    An alternative would be see if you can adopt h/w uart. I am not very familiar w/ it so you should check if the device / registers has any potential conflict w/ your other modules.
  • Create New...