91.548 Robots
Assignment
Paper
Lab No. 5
Due Date: Feb. 27, 2003
Course: 91.548 Robots 2003 Spring
Student: Jianping Zhou
Instructor: Prof. Fred Martin
Experiments: LogoChip Bus Communications
Description: For these experiments, my strategy is to use single byte communication sentence protocol. In this protocol, the command word contains 2 bits for device class ID, 2 bits for device ID, 4 bits for data. Therefore this protocol supports only 4 kinds, each with maximum four pieces, devices, as well as limited 16 differentiating data messages. This concise protocol presents less traffic on data bus in favor of faster communication though its limited capabilities. In most cricket application cases, this tradeoff is fairly justified because the slower processing speed of cricket.
To explore issues of Cricket and LogoChip Bus Communications, I also made some comments in this report. Some comments are verified through experiments
Experiment 1: Cricket compliable output bus device
The fancy device is a 9 LEDs matrix, which is compliable with Handy Cricket bus communication usage, including the connect jack and software driver specification.
The driver here is a simple procedure, once the procedure is added to cricket program, it can be used anywhere without limitation.
The fancy can display several blinking pattern in indicated speed. The call function is as this:
fancy class
device inter pattern dr
Parameters:
class --- device class ID, defined as 1 for this device
device --- device ID. It can be decided by user and embedded in the device with the effective
value 1 ~ 4, here defined as 1 for this experiment
pattern --- number 1 ~ 4, corresponding to how the LED blink respectively; Any input number will be cast to 1 if less than 1, or 4 if greater than 4.
inter – option of fast or slow blink represented by 0 or 1; Any input number will be cast to 0 if less than 0, or 1 if greater than 1.
dr – sequential direction of blink represented by 0 or 1, indicating rotation in clockwise or counterclockwise, shift from up to down or down to up, or from left to right or right to left. Any input number will be cast to 0 if less than 0, or 1 if greater than 1.
The fancy device is a non-interruptible and non-queued. The non-interruptible means the device cannot be interrupted once starting. The non-queued means any new request will be ignored during the device is running, no task will be queued. We could implement to make it interruptible and quecible in order to meet commercial requirement, but not at this time.
The interface driver, which is added to user application module (in either the cricket program or logochip program)
global [data]
to fancy :class :device :inter :pattern :dir
ifelse :dir > 0 [setdata 1] [setdata 0]
ifelse :pattern > 3 [setdata 6 + data]
[ifelse :pattern > 2 [setdata 4 + data]
[if :pattern > 1 [setdata 2 + data]]]
if :inter > 0 [setdata 8 + data]
ifelse :device > 3 [setdata 48 + data]
[ifelse :device > 2 [setdata 32 + data]
[if :device > 1 [setdata 16 + data]]]
ifelse :class > 3 [setdata 192 + data]
[ifelse :class > 2 [setdata 128 + data]
[if :class > 1 [setdata 64 + data]]]
bsend $100 + data
end
The device driver, which runs on the logochip of fancy bus device
constants
[[porta 5][portb 6][porta-ddr $85][portb-ddr $86]]
global [class device data pattern inter dr]
to reset
write porta 0
clearbit 4 portb
clearbit 5 portb
clearbit 6 portb
clearbit 7 portb
end
; shift led rows, up to down if dr 1, down to up otherwise
to pattern1 :inter :dr
reset
ifelse :dr > 0
[setbit 2 porta setbit 5 porta setbit 7 portb]
[setbit 0 porta setbit 3 porta setbit 5 portb]
wait :inter
reset
setbit 1 porta setbit 4 portb setbit 6 portb
wait :inter
reset
ifelse :dr > 0
[setbit 0 porta setbit 3 porta setbit 5 portb]
[setbit 2 porta setbit 5 porta setbit 7 portb]
wait :inter
end
; shift led columns, left to right if dr 1, right to down otherwise
to pattern2 :inter :dr
reset
ifelse :dr > 0
[setbit 2 porta setbit 1 porta setbit 0 porta]
[setbit 7 portb setbit 6 portb setbit 5 portb]
wait :inter
reset
setbit 5 porta
setbit 4 portb
setbit 3 porta
wait :inter
reset
ifelse :dr > 0
[setbit 7 portb setbit 6 portb setbit 5 portb]
[setbit 2 porta setbit 1 porta setbit 0 porta]
wait :inter
end
:spin rotate, clockwise if dr 1, counterclockwise otherwise
to pattern3 :inter :dr
reset
ifelse :dr > 0
[setbit 2 porta setbit 4 portb setbit 5 portb]
[setbit 1 porta setbit 4 portb setbit 6 portb]
wait :inter
reset
ifelse :dr > 0
[setbit 5 porta setbit 4 portb setbit 3 porta]
[setbit 7 portb setbit 4 portb setbit 0 porta]
wait :inter
reset
ifelse :dr > 0
[setbit 7 portb setbit 4 portb setbit 0 porta]
[setbit 5 porta setbit 4 portb setbit 3 porta]
wait :inter
reset
ifelse :dr > 0
[setbit 1 porta setbit 4 portb setbit 6 portb]
[setbit 2 porta setbit 4 portb setbit 5 portb]
wait :inter
end
:crawl rotate, clockwise if dr 1, counterclockwise otherwise
to pattern4 :inter :dr
reset
ifelse :dr > 0
[setbit 2 porta setbit 5 porta]
[setbit 1 porta setbit 2 porta]
wait :inter
reset
ifelse :dr > 0
[setbit 5 porta setbit 7 portb]
[setbit 0 porta setbit 1 porta]
wait :inter
reset
ifelse :dr > 0
[setbit 7 portb setbit 6 portb]
[setbit 3 porta setbit 0 porta]
wait :inter
reset
ifelse :dr > 0
[setbit 6 portb setbit 5 portb]
[setbit 5 portb setbit 3 porta]
wait :inter
reset
ifelse :dr > 0
[setbit 5 portb setbit 3 porta]
[setbit 6 portb setbit 5 portb]
wait :inter
reset
ifelse :dr > 0
[setbit 3 porta setbit 0 porta]
[setbit 7 portb setbit 6 portb]
wait :inter
reset
ifelse :dr > 0
[setbit 0 porta setbit 1 porta]
[setbit 5 porta setbit 7 portb]
wait :inter
reset
ifelse :dr > 0
[setbit 1 porta setbit 2 porta]
[setbit 2 porta setbit 5 porta]
wait :inter
end
to slave
waituntil [newbus?]
setdata brcv
if not leftshift data -4 = (class * 4 + device + 11) [stop] ;16 + ((class - 1) * 4) + (device - 1) [stop]
ifelse leftshift (leftshift data 12) -15 = 0 [setinter 2] [setinter 4]
setpattern leftshift (leftshift data 13) -14
setdr leftshift (leftshift data 15) -15
;during following loop, we don’t set checking interrupt coming ;from master, we could do it here, also may have other ;strategies
ifelse pattern = 0 [pattern1 inter dr]
[ifelse pattern = 1 [pattern2 inter dr]
[ifelse pattern = 2 [pattern3 inter dr]
[pattern4 inter dr]]]
end
to go
setclass 1
setdevice 1
write $9f 6 ;make sure a port as output
write porta-ddr 0 ;set output port
clearbit 4 portb-ddr
clearbit 5 portb-ddr
clearbit 6 portb-ddr
clearbit 7 portb-ddr
reset
loop [slave]
end
The schematic is showed on the upper part of the lab wiring diagram.
Following codes are used to test the device from cricket:
to go
loop [
fancy 1 1 1 1 0
wait 15
fancy 1 1 0 1 1
wait 15
fancy 1 1 0 2 0
wait 15
fancy 1 1 2 2 1
wait 15
fancy 1 1 1 3 0
wait 20
fancy 1 1 0 3 0
wait 20
fancy 1 1 0 4 1
wait 35
fancy 1 1 4 4 0
wait 35]
end
Experiment 2: Cricket compliable input bus device
The light sensor captures the photocell analogical signal, and converts it to digital value through using logochip port A0 conversion capability, then mapping this value to be within 255. The output is sent on bus in response of request from master.
Sampling light sensor datum is through calling the lightdata interface function:
lightdata class device
Parameters:
class --- device class ID, defined as 2 for this device
device --- device ID. It can be decided by user and embedded in the device with the effective
value 1 ~ 4, here defined as 2 for this experiment
interface driver
to lightdata :class :device
output bsr 176 + (:class * 64) + (:device*16)
end
Device driver
global [class device]
to slave
waituntil [newbus?]
if brcv = (176 + (class * 64) + (device*16) ) ; 256 + (class-1) * 64 + (device –1) * 16)
[bsend (read-ad 0 - 260 * 9 % 256)] ; mapping sensing value to be within 255
end
to go
setclass 2
setdevice 2
loop [slave]
end
Using the command to test this device from cricket.
loop[send lightdata 2 2]
For the schematic of this device, see the lower part of lab diagram.
Experiment 3: Integrated system
Add both above fancy and lightdata devices to bus port 1 and 2 of cricket, and see how the system interacts.
Once starting those two devices, and running following codes in the Cricket, we will see the fancy device blink fantastically when we move our hand over the photocell or change the light illumination.
global [data test]
to fancy :class :device :inter :pattern :dir
ifelse :dir > 0 [setdata 1] [setdata 0]
ifelse :pattern > 3 [setdata 6 + data]
[ifelse :pattern > 2 [setdata 4 + data]
[if :pattern > 1 [setdata 2 + data]]]
if :inter > 0 [setdata 8 + data]
ifelse :device > 3 [setdata 48 + data]
[ifelse :device > 2 [setdata 32 + data]
[if :device > 1 [setdata 16 + data]]]
ifelse :class > 3 [setdata 192 + data]
[ifelse :class > 2 [setdata 128 + data]
[if :class > 1 [setdata 64 + data]]]
bsend $100 + data
end
to lightdata :class :device
output bsr (239 + (:class * 16) + :device )
end
to go
loop
[ settest lightdata 2 2
ifelse test > 250 [fancy 1 1 1 1 0]
[ifelse test > 200 [fancy 1 1 0 1 1]
[ifelse test > 180 [fancy 1 1 0 2 0]
[ifelse test > 120 [fancy 1 1 2 2 1]
[ifelse test > 60 [fancy 1 1 1 3 0 ]
[ifelse test > 30 [fancy 1 1 0 3 0]
[ifelse test > 5 [fancy 1 1 0 4 1]
[fancy 1 1 4 4 0]]]]]]]
]
end
Comment for the structure of master and slave
The rule of dedicated single master and slaves is to accomplish the simpler, safer and faster bus communication protocol. Complying with this rule, slaves should not communicate each other or send request to master using command word, which is implemented by limiting the sending data of slave to be less than 256. This strategy avoids the data conflict on the bus. However one kind data conflict could happen when more than one input devices, or sensors, have same class ID and device ID. This is user’s responsibility to avoid this situation.
Comment for the role of Cricket
The cricket doesn’t have the ability to waiting for a bus data. Its reading data only occurs as it sends a request and read the bus in ¼ seconds time later through the command bsr. So it must act as master. (Even we could force Cricket to be a slave and try to catch a request by implement a bsr loop in its background, but this will be miserable to control the program). In a pure logochips system, the roles of master and slave can switch; this needs an overhead to implement this in the protocol
Comment for background thread
Logochips use a system level background thread, which is automatically initiated when logochip is powered and exists for ever, to listen to the bus. If a new bus data appears, the bus flag and receiver buffer will be filled up. This thread is different from VM level background, which is initiated using when primitive. So we won’t use when or whenoff primitives to interfere with or terminate the system level listening thread.
Comment for the single sentence protocol used in this experiment:
To resolve the problem of limited available device class ID, we may change the policy of assigning a kind device unique class ID. Instead we give user more options to select class id by setting jumper in the same way as selecting device id on . As to the reduction to the 4 data bits in a sentence, we have to send multiple sentences to transmit a data with more than 4 bits in a fashion of sequential bit transmission, for example if we need transmit a 8 bits data, we have to use at least 4 sentences.