JWoodrell 285 Posted June 4, 2013 Share Posted June 4, 2013 Interrupts dont require being in low power mode, they will happen regardless of the processor mode is long as interrupts are enabled. Your code line that says "__bis_SR_register(LPM0_bits + GIE); // Enter LPM0, interrupts enabled" is setting low power mode AND interrupts. Try just __bis_SR_register(GIE); // Enter LPM0, interrupts enabled ,or the direct shortcuts "__enable_interrupt(); // enable all interrupts --> GIE = 1 (HIGH) __disable_interrupt(); // disable all interrupts --> GIE = 0 (LOW)" This will let the interrupts run whenever Posted from my phone, forgive the typos Quote Link to post Share on other sites
Yuri 0 Posted June 4, 2013 Author Share Posted June 4, 2013 Thank you for the advice, but when I run those I do not believe the interrupts are working in the same fashion. Maybe it's a loop issue. If I enable interrupts, I now get a continuous stream of the character I type. They rapidly fill the prompt. My code for writing a character is : #pragma vector=USCIAB0RX_VECTOR__interrupt void USCI0RX_ISR(void) { UCA0TXBUF = UCA0RXBUF; character = UCA0RXBUF; __bic_SR_register(GIE);} void write(char ch) { while ((UCA0STAT & UCBUSY)); { UCA0TXBUF = ch; }} I apologize for the inconvenience! Quote Link to post Share on other sites
JWoodrell 285 Posted June 4, 2013 Share Posted June 4, 2013 my understanding of its behavior is that when a character is received, it just starts an infinite loop transmitting that character back out. How is it physically wired, it sounds like the TX line is somehow talking back into the RX line and retriggering another transmission. the only other thing I can think of is to manually reset the RX interupt flag at the very end of its ISR in case it is being triggered erroneously for some reason. can you post the whole code (probably zipped up if its getting too long) something is retriggering it now that its not sleeping, it may be in your main loop. Quote Link to post Share on other sites
Yuri 0 Posted June 5, 2013 Author Share Posted June 5, 2013 I just made a gist for my main. https://gist.github.com/CaptainSay/5713849 This is the only bit of code giving me issues, and the one tied to the interrupts. Quote Link to post Share on other sites
JWoodrell 285 Posted June 5, 2013 Share Posted June 5, 2013 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 Yuri 1 Quote Link to post Share on other sites
Yuri 0 Posted June 5, 2013 Author Share Posted June 5, 2013 That was exactly it! Thank you very much! I will now hopefully make some progress on this and report back if I hit any more roadblocks. I appreciate everyone's patience with me! Quote Link to post Share on other sites
Yuri 0 Posted June 5, 2013 Author Share Posted June 5, 2013 New issue! This time nothing to do with UART, surprisingly! So I tried to make a switch statement that would switch to certain vibration profiles, the vibration profiles will not engage. But if the haptic feedback is outside of the if or switch statements, they work just fine. I've confirmed that they work in my current main. It also is confirmed to work INSIDE of the while loop. My switch statement works, I had it output a string which would engage just fine. Just the haptic feedback is lost. I put the entire project up on Github if anyone is willing to take a look. I apologize for so many questions. I definitely need to study more after this project! Link : https://github.com/CaptainSay/CapTouchTest.git Logically, I don't see why a string would work inside of my switch statement, but not the vibration. Quote Link to post Share on other sites
simpleavr 399 Posted June 5, 2013 Share Posted June 5, 2013 @@Yuri There are just too many places to look at and I doubt a lot of people have your board and understand how it behaves. I can see different profiles toggle different io pins, etc. So we need to make sure if the pwm code fail to run, or the "haptic" hardware fail to response. Does the system hold up / freeze? Or just nothing happen (but you got your echo) and can accept new characters from PC? Some suggestion. 1. make use your Haptic_Sendwaveform() can work multiple times. I.e call it a few times separate by delays BEFORE entering while loop. 2. try change order of things. i.e may be do pwm before echo character back, and immediately set character back to '\r' before doing anything. 3. if your board has led indicator, use it to debug. Place code to turn it on in the middle of of your actions like after individual Haptic_xxxx steps, and progressively move the "led on" to the next function step. This way you will see if your code reaches those functions. Quote Link to post Share on other sites
Yuri 0 Posted June 6, 2013 Author Share Posted June 6, 2013 I get an echo, I just do not get a vibration. What I mean is. This will work : for(; { __bis_SR_register(GIE); write(character); character = 0x00; Haptics_SendWaveform(erm_rampup); } The board will vibrate continuously because it's a neverending loop. But the erm will rotate. BUT for(; { __bis_SR_register(GIE); write(character); if(character == 'a') { printf(" Successfully pressed 'a'! \r\n"); Haptics_SendWaveform(erm_rampup); } character = 0x00; } Will NOT work. It will output " Successfully pressed 'a'!" But it will NOT vibrate. As long as I don't put it in another loop inside of the for(; loop, it will vibrate, but putting it inside of an if or a switch will stop it from working. I apologize for asking such a huge question. Quote Link to post Share on other sites
JWoodrell 285 Posted June 6, 2013 Share Posted June 6, 2013 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 Yuri 1 Quote Link to post Share on other sites
Yuri 0 Posted June 6, 2013 Author Share Posted June 6, 2013 Thanks for the information! I will try to figure this out! Quote Link to post Share on other sites
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.