Changes between Version 12 and Version 13 of Hardware/jCM/dCM3/cSoftware


Ignore:
Timestamp:
Dec 16, 2011, 9:22:19 PM (13 years ago)
Author:
Ilya Chigirev
Comment:

—

Legend:

Unmodified
Added
Removed
Modified

  • Hardware/jCM/dCM3/cSoftware

    v12 v13  
    22
    33== Software Description ==
     4As mentioned previously software for the CM3 is developed in the Paradigm C++ Pro programming environment, and uses the Lantronix XPort AR SDK. At the time of this documents writing the SDK being used was release v5.2.0.0 R21. The CM3 works completely independently from the host node, and as soon as power is applied the native Lantronix XPort AR functions, such as network connectivity, start and then the custom
     5written CM software loads.
     6 
     7=== Files ===
     8The following is a list of the basic files that are in the SVN repository, and what functionality they contain:
     9 * CM3 - Initialization of the CM3, XML configuration, and the main program which runs the two primary threads
     10 * CM3_CLI - Sets up the command line interface (CLI) structure, as well as defining the functions call-backs for each command in the CLI
     11 * CM3_COMMAND - There are the functions that actually execute the commands, whether they be called by HTTP, CLI, or UDP
     12 * CM3_COMMUNICATION - Opens the UDP socket
     13 * CM3_HTTP - creates the HTTP pages and function call-backs to enable HTTP commands
     14 * CM3_I2C - Presently unused other than containing functions that read the hardware status and the 5V monitoring line, this should be done over I2C through the DS1780 chip, but I2C is non-operational
     15 * CM3_IDENTITY Contains functions that query the identifying features of the CM and node, like location, IP address, MAC address, etc.
     16 * CM3_UDP - Where the UDP thread functions are defines, as well as any other functions that process UDP information.
    417
    5 4. Chassis Manager Software Description
    6 As mentioned previously software for the CM3 is developed in the Paradigm C++ Pro
    7 programing environment, and uses the Lantronix XPort AR SDK. At the time of this
    8 documents writing the SDK being used was release v5.2.0.0 R21. The CM3 works
    9 completely independently from the host node, and as soon as power is applied the native
    10 Lantronix XPort AR functions, such as network connectivity, start and then the custom
    11 written CM software loads.
    12 4.1. Files
    13 The following is a list of the basic files that are in the SVN repository, and what functionality
    14 they contain
    15  CM3
    16 Initialization of the CM3, XML configuration, and the main program which runs
    17 the two primary threads
    18  CM3_CLI
    19 Sets up the command line interface (CLI) structure, as well as defining the functions
    20 call-backs for each command in the CLI
    21  CM3_COMMAND
    22 There are the functions that actually execute the commands, whether they be
    23 called by HTTP, CLI, or UDP
    24  CM3_COMMUNICATION
    25 Opens the UDP socket
    26  CM3_HTTP
    27 creates the HTTP pages and function call-backs to enable HTTP commands
    28  CM3_I2C
    29 Presently unused other than containing functions that read the hardware status and
    30 the 5V monitoring line, this should be done over I2C through the DS1780 chip,
    31 but I2C is non-operational
    32  CM3_IDENTITY
    33 Contains functions that query the identifying features of the CM and node, like
    34 location, IP address, MAC address, etc.
    35 Ilya Chigirev WINLAB, Rutgers University
    36 4. Chassis Manager Software Description 16
    37  CM3_UDP
    38 Where the UDP thread functions are defines, as well as any other functions that
    39 process UDP information.
    40 4.2. Initialization
    41 Upon startup the CM3 will fist contact broadcast over the network to discover the IP
    42 address that should belong to it. Assuming that the MAC address is already in DHCP,
    43 an IP address will be assigned to it, and from there the custom CM3 software takes over.
    44 Much of the configuration of the device is done through the XML configuration method.
     18=== Initialization ===
     19Upon startup the CM3 will fist contact broadcast over the network to discover the IP address that should belong to it. Assuming that the MAC address is already in DHCP, an IP address will be assigned to it, and from there the custom CM3 software takes over. Much of the configuration of the device is done through the XML configuration method. [[BR]]
     20
    4521The following are configured through XML:
    46  Serial line
    47  GPIOs
    48  Telnet ports
    49 After XML configuration is completed the CM3 will populate the network information
    50 back into variables set up in software. This is because a lot of the network information
    51 is only available through the XML configuration file and so to recollect it each time
    52 you need it takes a long time. The CM3 then sets up the HTTP commands, which allow
    53 some basic functions of the CM3 to be executed of HTTP, the custom command line
    54 interface for the CM3, as described in table 2, and the user datagram protocol (UDP)
    55 socket.
    56 4.3. UDP
    57 Once the UDP socket is opened two threads are opened that run side by side. The
    58 first is udpListen(), which is the thread that monitors the UDP socket for incoming
    59 packets. Once a packet is received the thread checks for valid CM packet structure and
    60 proceeds to act accordingly if it is. The details of the communication protocol are given
    61 in section 5.
    62 The other thread that is opened is udpPkt(). udpPkt() is the function that is responsible
    63 for sending registration and status packets. Initially the function will send out
    64 registration packets, until it gets a registration ACK, and then a status update packet
    65 every 20 seconds. If the CM sends out 3 status update packets and does not receive an
    66 ACK from the CMC, it will go back to the assumption that it is no longer registered in
    67 the CMC and send out registation packets again. Again, the details of the UDP communication
    68 protocol are described in greater detail in section 5. The two UDP threads
    69 are responsible for most of the functionality of the CM3 as the majority of commands
    70 come from the experiment controller through the CMC over the UDP lines. HTTP and
    71 CLI commands are added functionality for when there is no CMC.
    72 Ilya Chigirev WINLAB, Rutgers University
    73 4. Chassis Manager Software Description 17
     22 * Serial line
     23 * GPIOs
     24 * Telnet ports
     25
     26After XML configuration is completed the CM3 will populate the network information back into variables set up in software. This is because a lot of the network information is only available through the XML configuration file and so to recollect it each time you need it takes a long time. The CM3 then sets up the HTTP commands, which allow some basic functions of the CM3 to be executed of HTTP, the custom command line
     27interface for the CM3, as described in table 2, and the user datagram protocol (UDP) socket.
     28
     29=== UDP ===
     30Once the UDP socket is opened two threads are opened that run side by side. The first is udpListen(), which is the thread that monitors the UDP socket for incoming packets. Once a packet is received the thread checks for valid CM packet structure and proceeds to act accordingly if it is. [[BR]]
     31The other thread that is opened is udpPkt(). udpPkt() is the function that is responsible for sending registration and status packets. Initially the function will send out registration packets, until it gets a registration ACK, and then a status update packet every 20 seconds. If the CM sends out 3 status update packets and does not receive an ACK from the CMC, it will go back to the assumption that it is no longer registered in the CMC and send out registation packets again. The two UDP threads are responsible for most of the functionality of the CM3 as the majority of commands come from the experiment controller through the CMC over the UDP lines. HTTP and CLI commands are added functionality for when there is no CMC.
     32
    74334.4. Loading software
    7534There are two primary methods to reflash a CM3, over the network and also through