Re: sleep()
 

im sorry that i have to reiterate this, but you CAN NOT stop the program code from looping! no matter if it is with a non exastant "wait()" command or a for loop that devides PI by 100 million 50 thousand times, dont do it! it is much better, and perhaps the only viable solutuion, if you count the loops rather then trying to stop in the middle of one. each loop is ~26 ms. its not that hard to make 1 variable. comon guys.

Re: sleep()
 

It's not that, it's that the main loop has different iteration times depending on what is executed. Besides, It'd be so much cooller if we got it to work.

And like I said, just put calls to putdata and getdata in the loop.

Re: sleep()
 

Ken was right when he said that the timer will always run at the same speed. Texan probably meant that the motors being controlled by the timer would run slower ... which is true.

Getting back to the original focus of this post ... why do you want a sleep function? If you post the reason for your request for a sleep function, you'll probably get much better help.

Re: sleep()
 

if your going to the point where the diffrence between 23 and 26 ms matters, then use a timer inturupt. this is not a basic stamp lol

Re: sleep()
 

Any wait/pause code is the basis of a DriveForTime() Routine

Re: sleep()
 

yesm. i think were arguing the same thing here.

Re: sleep()
 

What? DriveForTime should do some driving for a given time ... but I don't see how any waiting is implicit in the function. Am I grossly mistaken? You can use a timer interrupt to drive for the specified amount of time, all you do is say:
Where's the need to wait? If you are 'pausing' (stuck in the loop for some reason), you sure aren't driving. Care to elaborate your thinking on the matter?

Re: sleep()
 

Although there are easy ways to make the processor "pause" or "wait" as described above, they are probably not the best way to implement this function on the IFI Controller. The Master processor expects to receive a data packet from the user processor every 26.2ms.

This means you cannot pause the controller for longer than 26.2ms at a time and still have the control system function.

The best bet is to increment a counter every time a new data packet is received from the master processor. If you need finer control than that, use a timer interrupt.

Re: sleep()
 

Do you mean "execution times"? I take "iteration time" to be the time between iterations of the 26.2 ms loop area. I actually measured this with a scope on Saturday, it was very interesting:

This made a pulse of about 4 ms in duration (the "exectution time" of my code), with a (measured) cycle time ("iteration time") of about 26 ms. Hitting certain buttons would change the 4 ms to something else like 3 ms as my code changed modes, but the period remained 26 ms. It seemed pretty rock-solid. Except when very strange things were happening; see my earlier post on that. But that was something broken.

One reason a delay might be useful is to reduce the frequency of calls to Generate_Pwms(). See the reply from Kevin Watson to the post mentioned above.

-Norm

Re: sleep()
 

Ive been wanting to scope the loop myself, but havent got to it yet- thanks for instrumenting your RC.

One thing I have not been able to figure out. The main loop looks for new input from the OI, and if it doesnt see it, it call the user_fast code

I dont see anything in the fast code to throttle it back - can you put your toggles at the beginning and end of the fast section and see how fast it runs with your scope for us?

I thought they said it runs every 4mS or so, and you have to be carefull not to overwhelm the pwms by changing them too fast - I also think you cannot do a get_analog_value... too quickly either?

but does anyone know - is the fast code loop timed by some event (the get or put data maybe?)

and is its period consistant?

BTW - if you are looking at timing be sure to comment out all your printf statements - there seems to be a whole library of code behind them, I think they will make a drastic reduction in your loop speed.

Re: sleep()
 

I can say from experience that the printf libraries do make a difference. All the "horror" stories my SICP instructor told me a couple of years ago about debug statements causing or removing bugs (the act of observing disturbs the observed?) have come true. Using the timing interrupts and for our auton code (on the EduBot at least), I've come across situations where putting a printf statement causes problems .. and then where it removes them. Needless to say, it was a pain figuring out that the printf statement caused it -- luckily my old teacher had warned me, or I wouldn't have even thunk it.

Re: sleep()
 

Bugs like those are colloquially known as "Heisenbugs", after Heisenberg's Uncertainty Principle, which states that observing something will alter that which you are trying to observe. They're ever-so-fun to track down.

Re: sleep()
 

putting debug statements in code is a significant change to its content.

HW guys have it even worse - Every HW engineer I know can tell you about some circuit they worked on that they were testing with a scope, and as long as the scope was connected, the circuit worked, but when you remove the probe it stopped working

all due to the slight capacitance of the probe altering the circuit they were trying to see.

Re: sleep()
 

Thanks, but I got the idea from someone on this forum.


That took me a little time to figure out. The fast code (Process_Data_From_Local_IO()) is called every loop of the while(1) loop. The "slow" user code is called in addition very occasionally in the while(1) loop when new data is ready (if (statusflag.NEW_SPI_DATA) ).

I did that, too, at the time, just to see. I didn't measure the rate, but it looked like hundreds of times for each call of Process_Data_From_Local_IO(). An easier, non-scope way would be to run a counter in the main while( 1 ) loop, then print it and reset it just before calling Process_Data_From_Local_IO().

...I was doing integer division in a few places in my joystick calculations and I was worried that my code was too slow, but was relieved to see that it runs in only 4 ms. Whew!

Re: sleep()
 

Don't worry - for the most part, integer division is just fine. It's only when you get into floating-point numbers that math operations start to kill you.