Task

Connection to the board

1/ Run GtkTerm on your PC

 Configuration -> Port:
 Port:   /dev/ttyUSB0;  Baud rate: 115200; Parity: none;  Stopbit: 1

In GtkTerm window, press enter, if you do not see IP address or restart the board.

  • Login: root
  • Password: mzAPO35

2/ Run terminal command windows on your PC and add the private key into ssh agent by the command:

ssh-add-mzapo-key

or

ssh-add /opt/zynq/ssh-connect/mzapo-root-key

3/ Mount the complete target file system into the /tmp subdirectory of your PC. Supply IP address of the connected board

/opt/zynq/sshfs-mount-target 192.168.202.xxx

4/ Copying files between PC and the board

  • Now, you can use Midnight commander on PC for copying files
  • Alternatively, you can connect via SSH, so you can use SCP to transfer files between the target system and the host PC

ssh -i /opt/zynq/ssh-connect/mzapo-root-key root@192.168.202.xxx

  • Alternatively, you can connect via ssh as user root

ssh root@192.168.202.xxx

The part of the board used in the task

KNOB and LEDs

Before using knobs and led, you must map them into address space.

unsigned char *mem_base;

mem_base = map_phys_address(SPILED_REG_BASE_PHYS, SPILED_REG_SIZE, 0);

if (mem_base == NULL) exit(1);

Reading knobs values

uint32_t rgb_knobs_value;

rgb_knobs_value = *(volatile uint32_t*)(mem_base + SPILED_REG_KNOBS_8BIT_o);

The knobs data are returned as 4 bytes unsigned | buttons | R-knob | G knob | B knob |, i.e., the bits 7 to 0 are blue knob, bits 15 to 8 are green knob, bits 23 to 16 are red knob, bit 24 is blue knob button, 25 is green knob button, and 26 is red knob button. You can unpack then, e.g. by

int rk, gk, bk, rb, gb, bb;

bk =  rgb_knobs_value      & 0xFF; // blue knob position
gk = (rgb_knobs_value>>8)  & 0xFF; // green knob position
rk = (rgb_knobs_value>>16) & 0xFF; // red knob position
bb = (rgb_knobs_value>>24) & 1;    // blue button
gb = (rgb_knobs_value>>25) & 1;    // green button
rb = (rgb_knobs_value>>26) & 1;    // red buttom

32 LEDs are controlled by writing to their port. The next line will light on all LEDs.

*(volatile uint32_t*)(mem_base + SPILED_REG_LED_LINE_o) = 0xFFFFFFFF;

The board contains 2 RGB LEDs with variable colors. The value is 4 bytes | 0-unused | R- | G | B |. The following lines will set the color of the first led to yellow and the second to violet.

*(volatile uint32_t*)(mem_base + SPILED_REG_LED_RGB1_o) = 0x00FFFF00;
*(volatile uint32_t*)(mem_base + SPILED_REG_LED_RGB2_o) = 0x00FF00FF; 

LCD

LCD display has 480 columns and 320 rows. The mapping of LCD ports is perfored by:

unsigned char *parlcd_mem_base;

parlcd_mem_base = map_phys_address(PARLCD_REG_BASE_PHYS, PARLCD_REG_SIZE, 0);

if (parlcd_mem_base == NULL)  exit(1);

The initialization of LCD is required before the first usage of LCD. It should be performed only once time by calling:

parlcd_hx8357_init(parlcd_mem_base);

To begin drawing, move LCD pixel pointer to point 0,0 - top left corner

*(volatile uint16_t*)(parlcd_mem_base + PARLCD_REG_CMD_o) = 0x2c;

Each subsequent write the data port of LCD fills a pointed pixel by color information and then, LCD data pointer is moved to next pixel in the current row. At the end of a row, LCD pixel pointer is moved to the beginning of a next row.

The following command writes black.

*(volatile uint16_t*)(parlcd_mem_base + PARLCD_REG_DATA_o) = 0x0;

A color information for LCD is 16 bit unsigned | 5 bits of Red | 6 bits of Green | 5 bits of Blue |. Thus, BLACK is 0x0, WHITE is 0xFFFF, RED is 0xF800, GREEN is 0x07E0, BLUE is 0x001F

Description of Semester Task - Embedded System with ARM architecture

Possible tasks

  • Distributed lighting control: 2 students.
  • Calculation and display of Julia set: 1 student.

Deadline

  • The assignment will take place in the credit week.
  • For each subsequent week, the student will delay the submission, the rating will be reduced by 5 points.

Distributed lighting control

The task is for 2 student groups for study programs OI and KyR but it can be solved by individuals as well. Design a system to adjust the intensity and color of the lighting in individual household rooms. Each room has a processor unit that controls the intensity and color of the ceiling lighting and wall lighting. Such a solution can serve to achieve maximum comfort and support for the daily regime of the population. In many situations, however, lighting requires manual setting. For this, each unit is equipped with three rotary selectors and a graphical display.

The units are interconnected by a communication network (physical ETHERNET 1Gbps, TCP / IP protocol), and it is possible to send commands to other units and also monitor their presence and status.

UDP is used for communication (unconnected service). All commands and status are sent between ports 55555. Each unit sends its status (broadcast) to the entire local network once times per second, it also tracks this information that was broadcasted by other units, creates the list of all connected units and their statuses.

The user can from a unit select another unit, monitor its status, and change it by sending a UDP command. Units are uniquely identified by their network (IPv4) address. In addition to the address, their send their names (up to 16 characters) and their 16×16 pixel graphic icon. The icon has 16bit color in LCD display format, i.e. the icon has 16*16*2 bytes, total length 512 bytes.

Because network byte order is big-endian, all data are sent in this format.

The format of each Apo Light Control report in 1.0 is the following.

Byte offset Data type Description
0 … 3 uint32_t Control number 'ALC1' = 0x414c4331
4 … 7 uint32_t protocol version 1.0 0x00010000
8 … 11 uint32_t Type of message (0 status, 1 increment value, 2 set value
12 … Date of message

Content of STATUS message type 0

Byte offset Data type Description
0 … 3 uint32_t 'ALC1'
4 … 7 uint32_t 0x00010000
8 … 11 uint32_t 0
12 … 15 uint32_t ceiling RGB
16 … 19 uint32_t walls RGB
20 … 35 16x char name of unit
36 … 547 256x uint16_T graphical symbol of unit

Notes:

  • Ceiling and walls RGB information is sent as 4 byte number, in big-endian order. The 32bit unsigned has 4 bytes | upper byte is unused | R | G | B |.
  • Name of unit has always 16 characters. If the name is shorter, that the end bytes of text are filled by 0.

Content of intensity correction message type 1 and type 2

Byte offset Data type Description
0 … 3 uint32_t 'ALC1'
4 … 7 uint32_t 0x00010000
8 … 11 uint32_t 1 or 2
12 … 13 int16_t R ceiling
14 … 15 int16_t G ceiling
16 … 17 int16_t B ceiling
18 … 19 int16_t R walls
20 … 21 int16_t G walls
22 … 23 int16_t B walls

Notes: Color information is signed integers. In the case of incremental correction, type 1, their values are added to current data of RGB. For type 2 message, the current RGB data are overwritten by a new value. If a new value is negative, there is no change.

Rating of Solution

  • [+2 points] displaying the list of active unit names
  • [+1 point] selecting a unit with a rotary selector
  • [+1 point] for a selected unit, displaying the menu of available commands
  • [+1 points] for the selected unit, incremental setting of lights by sending type 1 message
    • If UDP communication has not been implemented, enter the values ​​on the terminal
  • [+2 points] receiving message (type 1 / type 2) and adjusting your light value
  • [+1 point] sending periodic status message (type 0) with your unit icon
  • [+2 points] dynamic creation of the list of active units
  • [+1 point] in the list of active units (or in the unit menu), displaying the current settings of selected unit
  • Additional features in the submenu of the drive
    • [+1 points] lights off
    • [+2 points] full power (16-color selection)
  • [+1 point] displaying the icons in the list of active units
  • [+1 point] nontrivial unit icon
  • Required documentation. The following points will be assigned only in the case of complete functional solution.
    • [+2 points] for the user guide
    • [+2 points] for technical report]

Alternative Entry: Julia Calculation and Display Set

This task is intended primarily for KyR students who solve similar tasks within the subject B3B36PRG, but even OI students can choose it without restrictions.

KyR students have advantage because they can own the code of the calculation and share it with the semester project from B3B36PRG and gain experience how to implement the code portable between different systems. It reduces the time requirements of the B35APO subject for KyR students according to Credit subsidies.

Implement the Julia set on MZ_APO. (An illustrative example from Karl Sims here: [http://www.karlsims.com/julia.html|Understanding Julia and Mandelbrot Sets].) The output should make the most of the supported color gamut (RGB565) LCD (480×320 dots). The start position of the coordinate system on the display will be selected by two rotating selectors. The third selector will be used to set parameter c either continuously or from the list Values ​​with optically interesting output.

Rendering of the display should occur in a thread independent of the computational thread.

Parameters should also be possible to set up remotely by sending a UDP message In the text format “<x> <y> <c>” to port 44444.

Rating of Solution

  • [+2 points] graphic display output
  • [+1 point] computing and rendering a set - algorithm from B3B36PRG if the object code is to be shared, in the B35APO object it is possible to choose another interesting formula for fractal rendering
  • [+2 points] changing the plotting parameters and the formulas according to the rotary selectors
  • [+2 points] output on the display in a separate thread
  • [+3 points] listing of set parameter values ​​on text display
  • [+2 points] displaying menu for adjustments - brightness, color palette, etc.
  • [+2 points] remote setting of parameters from PC, for example via UDP message
  • [+2 points] mode for display case, the parameters are changed periodically so that the display is constantly changing and interesting pictures / effects alternated
  • Required documentation. The following points are only for the fully functional solution.
    • [+2 points] for the user guide
    • [+2 points] for technical report]

The initial application creation template

The application template is in the directory

/opt/apo/mzapo_template

The following files are included in the template

  • Makefile - rules for building and remote running of an application
  • Change_me.c - source code with main function main - template to be renamed
  • Font_prop14x16.c - raster proportional width font 14×16 (width x height points)
  • Font_rom8x16.c - raster fixed width font 8×16
  • Font_types.h - definition of type used for font description
  • Mzapo_parlcd.h - declaration of functions for low level access to the LCD display
  • Mzapo_parlcd.c - implementation of low-level access to the LCD display
  • Mzapo_phys.h - declaration of function for mapping the physical range of addresses into the application process
  • Mzapo_phys.c - implementation of a physical address mapping function into an application process
  • Mzapo_regs.h - definition of base addresses and MZ_APO tutorials

A more detailed description of the design registers can be found in documentation of MZ_APO.

The `Makefile` rules for the build program need to be customized for your own application. The application will consist of one or more source files in the language C (files with the extension `*.c`) or in C ++ (files with the extension `*.cpp`).

An example with the main function

main
is in the sample file `change_me.c` which should be replaced, renamed as application-specific file.

A list of source files is set in the SOURCES variable, see below Part of the `Makefile` file

SOURCES = change_me.c mzapo_phys.c mzapo_parlcd.c
#SOURCES + = font_prop14x16.c font_rom8x16.c

In the first line, you need to edit the name of your main application file. If fonts are used, you need to uncomment the second line. To add other needed files, it is possible to list them in these two lines or repeating them with += for adding other needed files. Header files (`* .h`) are not listed in make files, they are inserted by C preprocessor.

The name of the desired binary executable is assigned in the variable TARGET_EXE

The translation is done by simply calling the build program

make
where the first rule found is `all`.

To delete generated files (object files, application binary code and automatically generated dependencies), use `clean` object. Objects can also be combined

make clean all

Any compilation when you change and run an application on a remote drive is done when invoking the object `run`

make TARGET_IP=192.168.202.xxx run

Automatic login, data transfer and application launch on target device with the given IP address requires an already-established private key in the SSH agent for that session

ssh-add/opt/apo/zynq/ssh-connect/mzapo-root-key

The application is first copied to the subdirectory /tmp created by user's login name and, then, the application is running with the default Both input and output are available on the developer's computer via SSH connections.

Files are also available in GitLab FEL via ssh (required public key):
git@gitlab.fel.cvut.cz:b35apo/mzapo_template.git
Alternatively, via https:
https://gitlab.fel.cvut.cz/b35apo/mzapo_template.git

Unconnected / Datagram Communications in IP Network (Internet Protocol)

Currently, the IP (Internet Protokol) is the most common standard for communication between computers and devices. The protocol is a higher packet, datagram and link layer protocol. To implement our own frame transfer, a variety of technologies are available on local networks. The most widespread is ETHERNET, which does not, however, address the transmission of frames between multiple networks in its basic formats.

The IP protocol exists in two versions IPv4, which uses to identify the interface. Each computer on the World Wide 32-bit address. Gradually, it passes to a new version of IPv6 that uses 128-bit addresses with better sophisticated assignment and communication rules.

A simpler version of IPv4 is expected to work on a semester task. Above basic a network layer, there is several other protocols specializing in different needs and types of transmission. The best known is the protocol TCP which serves to ensure a secure connection with the complete acknowledgment of receipt mechanism give. The data stream is suspended in the event of packet loss and re-sending is secured undelivered data. Protocol is used, for example, for the most widespread transport application Protocols and HTTP, HTTPS, and SSH services. However, TCP is not suitable for parallel delivery messages with a general destination address to all participants on the local network (Broadcast).

*In order to maintain the list of all the connected units*, the unconnected datagram protocol UDP will be used within your application that allows sending status information to the local network without defining the destination address. Such messages can then receive by all units on the local network.

An example of a simple program in the role of the server and the other in the client can be found, for example in the Beej's Guide to Network Programming manual.

First you need to set up a network socket

   Int sockfd;

   If ((sockfd = socket (AF_INET, SOCK_DGRAM, 0)) == -1) {
        Perror ("socket");
        Exit (1);
    }

The AF_INET option specifies the IPv4 address family, SOCK_DGRAM then selects the UDP unconnected service. More about calling socket in Beej's Guide or in https://www.gnu.org/software/libc/manual/html_node/Creating-a-Socket.html#Creating-a-Socket] GNU C library documentation used on GNU / Linux.

Select a local port, on which the application listens and which is used with the outbound IP address. The computer / drive interface is selected by calling bind (GNU).

Because the datagrams could be sent to all local area network units by mistake, this option must be enabled

    Int broadcast = 1;

    If (setsockopt (sockfd, SOL_SOCKET, SO_BROADCAST, & broadcast,
        Sizeof broadcast) == -1) {
        Perror ("setsockopt (SO_BROADCAST)");
        Exit (1);
    }

It is also possible to use calls sendto and recvfrom to send messages.

Basic example of binding (labeling) IPv4 socket to the service specific port number to be accessible from all network interfaces. The value MY_PORT is 16-bit number in the range 1 to 65535. The network addresses are stored in the network stack data structures in the IP network standard byte order which is big-endian one. The port number has to be converted from the CPU native (h = host) order to the network (n = network) byte order for this reason. The port numbers in the range from 1 to 1000 are reserved for system/privileged services and can be used/requested for the bind only by programs with administrator privilege or delegated privilege for full network stack control.

  struct sockaddr_in bindaddr;

  memset(&bindaddr, 0, sizeof(bindaddr));
  bindaddr.sin_family = AF_INET;
  bindaddr.sin_port = htons(MY_PORT);
  bindaddr.sin_addr.s_addr = INADDR_ANY;

  if (bind(sockfd, (struct sockaddr *)&bindaddr, sizeof(bindaddr)) == -1) {
    perror("bind");
    exit(1);
  }

By default, system blocks reassignment of the same port number for the new instance of the service to new socket for some while after previous user has closed/released the port. That is why it is worthwhile to prevent this temporal blocking before bind() call when service should operate on the predefined port number.

  int yes=1;

  if (setsockopt(sockfd, SOL_SOCKET, SO_REUSEADDR, &yes,
                sizeof(yes)) == -1) {
    perror("setsockopt (SO_REUSEADDR)");
    exit(1);
  }

Because unintentional sending of broadcast to the network can lead to high load and disturbance of other communications, the broadcast transmission is disable for new socked by default. It can be enabled by set of the socket option

    int broadcast = 1;

    if (setsockopt(sockfd, SOL_SOCKET, SO_BROADCAST, &broadcast,
        sizeof broadcast) == -1) {
        perror("setsockopt (SO_BROADCAST)");
        exit(1);
    }

The datagrams corresponding UDP services can be send by sendto call and received by recvfrom call.

IPv4 address for broadcast datagram sending to the local network can be setup as

  struct sockaddr_in braddr;

  memset(&braddr, 0, sizeof(braddr));
  braddr.sin_family = AF_INET;
  braddr.sin_port = htons(HELLO_SERVICE_PORT);
  braddr.sin_addr.s_addr = INADDR_BROADCAST;

Simple test of UDP communication from a command line

Server / listener of UDP packed receiving on all network interfaces starting

nc -u -l -p 44444

Starting command to send message

nc -u 127.0.0.1 44444

courses/b35apo/en/tutorials/10/start.txt · Last modified: 2018/04/25 17:32 by susta