I was wandering how to store and represent the programs for the BigTrak. I wanted to stick to the original spirit of the toy and make it programmable via the web so I naturally got to thinking of LOGO commands. Most of my experience with the language was in a program called "WinLogo" ironically running on an Acorn Archimedes not Windows at all.
The interpreter is written from scratch in Python. The interpreter is implemented as a class, the
__init__() routine takes the code as a string argument and sets up the interpreter and splits the code into "words", that is any non-white space characters separated by white space, comments are stripped first. The code is then stored as a list of lists, each list is the content of one line. The line and word variables are set up to point at the first word on the first line. Finally a dictionary is constructed that lists all the command words understood by the system and which function knows how to deal with them. This allows only one function to be written for handling "FORWARD" but also to handle the abbreviated "FD". The "run" method interprets the current word, skipping blank lines and calling the appropriate handler function which has to move the word and line pointers on as many parameters as it takes e.g. handling "FD 5" would move the word pointer on two steps so it points at the next word to be interpreted as an instruction. The file has been written so it can be used as a library so the main code only runs if it is called standalone. If it is called on its own it expects to receive a filename for a LOGO program as it's single command line parameter, reads this and passes the content to a new interpreter and then runs it.
All the hardware aspects have been abstracted, in the initialisation an "output" object is set up from an external Python library which has blocking calls for the supported commands. This means you could hook it up with PyGame and have it draw on the screen for example. The hardware interface for the BigTrak is another class which carries out all the I/O initialisation needed and sends a "sync" character to the ChipKit to clear the serial buffer of any rubbish. Check out my article on Hardware Interfacing the BeagleBone to get an idea of how all the I/O ports and serial port were set up. Most of the command functions just use the Python serial library to send commands to the ChipKit with a couple of scaling factors defined at the beginning to sort out the amount of steps to move each motor for a given number of degrees etc. The wait_ready routine monitors the "Busy" line from the ChipKit to see when it's done. The fire routine flashes the "laser" at the front of the rover on and off for 10 seconds using a single I/O pin and the Python time.sleep() routine.
Note: If you get the latest image (9-Apr-2012) opkg update; opkg install python-pyserial is sufficient no need to compile anything! The only difficult bit with all this was getting the Python Serial library running on the BeagleBone as it isn't in the opkg repository. Building from source is fairly easy however:
opkg update opkg install python-distutils opkg install python-devel wget http://pypi.python.org/packages/source/p/pyserial/pyserial-2.6.tar.gz#md5=cde799970b7c1ce1f7d6e9ceebe64c98 mv pyserial-2.6.tar.gz#md5=cde799970b7c1ce1f7d6e9ceebe64c98 pyserial-2.6.tar.gz tar xvzf pyserial-2.6.tar.gz cd pyserial-2.6/ python setup.py build python setup.py install
It's going to give an error about py_compile being missing when you install it but it doesn't matter, py_compile is meant to pre-compile it to Python byte code to save the load time the first time you run it but it doesn't take long to compile at run-time on this module anyway.
|Python Logo Interpreter||Aug. 26, 2014, 10:21 p.m.||1.6 KB|