Advertisement
Buffering Commands
In the prior section, we saw how commands can be chained in immediate execution mode, and how a
call to Ready must be performed after some of them. Here we shall see how to eliminate these
extraneous calls by buffering a whole sequence of commands. When this is done, one call to Ready has
to be performed after the commands are executed (regardless of which commands were buffered). But
that's it: just a single call to Ready.
The buffering commands are as follows:
The command "<" can only be executed in immediate mode, and it puts the TSL1401R driver in buffered
mode. Commands entered after that are buffered in the driver's memory, beginning at location RESULTS
+ 5, but are not executed. When the command ">" is encountered, it is buffered, too, and execution
begins from the beginning of the buffer. Each buffered command is executed in turn until the ">" is
reached. Because commands are buffered in what will become the results area of memory, they are likely
to get clobbered as results get appended there. However, execution will always be at least one step
ahead of the results, so the only commands that get clobbered will be ones that have already executed.
Here are some additional important points:
When "<" is sent in immediate mode, and when ">" is encountered when executing from the
•
buffer, the internal results pointer is reset to RESULTS ($20). That means further results will
be appended to the buffer beginning at that point.
Do not buffer the ACQGRAY, DUMPID, DUMPFLAGS, or DUMPADR; and do not buffer more
•
than eleven bytes, including the ">". Doing so will raise an error condition, and you will need to
run the error recovery procedure outlined above, or else reload your program.
Since nothing gets executed until the ">" is received, you can send everything up to that point
•
but defer sending the ">" until the time is right to begin execution.
Now, let's see how to rewrite our code from the previous example to use buffering:
lft_edge VAR Byte
rgt_edge VAR Byte
OWOUT owio, 0, [SETEXP, 60, SETBIN, 100, 3, 0, ACQBIN]
GOSUB Ready
OWOUT owio, 0, ["<", FNDNEW|FWD|DRKEDG, 32, 64] '__ Buffered commands.
OWOUT owio, 0, [FNDNXT|BKWD|DRKEDG, ">"]
GOSUB Ready
OWOUT owio, 0, [DUMPADR, RESULTS]
OWIN owio, 2, [lft_edge, rgt_edge]
IF (rgt_edge) THEN
DEBUG "Bagel found with diameter ", DEC rgt_edge - lft_edge + 1
ELSE
DEBUG "No bagel found."
ENDIF
By buffering the finds, we eliminate one call to Ready, since the driver firmware waits until
buffered commands have executed before signaling that it is no longer busy. Notice, too, that we now
have to read our results from address RESULTS, instead of RESULTS + 5. This is because the "<"
reset the results pointer back to that point after the ACQBIN executed. How many bytes did we actually
buffer, anyway? In the first line, there are three: the "<" doesn't get buffered. In the second line there
© Bueno Systems, Inc. • TSL1401-DB (2009.10.01)
"<", commands, being, buffered, ">"
'
all
the
Page 39 of 52
Advertisement
