Homework 3 CSC , Spring, 2016

Transcription

1 Homework 3 CSC , Spring, 2016 Instructions in previous homeworks also apply to this one. For a coding question that requires coding your BBBK, you also need to be able to demonstrate, upon demand, your code in functioning state in class on or after the due date bring your BBBK and programming platform to class. For example, Q1 below asks you to make observations in your BBBK file system, and answer some questions, then write a program. The answers to the questions should go into the single PDF or text file you submit, together with answers to other questions. The code with build instructions should go into a zip file. Submit the PDF/text and zipfile(s) to the WolfWare locker, and bring the BBBK to class, ready to demonstrate. For all BBBK coding questions, you may use any language you use unless otherwise stated. If you include complete solutions to a question in three or more distinct languages, you get a brownie point for that question. Also note: Unless otherwise stated, any BBBK programming required should be done such that the code independently works on the BBBK, without requiring a browser to be running on a host computer. That is, you can leave the BBBK attached to the host computer, from which you access the BBBK using ssh or the Cloud9 web client to write and trigger the program, but you must trigger it at the BBBK through either of these two means, not from a script executing on a browser on the host computer. For Q4, if you submit an answer, you must also submit a video clip (or link to one) showing it in operation. 1. The USR0 LED by default blinks a heartbeat on the OS image the BBBK comes with that is actually a Linux timing signal. Instead, we want to convert it to a palpitation blink it on and off 10 times a second. A quick search on the BBBK reference sites and other sources turn up commands that should do it: echo 50 > /sys/class/leds/beaglebone:green:usr0/delay_on echo 50 > /sys/class/leds/beaglebone:green:usr0/delay_off (a) Attempt to execute these commands after booting the BBBK without any other intervening steps. What happens? Does the behavior of the LED change? You should get an error message of some sort such as -bash: /sys/class/leds/ beaglebone:green:usr0/delay_on: No such file or directory, since by default the trigger is set to heartbeat, and the delay parameters are only available when the trigger is set to timer (and since these are not really files, you cannot create them simply by writing to them). (b) With a little further research or even guesswork, you can turn up the step you have to take first in order to make the above work. What is it? Verify that once you do it (HINT: it involves setting the trigger for that LED to the appropriate value first), you can control the LED to behave as you want it to. It is to set the trigger to timer, as above; which can be done by echoing the string timer to /sys/class/leds/beaglebone:green:usr0/trigger. (c) In the above example, the LED is configured to turn on for 50 milliseconds and off for another 50 milliseconds, which should result in the LED make a complete blink cycle in 1/10 th of a second. With the aid of an independent timer (like a stopwatch), count the number of blinks you can count in a few seconds, then state whether the number of blinks per second does appear to be approximately 10, or distinctly different. Describe and provide detailed data on your experimental procedure not a simply yes or no.

2 You should provide some information (and preferably data) to show that you either tried it over a longer and longer period until the average stopped changing, or that you tried it many times, or both; any other reasonable methodology to reduce error and remove bias will also be acceptable, but simply I measured it once but I was very careful will not. (d) Write a standalone program that will let you investigate the effect of changing the proportion of on-time and off-time, while keeping the total 100 milliseconds. Describe whether you can visually tell the difference between any set of values. How different do the values have to be for you to be able to discern any visible difference? Depends on your visual acuity, persistence of vision, which are all individual and change with age. Personally I can tell when the on-time changes by as little as 10 ms, but only if I am looking at it while it changes. My ability to detect the change also seems to depend on whether the duty cycle is going up or down. Your answer should indicate that you followed a systematic procedure to find the threshold, and preferably detail the procedure enough so that another experimenter can precisely duplicate it. Extra credit if you realized the difference between looking at it during the changeover and only looking at it before and after the change, and devised some procedure to distinguish it without bias (for example, making your program change it randomly between two sets of values, and then comparing your perceived changes to ground truth). If your actual answer differs very much from the human norm in either direction, you will lose marks because the natural conclusion is that you made a mistake. (e) Extend the program so that it can also be used to investigate the effect of changing the total cycle time, keeping the on-time and off-time equal. Investigate cycle times lower than the 100 milliseconds you started with. Describe whether you can visually tell any difference. How different do the values have to be for you to be able to discern the difference? What value, if any, is the highest frequency at which you can still tell the blinks apart, or count them? Describe and provide detailed data on your experimental procedure. Again, a matter of individual variation; again, any procedure is fine as long as it is reasonable and described in sufficient detail, and any answer is fine as long as it is within normal human capabilities. 2. Develop a standalone program on your BeagleBone Black that, when run, expects a string of numbers to be specified on the command line, and then blinks the usercontrolled LEDs corresponding numbers of times, with short pauses between blinks and long pauses between sets of blinks representing successive numbers. (For example, if the executable is a.out, then executing a.out should result in three blinks separated by short pauses, then a long pause, five blinks, long pause, one blink.) Running the program without any command line arguments or with non-number command line arguments should cause it to print out a usage guide and exit. Your README file should specify what development environment you used, any assumptions or values you adopted (such as lengths of blinks or pauses), directions for compiling and using, and any other pertinent information.

3 3. Develop program(s) that allow you to send packets to servers running on specific hosts, then use them to transmit data as follows. There is one UDP server and one TCP server, both with the same application layer PDU standard, and you must successfully transmit a single application PDU to each of the two. In each case, the server is running on a host with IP address , and is reachable on port The application PDU is described below. In addition, the UDP server expects the entire application PDU to be embedded in a single UDP packet. (Note: The machine on which this server is running has most other network ports blocked by a firewall. Thus ping or other network probes cannot be expected to succeed. Your only way of verifying that the server is up is to send something to it, and received back the response as specified below.) The first four bytes of the application PDU must be the bytes representing the corresponding UNICODE or ANSI characters N, C, S and U. The next nine bytes must be similarly byte encodings of the characters in the string representation of your 9- digit student ID. (Note: They must be the character encodings rather than the actual number. For example, if your student ID is , then the first byte must not have the value 9, but rather the value 57, which is the ANSI encoding for 9.) (Note: These first two fields of the message appear to be like strings, but they are NOT null-terminated. If a null is inserted, it would be misinterpreted by the server as the first byte of the next field.) (Note: Unlike memory data structures or files, once you write a byte into a socket, you cannot go back and take it back or write over it, obviously.) The next four bytes should be your 9-digit student ID expressed as a 4-byte number. Depending on your programming platform of choice, this may be an int, a long, an unsigned long, or some similar data type. However, the server expects to receive the 4 bytes making up this number in the order of most significant byte first. (Note: This ordering of bytes is often called the network byte order, because this is the standard ordering for programs to exchange data. A standard is needed since different platforms vary in how they locally store multi-byte numbers. So called BIG_ENDIAN systems store numbers so that the MSB is in the lowest address, whereas systems that store the LSB in the lowest address space are called LITTLE_ENDIAN. Since transmission typically occurs from the lowest address up think of how strings are transmitted the network byte order corresponds to BIG_ENDIAN. Macros such as ntohs(), htons() etc. provide easy ways for the application programmer to always ensure network byte order without having to know the byte ordering of the platform that the code will be running on read the manual pages of these for details on how to use them.) (Note: sizeof() is a handy function to find out how many bytes make up a particular data type, such as int, on your local platform.) The rest of the application PDU must be a single null-terminated string, with the following information as string in the following format: <Your name>\n<your 9- digit student ID>\n<The dotted decimal representation of the IP address you are sending from>\n<the port number you are sending from>\ncsc \n<Current date and time on your system in mm/dd/yyyy hh:mm format>\n. (The \n indicates the UNIX newline character.) When the server prints it out, it should look like the following: Rudra Dutta

4 CSC /7/ :43 It is also acceptable to have the date format 02/07/2015. (Note: The null termination at the end of this string is the only way the server knows that the APDU is concluded. If you send data to the server that does not so terminate, you can hang the server, or at least the thread servicing you. Please aim to avoid this.) Neither the UDP nor the TCP server will accept an application PDU of more than 1000 bytes from the socket, so your program should ensure this is what the server receives. In each case, the server will send back a string Server received and archived <X> bytes of transmitted data, which your program should receive from the socket, where X is the number of bytes the server read in total. If you receive any other string, or receive nothing, then your transmission did not succeed, and you should re-try, after checking your program for errors. Since servers as well as server programs can have temporary problems, or there may be network problems, a failure does not necessarily indicate a problem in your program. 4. (Extra credit) You may be familiar with air-text a set of LEDs that blink in such a pattern such that when they are pulled through the air, they seem to leave text behind them floating in the air due to persistence of vision. Since there are four user LEDs on the BBBK, it might be possible to use it for air text, though with only four dots in the vertical direction it may not look very good. Develop a standalone program on your BBBK that, when run, expects a string to be specified on the command line, and then blinks the LEDs to produce this string in air-text. It is acceptable to convert all letters to capital case. To enable the user to time the back-and-forth motion, also allow the user to specify as the first argument, in milliseconds, the time that the user wants to perform each of those half-motions. Your program should first produce some countdown blinks to enable the user to start shaking. Then it should alternate showing the air-text for the given number of milliseconds, and keeping all the LEDs dark for the given number of milliseconds, in an infinite loop until interrupted. (For example, if the executable is a.out, then executing a.out 500 bingo should result, after the countdown blinks, the letters in the string bingo (separated by some space) displayed one after the other, completed in half a second, followed by half a second of darkness, and keep alternating. You have to first on a 4xN dot-matrix display of the characters of the alphabet (and the numbers and punctuation, if you want to support those, too). You may adopt one from elsewhere, or make one yourself. In your answer, specify whether you made your own, or cite the source that you adopted them from. N may have any value, and larger N is one way of increasing the resolution of the display. For example, possible 4x5 and 4x7 dot matrix displays of the letter A are shown below. Obviously, making N larger is also a lot more work in designing and implementing the dot matrix.

5 (Note: Since this is a challenge question, you can attempt only part of it if it makes this more tractable to you. For example, you can make it work only for a subset of characters, say only the numerals. Or you can show the airtext one character at a time.)