August 25th, 2012, 02:59 PM
Simple while loop question.
Using AVR-GCC, trying to have my program 'hold' and not process anymore code when a condition is set as true. I'm pretty sure this is how I do it, correct?
The program sets an output to low in an interrupt service routine and I want to make sure that the values are not updated to the output until the condition is set back to true.
The attempt a program 'pause":
PWM_off = 1;
OCR1A_old = OCR1A;
OCR1B_old = OCR1B;
OCR1C_old = OCR1C;
OCR1A = 0;
OCR1B = 0;
OCR1C = 0;
PWM_off = 0;
OCR1A = OCR1A_old;
OCR1B = OCR1B_old;
OCR1C = OCR1C_old;
while(PWM_off); //pause here until PWM_off is set to 0
OCR1A = R * brightness;
OCR1B = G * brightness;
OCR1C = B * brightness;
August 26th, 2012, 12:30 AM
Have you tried
volatile int PWM_off;
If the compiler "knows" the value is 1, and can see no way for the variable to change, it can easily generate code for while(1) instead.
The volatile qualifier tells the compiler to not optimise out apparently redundant accesses to the variable.
August 26th, 2012, 01:10 AM
The variable'PWM_off' is called in an ISR and in main so it is already set as volatile. My question is just: will it hang at the while lopp as long as the condition passed to it is true?
August 26th, 2012, 01:51 AM
> My question is just: will it hang at the while lopp as long as the condition passed to it is true?
Tell me, have you tried to run this code in the 12 hours since you posted it?
Try it, and post some actual information based on observed results. There is only so much guessing we can do based on incomplete code.
Yes it will "stop" at the while loop until the flag is set to zero, and no it won't stop the ISR from running. Assuming of course you haven't disabled all interrupts somewhere else in the code you haven't posted.
August 26th, 2012, 02:25 AM
I have tested it, but in all honesty there isn't much way I can check to see if it is working as intended. I can check for simple glitches in the PWM signal, but they aren't very apparent at ~1000Hz. I could also enable a HID USB listen program to communicate debug messages, but I'm not sure how I would check a no argument while loop.
Originally Posted by salem
August 26th, 2012, 06:05 AM
That was not obvious in your question - you should have included the declaration. Normally people post here what they have a problem, so the answers you received addressed the most likley problem from the information given. It seems in fact that you don't have a problem other than you do not know how to effectively test and debug your code.
Originally Posted by tightmopedman9
The best solution would be to use a hardware debugger such as the AVR Dragon for example. Any serious embedded development will be severely hampered without some sort of in-circuit debugger. The problem with using USB for debug I/O is that the necessary device stack is not an insignificant amount of software with a relatively high CPU load requirement, that software itself must be debugged and the load may affect the operation of teh software being monitored. A better ad-hoc approach would be to use UART serial I/O and a cheap USB<->RS232 adapter if your PC lacks a legacy serial port.
A simple way to debug this specific code would be to toggle a GPIO output pin after the wile loop. If the loop never terminates you will see no toggling, if it never waits you will see a very high frequency, and if it all works it will toggle at the PWM frequency (with perhaps some software overhead/jitter). You will of course need an oscilloscope to see that, but again if you are serious about embedded development, that would be standard equipment. If you are on a budget and the frequencies are sufficiently low, a simple PC based USB scope may be sufficient. Prices start very low for devices that work at frequencies of a few KHz, you pay more for more channels and high frequencies.
Finally another method is software simulation. Using an AVR simulator will allow you to test the code on a PC independent of hardware. The simulator will need the ability to emulate the peripheral devices with interrupt generation rather than just a basic instruction set simulator. Ideally it would work with your existing IDE integrated debugger if you are using one. You may already have such a simulator in your existing tool chain.