[squeak-dev] Delay time question

> Robert F. Scheer wrote:
> > Picture 5 serial lines.  Each has a packet of a few to a few dozen bytes
> > arriving every 20ms although they are not synchronous.  The data arrives
> > on time within a few microseconds every cycle and it must be captured.  
> >
> > I was trying to use delays of around 15ms to prevent the Squeak i/o
> > processes from continuously tying up compute cycles trying to read the
> > serial lines when no data was expected.  Read a packet, delay 15ms, then
> > go into a tighter loop trying every 1ms until the packet was read.  
> >
> > Now, I know this is a bad scheme.  Even a 1ms programmed delay could
> > become longer than 20ms sometimes.  So let's get rid of all programmed
> > delays inside the serial i/o loops.  
>
> Ah. Now we are talking. What you want is the ability for a serial port
> to issue an interrupt / signal a semaphore so that your waiting process
> gets woken up when something happens. The way to do this is by fixing
> the (very, very naive) serial port primitives to add something that
> allows you to signal a semaphore upon data availability. There are
> examples for this kind of thing in other plugins (like the socket or
> async file plugin).
>
> Also, I vaguely remember that John had built a better serial port plugin
> (don't remember where I saw this but I'm sure he'll chime in) which may
> very well support this out of the box.
>
> > I probably don't understand the primitive serial methods well enough.
> > They seem not to block while awaiting input so that requires
> > continuously looping to read.  Is there a blocking method?
>
> There isn't. Since Squeak doesn't use native threads internally (instead
> it uses so-called "green threads") a blocking read would block the
> entire VM and completely defeat the purpose of a blocking read. That's
> why all such primitives are designed to simply signal a semaphore so
> that the process in squeak just sits there doing something like:
>
>    dataArrived := Semaphore new.
>    self registerSemaphoreForSignallingData: dataArrived.
>    [true] whileTrue:[
>       dataArrived wait.
>       self processData.
>    ].
>
> etc.
>
> Cheers,
>    - Andreas
>
>

> Robert F. Scheer wrote:
> > I forgot to be very clear about this in the last post, there is one main
> > reason why C would have no trouble keeping these loops all serviced.
> >
> > The reads would block.  While waiting for the first byte of a packet to
> > come in for the next cycle, no processing cycles would be consumed.  No
> > delays inside loops would be needed.  
>
> I see. Well, if you'd be willing to throw a couple of native threads at
> the problem to service these lines, you could deal with the problem
> easily simply by writing the blocking read in C and have that (once it
> reads the data) signal a semaphore in Squeak which makes the associated
> Squeak process wake up and retrieve and process the data you just read.
>
> Cheers,
>    - Andreas
>
>

> John M McIntosh wrote:
>> I can't speak for Windows works but the magic on unix systems  
>> happens in ioRelinquishProcessorForMicroseconds
>
> But none of it contradicts what I said earlier - if platformSleep  
> uses the system's default timer (which it should) then the accuracy  
> of C code will be no better than the accuracy of Squeak. And if it  
> doesn't, well then the code is broken and you should fix it. It sure  
> as hell works on Windows (perhaps I can shame you into fixing it? ;-)
>
> Cheers,
>  - Andreas

>
> On Thu, 2008-02-28 at 00:18 -0800, Andreas Raab wrote:
> > Robert F. Scheer wrote:
> >
> > > I probably don't understand the primitive serial methods well enough.
> > > They seem not to block while awaiting input so that requires
> > > continuously looping to read.  Is there a blocking method?
> >
> > There isn't. Since Squeak doesn't use native threads internally (instead
> > it uses so-called "green threads") a blocking read would block the
> > entire VM and completely defeat the purpose of a blocking read. That's
> > why all such primitives are designed to simply signal a semaphore so
> > that the process in squeak just sits there doing something like:
> >
> >    dataArrived := Semaphore new.
> >    self registerSemaphoreForSignallingData: dataArrived.
> >    [true] whileTrue:[
> >       dataArrived wait.
> >       self processData.
> >    ].
>
> Yes, that's what I need.  Unfortunately being a Squeak newbie and having
> one month till competition, this looks like an insurmountable gap to me
> atm.  But if it existed, I'd be in heaven.

> I am not sure why your architecture has to change dramatically as a  
> result. If your main problem is to make sure that that a loop is  
> done every 20msecs and you need to adjust for statistical delay  
> variations, you can simply compute the actual time the wait took and  
> do something like:
>
> nextDesiredTick := Time millisecondClockValue + 20.
> [true] whileTrue:[
>   self doControl.
>   "note: for very, very long doControl the waitTime could be negative.
>    you have to decide whether it's better to skip or to run an extra
>    doControl in this case."
>   waitTime := nextDesiredTick - Time millisecondClockValue.
>   (Delay forMilliseconds: waitTime) wait.
>   "Next desired tick is twenty msecs from last one"
>   nextDesiredTick := nextDesiredTick + 20.
> ].

> On Thu, 28 Feb 2008 02:00:38 -0800, "Robert F. Scheer"
> <[hidden email]> wrote:
>
>> I can do it this way, sure.  Just have to figure out how to do the
>> signalling and interprocess communication.  Would you use sockets for
>> the ipc?
>
> 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

> 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
>

> Hi--
>
>       For what it's worth, the Center for Contemporary Research in Music
> and Acoustics at Stanford University (CCRMA) offers packages to make
> RedHat and Fedora Core Linux suitable for very-low-latency multimedia
> use[1]. I've seen demos of it and it works.
>
>
> -C
>
> [1] http://ccrma.stanford.edu/planetccrma/software

> On Thu, 2008-02-28 at 12:59 -0800, Craig Latta wrote:
> > Hi--
> >
> >       For what it's worth, the Center for Contemporary Research in Music
> > and Acoustics at Stanford University (CCRMA) offers packages to make
> > RedHat and Fedora Core Linux suitable for very-low-latency multimedia
> > use[1]. I've seen demos of it and it works.
> >
> >
> > -C
> >
> > [1] http://ccrma.stanford.edu/planetccrma/software
>
> And also for Ubuntu there's:
>
> sudo apt-get install linux-rt
>
> which I'm testing today.
>
> - Robert
>
>
>

> On Feb 28, 2008, at 20:26 , Robert F. Scheer wrote:
> > 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.
>
> Well, I had satisfactory results reading from a pipe using AsyncFile  
> (had to add a utility method though):
>
> http://tinlizzie.org/updates/olpc/updates/0995sugar-bf.cs
>
> In this code, #readChar blocks until data is actually available - it  
> might work to just open /dev/tty... and start reading in a process,  
> similar to what I did in #fetchCommandsFrom:.
>
> - Bert -
>
>
>

> On Thu, Feb 28, 2008 at 09:11:28PM -0800, Robert F. Scheer wrote:
> >
> > This is tantalizingly close to working.  I can open, close and write
> > something to serial ports as pipes with the AsyncFile methods but can't
> > successfully read.  As Jon Hylands pointed out, it's probably because
> > they have no ability to negotiate baud rates and other minor serial port
> > stuff.  
>
> I assume that you are familiar with the unix "stty" command for setting
> serial port parameters, but I'll mention it just in case.
>
> Dave
>
>

> On Thu, Feb 28, 2008 at 09:11:28PM -0800, Robert F. Scheer wrote:
> >
> > This is tantalizingly close to working.  I can open, close and write
> > something to serial ports as pipes with the AsyncFile methods but can't
> > successfully read.  As Jon Hylands pointed out, it's probably because
> > they have no ability to negotiate baud rates and other minor serial port
> > stuff.  
>
> I assume that you are familiar with the unix "stty" command for setting
> serial port parameters, but I'll mention it just in case.
>
> Dave
>
>
>