next up previous contents
Next: Motors and Sensors Up: Robot-computer Interface Previous: Workstation's Role

Problems

There were a series of problems all along the project. First the port /dev/ttya was not configured, and later it was configured to be a terminal. A terminal is configured by default to be echoing, carriage return line feed mapped together and a cooked mode ie. lines of input are collected and input editing is done, and the edited line is available when it is completed by a newline. Without knowing this default mode, I had the protocol set up such that the chip sends some data and waits for the workstation to send back some data. But instead the chip would read the data it had just sent which got echoed back from the port. Also the workstation wouldn't read any data since it did not receive a carriage return. Later with a carriage return- line feed inserted with each data, the workstation was reading the data OK, but the input and output data was being processed for parity and the 8th bit was masked, so the range of data in the communication was now reduced to 0x00 to 0x7F. The in step protocol had no meaning at all and the communication would just lock up. After I had the configuration set up properly, the communication worked correctly.

Also a different cable had to be used for communication with the workstation. I had the communication tested with a PC, but then it wouldn't work on the workstation, because it needed some extra jumpers on the connector. DSL helped me out with the right cables. Testing with the dumb terminal t10 caused some problems because it also did parity checking and masking and I was checking to see if output processing was being done by the workstation or not.

Though the communication on the sun works perfect, the read operations from the sensors through the chip take up a lot of time. After running a lot of tests on the communication, like reading and writing different number of bytes from and to the chip, we figured out that most of the time was being used up in the OS during the read operations. Though we couldn't find out what exactly was going on in the kernel that was causing the delay (we couldn't find any documentation on it), we guessed that there was a read buffer that was being filled up each time a byte is sent by the chip, but the buffer is not available in user space for the program to read it until the buffer contains a certain number of bytes, or a certain time-out value has expired. But we had no way of either proving it or changing it.

So we moved from hayduke (Sparc 10) to kahlua (HP - 730), because we were assured of some low level hacking by Mike Hibler of CSS, to see what the problem was, and correct it, if it persists. On running the program a few times on the HP, Mike figured out that it was a buffer timeout value problem on an HP, and found that the default value was set to 14 characters. So he changed the timeout to one character, and rebooted the machine. He also mentioned that usually this timeout value cannot be changed by a normal user. So once this change was done, the 10,000 loop program with 2 reads and 1 write per loop ran in 30 seconds, which is around the optimum speed that can be attained at 9600 baud rate. To get a higher update rate , we have to use 19200 or 38400 baud rate.

But the EVBU uses a crystal of 8-MHz frequency. With this frequency, the maximum attainable useful baud rate is 9600. To get 19.2K or 38.4K, we will have to replace the crystal by a different crystal. But with a 10-MHz crystal, the system E-clock rate increases to 2.5-MHz which might cause problems since the part has been tested only for 2.0MHz. Another option is to go to a lower frequency crystal (4.9152 MHz) which also gives the standard baud rate options, but this slows down the internal clock and hence execution of the instructions, and the A/D conversions. Also the PCBUG11 and the BUFFALO monitor programs have been written for 8MHz crystal frequency, and they have to be modified for any other crystal. But after Mohammed simplified the control program to normal linear control, the communication speed on the SUN was sufficient for control of the 3 links.


next up previous contents
Next: Motors and Sensors Up: Robot-computer Interface Previous: Workstation's Role

Matanya Elchanani
Wed Dec 18 17:00:21 EST 1996