View Single Post
  #9   Spotlight this post!  
Unread 02-04-2013, 02:16 AM
NotInControl NotInControl is offline
Controls Engineer
AKA: Kevin
FRC #2168 (Aluminum Falcons)
Team Role: Engineer
 
Join Date: Oct 2011
Rookie Year: 2004
Location: Groton, CT
Posts: 261
NotInControl has a reputation beyond reputeNotInControl has a reputation beyond reputeNotInControl has a reputation beyond reputeNotInControl has a reputation beyond reputeNotInControl has a reputation beyond reputeNotInControl has a reputation beyond reputeNotInControl has a reputation beyond reputeNotInControl has a reputation beyond reputeNotInControl has a reputation beyond reputeNotInControl has a reputation beyond reputeNotInControl has a reputation beyond repute
Re: Configure Timers

Quote:
Originally Posted by Ether View Post
Two questions come to mind:

1) Do you put code in each of your threads to monitor throughput margin and re-entrancy ?


Yes, I do, it is not necessary, but I just do out of habbit for all my embedded projects.

Especially when I run embedded code on an operating system that doesn't guarantee timing, I always put code in in there to monitor the execution of each state.

Unfortunately, the SwawkOS doesn't support :

Code:
System.nanoTime()
so timing is only good to the millisecond from:
Code:
System.currentTimeMillis();
but milli second accuracy is good enough for anything we will need to do in FIRST for sure.

Quote:
Originally Posted by Ether View Post

2) Are there other scheduling options in FRC Java which will provide concurrent processing of same-priority threads ?


When you use the TimeThread task, it doesn't run automatically, you need to create a separate scheduler which runs the task based on the periodicty set.

Something like:

Code:
		
this.executor = new java.util.Timer();
this.executor.schedule(new MyTimedTask(this), 0L, this.period);
There are different types of properties you can set on the scheduler. By default the scheduler doesn't preempt the running thread so lets say you kicked off a TimedTask thread, and then you entered this block of code after:

Code:
while(true)
  system.out.println("Hello World");
running as fast as it could, you would see that your timer task would not run at your set period, it would only get to run, between timesclices of the while loop that the cpu was free for an instance of time.

However, for JavaFRC you can use other properties of the Timer Task to control your concurrancy. For example you could use the scheduleAtFixedRate method of the TimerTask, which i believe does preempt the running thread to try and guarantee execution. (I never tested it however).

The better way to do it in a normal J2ME project would be to set the priority of all of your threads. Using the Thread.setPriority() and Thread.getPriority() functions and the Thread.xxPRIORITY static fields. You can have up to 10 levels of priorities. Where Higher priorities will pre-empt lower ones. However these methods are not supported by Squawk JVM for FRC, and all threads in FRC Java are created with the same NORMAL priority.

The best way to do it JavaFRC would be to avoid the need for preemption and try to ensure your code is optimized and runs in a period that is reasonable so that the CPU can be shared between all normal priority tasks. If all of your JavaFRC threads have relatively small execution times compared to its period, (and they should), then all your threads should have enough access to the CPU to run within its within its periodicity.

Java VM in general is not a real time OS, so timing is never truly guaranteed, no matter what we do. Most of the inconsistencies arise when you have threads that are relying on preemptive behavior, instead of cooperatively giving up CPU time.


Hope that helps,
- Kev
__________________
Controls Engineer, Team 2168 - The Aluminum Falcons
[2016 Season] - World Championship Controls Award, District Controls Award, 3rd BlueBanner
-World Championship- #45 seed in Quals, World Championship Innovation in Controls Award - Curie
-NE Championship- #26 seed in Quals, winner(195,125,2168)
[2015 Season] - NE Championship Controls Award, 2nd Blue Banner
-NE Championship- #26 seed in Quals, NE Championship Innovation in Controls Award
-MA District Event- #17 seed in Quals, Winner(2168,3718,3146)
[2014 Season] - NE Championship Controls Award & Semi-finalists, District Controls Award, Creativity Award, & Finalists
-NE Championship- #36 seed in Quals, SemiFinalist(228,2168,3525), NE Championship Innovation in Controls Award
-RI District Event- #7 seed in Quals, Finalist(1519,2168,5163), Innovation in Controls Award
-Groton District Event- #9 seed in Quals, QuarterFinalist(2168, 125, 5112), Creativity Award
[2013 Season] - WPI Regional Winner - 1st Blue Banner

Last edited by NotInControl : 02-04-2013 at 02:47 AM.
Reply With Quote