On Thu, 2008-02-28 at 06:55 -0500, Jon Hylands wrote:

> The other thing you can try (to do this all in Squeak), which is what I
> normally do, is this:
> 
> - use a higher priority process in Squeak (forkAt: Processor
> userInterruptPriority) to run your serial loop
> 
> 	[
> 		[done] whileFalse: [
> 			data := serialPort readBytes.
> 			(data notNil and: [data notEmpty])
> 				ifTrue: [sharedQueue nextPut: data].
> 			(Delay forMilliseconds: 1) wait]] forkAt: Processor
> userInterruptPriority named: 'Serial-Reader'.
> 
> Later,
> Jon
> 

I tested the higher priority fork against a simple user loop and the
forked loop came out the loser.  

	[
	delay := Delay forMilliseconds: 1.
	bag1 := Bag new.
	1000 timesRepeat:[bag1 add: [delay wait] timeToRun].
	] 
	forkAt: Processor userInterruptPriority
	
	bag1 sortedCounts 
"a SortedCollection(746->1 86->16 69->14 65->15 32->13 1->2 1->22)"

	delay := Delay forMilliseconds: 1.
	bag2 := Bag new.
	1000 timesRepeat:[bag2 add: [delay wait] timeToRun].

	bag2 sortedCounts 
"a SortedCollection(982->1 6->16 5->13 4->14 1->15 1->6 1->7)"
	
I then ran both loops at the same time to see how they'd interact and
got an interesting result.

	delay1 := Delay forMilliseconds: 1.
	bag1 := Bag new.
	delay2 := Delay forMilliseconds: 1.
	bag2 := Bag new.
	[
	1000 timesRepeat:[bag1 add: [delay1 wait] timeToRun].
	] 
	forkAt: Processor userInterruptPriority.
	1000 timesRepeat:[bag2 add: [delay2 wait] timeToRun].

	bag1 sortedCounts "a SortedCollection(914->1 39->16 17->15 14->13
14->14 1->4 1->6)"
	
	bag2 sortedCounts "a SortedCollection(914->1 39->16 17->15 14->13
14->14 1->5 1->6)"

My conclusion is not to use 1ms delays anywhere in the time critical
loops of the robot.  I'm off to look at the interprocess semaphore
methods that David and Andreas have alluded to.  It looks like C serial
handlers are the way to go atm.

Thanks for all the suggestions everyone.

- Robert