Semestral assignment

Documentation:

• Documentation How to Work with MicroZed APO
• MicroZed APO Documentation
• MZAPO connection cookbook
• MZ_APO datasheet in English PDF

• The deadline to submit selected task specification is May 2 2021 (submit to semassign in BRUTE)
• The submission of the task is possible up to one week after the assessment week, i.e. until Friday, May 30 2021
• For each additional week started, the penalty is -10 points.

• The task is intended for pairs of students without distinction for the study program OI and KyR and or language varinat, but it can also be solved independently.
• Upload the source codes in the archive (zip) to https://cw.felk.cvut.cz/brute/ (SEMCODE task)
• Documentation (user manual and technical report) in the archive to SEMDOC on Brute.

To submit, it is necessary to establish a team and this will also apply to individuals. Team building is set up to allow you to work in pairs.

Due to the transition to the distance form, the final solution is in negotiations and also depends on the opinions of students. Most of the requirements are and will be chosen so that it is possible to debug the work on the QtMips simulator and also submit it in a version only for QtMips (with a slightly lower rating or the same as on real HW, this is still open).

Limit conditions that are already given.

• Output on RGB diodes and LED line (support for QtMips and MZ_APO, can be easily checked with a camera, MANDATORY)
• Text output to graphic display / frame-buffer (support for QtMips and MZ_APO, camera does not provide way to fine check the result, big font has to be chosen, same for graphic, MANDATORY)
• Output to serial port or standard output - rather only for debugging (support for both, QtMips and MZ_APO)
• Rotary knob input, mandatory when submitting for QtMips, physical interaction/tuning is not possible for MZ_APO, so it doesn't make much sense
• Audio output, CAN communication, TCP / IP, etc. na available on MZ_APO, but rather too demanding, possible in individual assignments
• DC motor control, a good replacement for the incremental input of rotary selectors (IRC), where voltage control can be used to mechanically rotate the motor and set IRC (so far only support on MZ_APO, but I am considering programming the display and dynamics of the DC motor to QtMips)

Inspiration and examples for assignments

• classic game of snakes (see Wikipedia EN, CZ) - QtMips or MZ_APO (here in the distance form two snakes with artificial “intelligence” in demo mode plus mode to control at least one character via SSH), in the standard variant two snakes, the direction of one head controlled by red selector and the characters 'a' and 's' in the serial port input, the second head with the blue selector and the characters 'k' and 'l'. The length of the snake and the time will be displayed in the form of a text (label + number), the left and right RGB LED informs about the good condition of the respective first and second snake, green, swallow blue and impact resulting in death and stopping by red. For the full number of points and a graphical menu with a choice of parameters - speed, etc.
• magnifying glass (xmag − magnify parts of the screen) - the display shows longer text on several lines (ideally entered from a file, even QtMips provides open, read, write,… syscalls, although without modifying the C library it will probably be necessary to call them manually), two knobs will set the position of the window on the screen, the content of which will be enlarged, either above the selected place or at a fixed position, on MZ_APO in the case of a distance form, the selected position will gradually move line by line from top to bottom so that the text is at least a little legible, LEDs will be for example, to indicate the transition between the lines, in the case of an optional magnification factor, for example, the degree of magnification
• electronic version of Etch A Sketch - for distance form only for QtMips, mandatory textusl display of position and selected colors, choice of color from the menu, selected color on one of the RGB LEDs.
• management and monitoring of the production line
• robot drive control etc…
• own ideas welcome.

• registering team and submitting work specification (1 point at BRUTE semassign)
• basic functions to access and use peripherals, at least three different peripherals (3 points)
  • use RGB LEDs for application output
  • use 32 LED line for some state visualization
  • output to serial port
  • read from rotary dials knobs
  • standard input (for example via SSH) without waiting to confirm of whole line by enter (raw input)
  • read DC motor position and PWM control for DC motor extension kit
  • processing of external events in interrupt service handler (applicable for QtMips only)
  • system-call implementation (interrupt or exception service)
• text output to graphics LCD display/frame-buffer
  • draw text with provided font (1 point)
  • text output with proportional character width font and use of at least two fonts (1 point)
  • line graphics or some other graphics visualization (1 bod)
• application implements functional application logic according to the specification (5 point)
• quality of work, conformance to good coding practice rules (5 bodů)
  • consistent indentation
  • a function length should not exceed 20 or 30 lines - “one function has single well defined purpose” and name is descriptive
  • divide application code to multiple files - each C source file should not exceed 150/200 lines
  • select coding style and keep it for all code, inspiration PEP20 a např. Linux kernel coding style
• user interface/logic is ergonomic (3 points)
• documentation - obligatory, undocumented work is considered as void
  • application architecture - block diagram (1 point)
  • traceability, each function and global variable should be described and mapped to individual susbystem (1 point)
  • user manual, it should allow full operation without other party assistance (1 point)
  • description how to build (including dependencies) and start application (1 point)
• whole project development realized under version control system - GIT (voluntarily - awarded by bonus points)
  • the project repository exists, it is not polluted (including history) by generated files (object files, binaries), if the work is proceed in pair, the commit from both parties witness real cooperation (1 bonus point)
  • the commit brief and full description corresponds to the reason/purpose of the change (1 bonus point)
  • each commit should add single feature or fix single problem
  • development done in separated branch (“dev” for example) and before submission there is created merge request on gitlab (or github). Merge request is for integration of development/final project into “master” branch and is assigned to the teacher to allow efficient comment of the work. (1 bonus point)