Go to Post Dreams come and go, but once life throws a football you have to think fast. - Pavan Dave [more]
Home
Go Back   Chief Delphi > Technical > Programming
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
 
 
Thread Tools Rate Thread Display Modes
Prev Previous Post   Next Post Next
  #15   Spotlight this post!  
Unread 31-03-2004, 02:00
TedP TedP is offline
Registered User
#1014
 
Join Date: Mar 2004
Location: Dublin, OH
Posts: 19
TedP will become famous soon enough
Re: counting in seconds for the autonomous mode??

Quote:
Originally Posted by KenWittlief
hmmmm.... I dont understand TedPs adversion to counting SW loops.

someone has tested the timing of the statusflag.NEW_SPI_DATA event- its controlled by a timer in the communications loop and testing has shown its dead accurate every time, unless you have so much code that it takes more than 26mS seconds to execute.

statusflag.NEW_SPI_DATA will be true 38 times a second - you can even round it off to 40 to make it simpler - I cant imagine anyone needing finer resolution that 1/38th of a second while setting up the sequence of events in auton mode ?
For one, there's no reason your autonomous mode code has to run at the slow rate. Only Getdata() when that flag goes high, and otherwise rattle around as fast as you can. You can Generate_Pwms() as fast as you can as well because those are the FAST PWMs. They can be handled specially. Additionally, Putdata() can be called as fast as you'd like. IFI specifically says that there is no harm done by calling Putdata() too fast; it also says that there's not necessarily anything gained. It's in the documentation.

Having interrupt-controlled timing that is triggered by an interrupt generated by the terminal count of a hardware timer timed fairly precisely to go off every 100th of a second (or even finer) seems much simpler than using a counter to do this timing. Additionally, you can use this counter later on in your competition mode code.

It just seems much cleaner to have an interrupt manage all your timing for you. You can get fairly fine time resolution, and you don't have to worry about making sure you increment in time. Run code as slow as you'd like; the interrupt will jump in when it needs to increment your "clock."

If you do things the more naive way, then you gain a second every twenty seconds, and you lose the ability to differentiate in time among a great number of cycles of your code. That may not be that big of a deal, but it definitely could use some improvement. Using the simple interrupt-driven timing does this. That's all I'm saying.
 


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Future of Autonomous Mode FadyS. Programming 41 24-05-2004 19:45
Simple Autonomous Mode Example deltacoder1020 Programming 5 08-03-2004 20:22
Initializing autonomous mode Mr. Lim Programming 7 02-02-2004 07:26
autonomous mode problem on field Chris_C Programming 17 26-03-2003 19:11
autonomous mode timer Don Programming 6 09-02-2003 22:16


All times are GMT -5. The time now is 07:46.

The Chief Delphi Forums are sponsored by Innovation First International, Inc.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi