Embedded Ethernet Module (A3053) Manual

Contents

Description

[24-DEC-25] The Embedded Ethernet Module (EEM, A3053) is a Fast Ethernet to Eight-Bit Parallel Bus interface built on a Mini PCI Express (mPCIe) card. When we design a new instrument, and we want to control and read out the instrument over our Local Area Network (LAN), we place an mPCIe socket on the instrument motherboard, route a few traces to a 100Base-T socket on the edge of the board, a few traces to a pin header for programming, a few traces to another pin header for a three-wire console interface, and eighteen traces to our instrument's logic circuits to act as the interface between the logic and the EEM we plug into the mPCIe socket. Starting with the complete, production-tested example code provided by Open Source Instruments, we develop the network interface we desire. We connect our instrument to our LAN with an Ethernet jumper cable. If the LAN switch provides Power over Ethernet (PoE) we can add a PoE converter to our instrument and power the entire thing off the same cable we use for communication. We are loading PoE on all our new instruments. The resulting instrument is easy to install and easy to communicate with.

Figure: Embedded Ethernet Module (A3053A), Top Side. There are no parts on the bottom side. This version does not provide a SIP-4 footprint for the serial UART bus connection, but the A3053B will do so, as well as two small, surface-mount reset and configuration switches.

We designed the EEM to replace the RCM6700, which we have been using since 2011, starting with our LWDAQ Driver with Ethernet Interface (A2071E), and more recently in our Animal Location Tracker (A3038). In October 2024, Digi International, the company that manufactures the RCM6700, announced they were discontinuing the RCM6700, with a Last Time Buy (LTB) date of December 15, 2025. In January 2025, we were unable to find the RCM6700 at any distributor in the US or China. Today we see 607 of them at Digi-Key. Its "Product Status" has been updated to "Active". But we have already developed our EEM, and its performance is far superior to that of the RCM6700, so we will be using it from now on in place of the RCM6700. The RCM6700 provides a peak download speed of 1.4 MByte/s, while the EEM provides close to 7 MByte/s. The EEM is powered by Microchip's PIC32MZ 32-bit, 200-MHz micro-controller unit (MCU). The PIC32MZ provides analog inputs and peripheral pin selection for routine specialized functions to pins of our choice. The RCM6700 is a 16-bit, 162-MHz micro-controller with no analog inputs. We manage our EEM source files with a text editor, compile them from the command line with Make, and distribute them on GitHub. We can build the EEM executable with equal ease on Windows, Linux, or MacOS using Microchip's xc32-gcc compiler. The RCM6700 code must be compiled within the Dynamic C Integrated Development Environment (IDE), which runs only on Windows.

Figure: The Discontinued RCM6700 Mini-Core Module. When programmed correctly, the A3053A should be able to act as a drop-in replacement for the RCM6700, duplicating Ethernet communication and all digital input-output functions.

In our circuits, the EEM is a dop-in replacement for the RCM6700. For other RCM6700 users, the chances are good that the existing RCM6700 functions can be implemented with the EEM with the help of the PIC32MZ's flexible pin configuration and assignment options. We can program the EEM where it sits on an RCM6700 motherboard with the help of a home-made adaptor for the Microchip PICKit programmer. We can communicate directly with the EEM over a three-wire UART serial bus by loading a four-pin header into the EEM's console connector footprint, and connecting an off-the-shelf USB-to-UART bridge to the RX, TX, and GND pins on the header. This serial interface provides the debugging console and a Command-Line Interpreter (CLI) through which we can query and control the EEM during development. When we design a motherboard specifically for the EEM, we can provide a programming connector that mates immediately with the PICKit, and a four-pin header that mates immediately with the USB-to-UART bridge. An existing RCM6700 motherboard will have the mPCIe module connected to an RJ-45 socket with internal magnetics. The EEM is drop-in compatible with these existing connections. If the motherboard uses the RCM6700's peripheral input-output bus, the EEM provides access to this bus immediately.

The heart of the A3053 is a PIC32MZ2048EFH Embedded Connectivity with Floating Point Unit MCU in a TQFP-100 package. This particular variant of the PIC32MZ family is equipped with 2 MByte of flash memory and 512 KByte of random-access memory (RAM). It uses the MIPS32 M4K instruction set and runs at 200 MHz. The TQFP-100 package provides fifty-one general-purpose input-output (GPIO) pins, of which forty are routed by the EEM to pins on the mPCIe connector. These GPIOs including 12-bit analog-to-digital converter (ADC) inputs, pulse-width modulated (PWM) outputs that will mimic analog outputs, and tri-state buffers for driving digital buses. The PIC32MZ provides its own media access controller (MAC), but the Ethernet physical layer is external to the microcontroller. The EEM's Ethernet physical layer is provided by another Microchip part: the LAN8720A. Also mounted on the EEM are a 50-MHz oscillator, five LEDs, and a collection of capacitors and resistors. There are no parts on the underside of the board. A four-pin footprint for the three-wire UART serial bus we leave unpopulated unless we need to view debug printing and communicate with the EEM without the network interface.

Figure: Drawing of the Full-Size Mini-PCI Express (mPCIe) Card Outline. Taken from the mPCIe Specification.

We currently have working EEM prototypes undergoing production testing in our OSI electronics shop. The network interface appears to be stable on a timescale of days. We are still working on the timing of accesses to the mPCIe parallel bus. We will replace the prototype A3053A with a new A3053B in the coming months. The A3053B will provide a better allocation of PIC32MZ pins to the mPCIe connector, so as to simplify and accelerate the EEM routines that access the mPCIe bus. The Telnet and LWDAQ Our hope is that other users of the RCM6700 will be able to program the A3053A to act as a drop-in replacement for their own RCM6700-based instruments, requiring no modification of their motherboard. In the future, we hope to make use of the many features offered by the PIC32MZ that were not offered by the RCM6700, such as its ADC inputs and PWM outputs.

Pin Assignments

[24-DEC-25] The table below gives the connections between the A3053A circuit and the mPCIe connector. In the A3053A Signal column, we give PIC32MZ (U1) and LAN8720A (U2) pin names, at taken from Table 3 in the PIC32MZ data sheet. In the mPCIe Signal column we give the mPCIe (P1) contact upon which the A3053A signal appears.

Most of the PIC32MZ connections we name after the shortest and simplest name assigned to them by the PIC32MZ data sheet. In some cases we give longer names to draw attention to a particular function the pin might be used for. The SOSCI signal on P1-35, for example, is an input for a 32.768 kHz real-time clock, while SOSCO is an output for the PIC32MZ's built-in 32-kHz clock. The /MCLR signal must be a global negative-true reset signal provided by the motherboard. The signal must be asserted for 100 ms after power-up, and it must be debounced by a motherboard reset monitor if there is a motherboard reset switch. We connect this signal to P1-16, where it drives the PIC32MZ's /MCLR input. For compatibility with the RCM6700, we have this same signal being directed to P1-28, which is the RCM6700 /RESET output. The P1-16 signal is the RCM6700's /RESET_IN connection, which is why we chose it to bring /MCLR to the PIC32MZ. The Ethernet connections on the mPCIe card edge are TXP, TXN, RXP, RXN, and ECOM. The ECOM signal is the Ethernet common-mode voltage, which is provided by the A3053 so as to suit its own Ethernet physical layer. The voltage provided by the A3053A is 3.3 V. We note that the ECOM provided by the RCM6700 was 2.5 V.

Source Code

[24-DEC-25] Our P3053 GitHub repository contains all the source code you need to create an embedded TCP/IP server with parallel interface to its motherboard. All the source code is written in C. To compile and link a P3053 executable file, you must use Microchip's xc32 compiler and linker. These you can download from Microchip and install on your laptop so they run from the command line. After installing xc32, edit the P3053 makefile so that MP_DIR points to the directory in which you installed the xc32 binaries. In our case we have "MP_DIR=/Applications/microchip/xc32/v4.60/bin". To manage the executable build, we use "GNU Make", so you will need that installed on your machine as well. Open a terminal, navigate to the P3053 directory, and type "make". This same procedure works on Windows, Linux, and MacOS. You will see the build start and progress. In the end, a hexadecimal file named something like "P3053A.hex" will appear in the "P3053/build" directory. This is the file we use to program the PIC32MZ. Our build system makes no use of the Microchip's "MPLAB X" graphical development environment. To edit files, we use a text editor like Sublime (Linux, MacOS, Windows), BBEdit (MacOS), or Crimson Editor (Windows), all of which allow us to collect source files together and move easily between them. The combination of text editor and command-line Make is fast, simple, and effective.

The code that manages the Ethernet physical interface, provides the entire TCP/IP stack, declares all the PIC32MZ register names, manages the UART interface, and sets up the MCU timers all resides in our "src/microchip" directory. These files are provided by Microchip and are taken from their Harmony3 libraries. The Harmony3 source code is free and provided with no license restrictions, although we must preserve their copyright notices. The code provided by Open Source Instruments (OSI) is in the "src" directory. This code is also free, but we issue it under the GNU Public License, which prohibits its inclusion in any code project that is not itself distributed for free under the same license. Our P3053 repository does not include the WolfSSL library that Microchip uses to provide Secure Socket Layer (SSL) services. Nor does it include Microchip's cryptography libraries. We eliminated both these libraries because we have no use for them and they were slowing down our build process. We can conceive of no application at OSI in which a data acquisition computer would need to serve an SSL to a client, nor any application where one of our instruments would be required to connect to an HTTPS server to upload data. Nor do we include in our P3053 repository the Harmony3 HTTP server library. We at first thought it would ne neat to provide an HTTP configuration interface for the EEM, but when we came to actually working on the EEM, we found that the console and Telnet command-line interpreters are far more useful and versatile than any HTTP interface. With the Telnet server running, we can open a socket to and use it to configure the EEM during production, adapting the A3053 for a particular application. After that, we can use the same interface to disable the Telnet server starting with the next software reset, so that the EEM is no longer accessible through Telnet.

The OSI code consists of the files listed below. Each library consists of two files: an interface and an implementation. The interface file, or "header file", declares the shared functions provided by the library, and contains comments explaining in detail the purpose and proper usage of these functions. The implementation file, or "C file", defines the library functions and contains comments explaining in general terms how the functions work. We trust that the code itself will reveal how each function works in detail.

cli.c		console.c	main.c		server.c	utils.h
cli.h		console.h	microchip	server.h
config.c	lwdaq.c		pic.c		shim
config.h	lwdaq.h		pic.h		utils.c

As we provide it, the P3053 source code sets up two servers: Telnet and LWDAQ. Anyone can connect to the Telnet server with the "telnet" utility, the "nc" utility, or with a Python or Tcl socket channel. The Telnet server provides a command-line interpreter (CLI). Type "help" to get a list of available commands. Type "command --help" to get detailed help for a single command. The CLI's "mpcie" command allows us to read and write from the mPCIe parallel bus. This network access to the mPCIe bus is available as soon as we boot up the EEM. The Telnet server is designed for text-only communication. We have programmed it to ignore Telnet control characters. When we read bytes from the mPCIe bus, they will come back as text strings. The Telnet server's TCP socket is managed by our generic tcpip_server state machine. In the "main.c" file, we see the Telnet's server description record being composed and the Telnet server task function being defined. We see the task function composing a channel description record for each Telnet client socket and then using this record to provide the CLI to the client. In "console.c", we set up the PIC32MZ's UART2 interface to act as the destination for operational and diagnostic reporting. In the console_start function, we see the connection being made between the console UART interface an our CLI. The console and its CLI allow us to obtain reports from the EEM, and query and modify its configuration, even without a working network connection.

Although useful during development and testing, the Telnet interfaces is not fast enough to support real-time data acquisition in our own instruments. We need the EEM to provide fast, binary-format communication. In our case, we use our own LWDAQ binary messaging protocol. The P3053's "lwdaq.c" file provides routines to receive and interpret LWDAQ messages, acknowledge them, and upload binary data to the client. When we start a TCP/IP server with lwdaq_tasks as its task function, the server will be a LWDAQ server. In "lwdaq.c" we see how the server achieves fast and reliable binary communication as well as rapid opening and closing of sockets without losing any data. We see how we can use the tcp_tick routine to maintain the TCP/IP stack and Ethernet interface while polling bytes on the motherboard with the mPCIe bus. With the LWDAQ server as an example, we hope new users of the EEM will find it easy to prepare servers for their own binary TCP/IP data acquisition protocol.

Programming

[24-DEC-25] We program the A3053's PIC32MZ microcontroller using a connector on the motherboard. For motherboards that were designed for the RCM6700 mini-core module, see RCM6700 Compatibility. But if we have a motherboard designed for the EEM, and intended only for the EEM, we can provide programming connectors that are immediately compatible with Microchip cables. We can program the PIC32MZ using either an ICSP or a JTAG programming interface. The ICSP interface is slower, but it is more capable of restoring the PIC32MZ after a disastrous mis-configuration. The JTAG interface is, we are told, faster, and allows us to set breakpoints in our code for debugging. It permits us to read register values directly from the PIC32MZ. But the JTAG interface can be disabled after a disastrous mis-configuration, so all motherboards should provide the ICSP programming interface. We have not used the JTAG interface yet. For programming, we use the ICSP interface. For debugging we use our UART serial bus interface with its console for progress and debugging messages, and its built-in command-line interpreter.

The ICSP programming interface uses two dedicated signals that pass through the mPCIe connector to the PIC32MZ. It also uses a global /RESET line, which is called /MCLR in the ICSP signal naming. This line must be an open-drain signal that the ICSP programming cable can drive LO to cause a global reset, and then release to bring the system out of reset. The motherboard should provide a reset monitor that asserts /RESET on power-up for 100 ms or so, and also debounces /RESET when it is asserted with a push-button switch, but otherwise does not delay the release of /RESET more than 10 ms after all other sources of /RESET have released the line. Somewhere on the motherboard, /RESET needs to be pulled up by a resistor. The table below gives the pinout of the ICSP programming connector, which is a 1×6 0.1" rectangular header.

There are four JTAG signals on the mPCIe connector: TCK, TMS, TDI, and TDO. The Microchip JTAG programming cables expect a 2×5 0.1" rectangular plug with the pinout given in the table below. The JTAG connections on the EEM's mPCIe connector can be configured to act as GPIO lines, so we do not need to dedicate them to JTAG. We can instead use them for analog or digital input and output.

We have not yet tested the A3053's JTAG interface. We must wait until we design a motherboard designed specifically for the A3053, and include on that motherboard a connector for the JTAG interface. We have, however, been able to solve all technical problems and find all bugs in our code with the use of only the ICSP interface and our UART console.

Persistent Configuration

[24-DEC-25] The configuration of the EEM is stored in flash memory, so it is persistent through power cycles and resets. We can restore the configuration to its factory default state by performing a configuration reset. An instrument equipped with an EEM should provide a reset button and configuration button accessible from the outside of its enclosure. The reset button will assert the EEM reset line, and the configuration button will clear the least significant bit of a location in the mPCIe parallel bus memory space. We use location 0x28 for this purpose (decimal 40), but the P3053 software can be modified to use any location. The EEM checks the state of this bit after reset, and if the bit is cleared, it overwrites the flash configuration with the factory default configuration. The EEM itself provides its own reset and configuration switches, so we can use these instead, but these will not be available on the outside of the enclosure. (Neither of these switches is available on the A3053A, but will be on later models.) We hold the configuration switch down for three seconds after releasing the reset button to accomplish the factory reset. In this way, we can restore the EEM to a known state should we forget its IP address, or if its IP address is set to a value inconvenient for us to connect to. The factory reset configuration is like this:.

static const eem_config_type eem_config_factory = {
	.flash_magic = CONFIG_FLASH_MAGIC,
	.seclevel = 0,
	.password = "LWDAQ",
	.person = "unassigned",
	.ip_str = "10.0.0.37",
	.gw_str = "10.0.0.1",
	.nm_str = "255.255.255.0",
	.timestamp = "00000000000000",
	.device = EEM_PLATFORM,
	.lwdaq_port = 90,
	.telnet_port = 23,
	.lwdaq_timeout = 10,
	.telnet_timeout = 300,
	.tcp_tick_ms = 2
};

Among the configuration parameters is a security level and password. These control access to the EEM and its configuration records. There are three configuration records available in the EEM: active, factory, and flash. The active configuration is the one that was read from flash memory on start-up. The flash configuration is the one currently residing in flash, which will be different from the active after we perform a modification. The factory configuration can be read but not modified. Nor can the active configuration be modified except when it is read from flash memory up after reset. If the security level is zero, no login is required to connect to and make full use of the EEM, including reading and modifying its configuration records. If the security level is one, we must provide the password in order to read any of the configuration records or modify the flash configuration record. If the security level is two, we must provide the password before the EEM will allow us to perform any operation other than a password login operation. In our P3053 software, our Telnet and LWDAQ servers, as well as our UART serial interface, all respect the security level setting, although the serial interface behaves slightly differently. When the serial interface's command-line interpreter starts up, its logged-in flag is set. But for connections to the Telnet and LWDAQ servers, the logged-in flag is cleared until a successful login occurs.

The EEM's Telnet and LWDAQ servers listen on ports assigned by the two configuration port parameters. The LWDAQ server is the one we use for our data acquisition instruments, and in our P3053 code, the LWDAQ server provides an example of how to implement a binary messaging protocol for data acquisition. If we set either port to zero, the server will be disabled. The Telnet port provides a command-line interpreter, and we can use this to modify the EEM flash configuration. Here is the help text provided by the interpreter's "config" command.

config --help
Usage:
  config [--info|--help]
  config show <active|flash|factory>
  config set --option <value> [OPTIONS]

Description:
  Display or modify Embedded Ethernet Module (EEM) configuration records. The
  'show' operation allows us to select one of the three EEM configuration records:
  'active', 'flash', or 'factory' for display. The 'set' operation allows us to
  modify or over-write the configuration stored in flash memory. With '--replace'
  we name 'active' or 'factory' to overwrite the flash configuration. Other 'set'
  options allow us to modify individual fields in the flash configuration. Several
  fields take the form of character strings. These must contain no spaces or tabs.
  Any quotation marks, either single or double, will be interpreted as delimiters
  rather than members of the string. This command respects the security level
  declared by the active configuration. If the security level is > 0, the command
  will prohibit both 'show' and 'set'. operations unless the channel status is
  LOGIN_PASS. For the Telnet and LWDAQ port numbers, we enter a value 0-65535, for
  which 0 will disable the server.

Verbs:
  show                  Display active, flash, or factory configuration.
  set                   Over-write the flash configuration record.

Selectors:
  active                Currently active configuration.
  flash                 Configuration stored in flash memory.
  factory               Factory-default configuration.

Options:
  --replace <config>    Over-write flash with active or factory configuration.
  --seclevel <0|1|2>    Set security level to value 0-2.
  --password <str>      Set password to string containing no whitespace.
  --person <str>        Set operator name to string containing no whitespace.
  --ip-str <str>        Set flash IP address to x.x.x.x.
  --gw-str <str>        Set flash gateway address to new string x.x.x.x.
  --nm-str <str>        Set flash network mask to new string x.x.x.x.
  --timestamp <str>     Set timestamp to string containing no white space.
  --device <str>        Set device name to string containing no white space.
  --telnet-port <port>  Set flash Telnet server port, 0 to disable.
  --lwdaq-port <port>   Set flash LWDAQ server port, 0 to disable.
  --telnet-timeout <s>  Set flash Telnet server timeout in seconds.
  --lwdaq-timeout <s>   Set flash LWDAQ server timeout in seconds.
  --tcp_tick_ms <ms>    Set tcp tick execution period in milliseconds.
  --info                Summary of this command, no changes made.
  --help                Detailed help for this command, no changes made.

The EEM's UART serial interface provides the same command-line interpreter, which is useful during development, but unlikely to be useful to someone operating outside the instrument's enclosure. We can also modify the flash configuration through the LWDAQ server, by means of the LWDAQ Configurator Tool.

After a factory reset, we can connect to the EEM to modify its configuration in one of three ways. The best way for us as to communicate with the EEM as a user of the instrument is to connect it to our laptop with an Ethernet cable and set our laptop to operate on the 10.0.0.x subnet. We can now Telnet to the EEM, or connect to it with the Configurator Tool. Over Telnet, we use the "config" command to edit flash configuration fields individually. With the Configurator Tool we have access to the those fields important to the LWDAQ server, but not those controlling the Telnet server. After editing the configuration, we reset the EEM to bring the new configuration into effect. If we have modified the IP address, gateway address, and network mask, the new values will take effect. We now place the EEM on the newly-assigned subnet and connect to it from a computer that has access to that subnet.

Command-Line Interpreter

[26-DEC-25] The P3053 software provides a channel-agnostic command-line interpreter (CLI). We can deploy the CLI on any communication channel for which three routines to manage the channel: one routine to read zero or one characters from the channel, one routine to write one character to the channel, and one routine to flush characters out of the channel. The "cli.c" file shows how the interpreter uses these routines to collect commands names and arguments strings for command routines to execute. The "cli.c" file also includes a few example commands. In "main.c" we see the console being attached to the CLI and commands being registered with the CLI. In the telnet_tasks function, also in "main.c", we see the Telnet server being attached to the CLI. Here is what we see in a Telnet console when we log into the EEM and execute the help command in P3053 commit v1.22.

% telnet 10.0.0.37 
Trying 10.0.0.37...
Connected to 10.0.0.37.
Escape character is '^]'.
===========================================================
===  Embedded Ethernet Module Command-Line Interpreter ====
===========================================================
Command-line interpreter running, try 'help' for help.
help
Available commands:
  config           Display or modify EEM configuration records.
  debug            Sets or clears the debug flag.
  help             List all commands with descriptions.
  login            Sets login flag if password correct.
  mpcie            Read and write from the eight-bit MPCIE bus.
  reset            Initiate a software reset of the EEM.
  status           List PIC32MZ internal information.

The CLI does not print a prompt at the beginning of a new line when it is waiting for a new command. The prompt does not work well when mixed with debug printing in the serial console, and it complicates automated interactions with the CLI: no automated interaction needs the prompt. All communication with the CLI is line-buffered: we will receive a carriage return and line feed character at the end of each output line. When the CLI returns an error, it always does so with the exact phrase "ERROR: " at the beginning of the returned line. The cli_login command is essential for the implementation of the EEM security level and password. This one has a name constrained by a global string constant. The cli_help command lists the available commands. Every command we register with the CLI must respond to the "--info" and "--help" options. In response to the "--info" option, the command must ignore all other options and return a summary of the command, no longer than 63 character long. In response to the "--help" option, assuming there is no "--info" option present, the command must print a detailed description of itself. Here is the help response from the "debug" command, as reported by P3053 v1.22.

debug --help
Usage:
  debug  [--info] [--help]

Summary:
  Sets or clears the debug flag that is used to enable console print commands
  for debugging. The default state of this flag on reset is set by a constant in
  the source code, but we can change the flag during run-time with this routine.

Verbs:
  set           Set the debug flag, debug prints enabled.
  clear         Clear the debug flag, debug prints disabled.

Options:
  --info        Print a one-line summary of this command.
  --help        Print this help text.

With the CLI state machine in place, and several examples of commands to adapt for your own purposes, we trust that you can create commands to perform whatever functions you need. The CLI reads and writes one character at a time, and does not provide support for binary data exchanges. If it is going to return a binary byte value, it will need at last two characters to do so: the two characters of a hexadecimal byte. The "mpcie" command available in the CLI of P3053 v1.22 provides read, stream-read, write, and stream-write access to the mPCIe bus. Here is the command help text.

mpcie --help
Usage:
  mpcie <read|stream-read> <addr> [length] [--decimal|--packed] [--info] [--help]
  mpcie <write|stream-write> <addr> [--info] [--help] <value> [value...]
  
Summary:
  Writes to and reads from the mPCIe eight-bit bus. For both actions, we must
  specify an eight-bit address 'addr' either as hexadecimal with a '0x' prefix or
  as decimal with no prefix. The 'write' and 'stream-write' operations write as
  many values as we pass on the command line. The 'write' operation starts writing
  at location 'addr' and increments the location after each write. The
  'stream-write' writes all bytes to the same location 'addr'. The command reads
  bytes as a space-delimited string either in hexadecimal or decimal, just as for
  the 'addr'. The 'read' operation reads 'length' bytes from consecutive
  locations, starting at location 'addr'. The 'stream-read' operation reads
  'length' bytes from the same location 'addr'. If we omit 'length', it defaults
  to 1. By default, the returned bytes will be written as sixteen bytes to a line,
  each byte two hexadecimal digits separated from its neighbors by a space, and
  with each line of sixteen bytes starting with the mPCIe address of the first
  byte, expressed in hexadecimal with a '0x' prefix. With the '--decimal' option,
  the bytes read will be expressed as decimal values separated by spaces. With the
  'compact' option, the bytes will be returned as a packed string of hexadecimal
  bytes, each byte two digits only, with no separators, no newlines, and no
  address markers.
  
Verbs:
  read         Read multiple bytes from consecutive mPCIe locations.
  stream-read  Read multiple bytes from the same mPCIe location.
  write        Write multiple bytes to consecutive mPCIe locations.
  stream-write Write multiple bytes to the same mPCIe location.
  
Selectors:
  length       The number of bytes to read.
  
Options:
  --decimal    Display bytes read as positive decimal values.
  --packed     Display bytes read as packed hexadecimal.
  --info       Display a one-line summary of command, no bus access.
  --help       Display this help text, no bus access.

In our mPCIe bus interfaces with motherboard logic, we accelerate readout by making the data available in a buffer we can read repeatedly at a single mPCIe location. With the "--packed" and "--stream-read" options, we can use the CLI to read data from such a buffer. The maximum number of bytes we can read or write in one operation is limited by the size of the CLI buffers. In P3053 v1.21 the limit is 512 bytes. With these maximum-length reads, we obtain a download rate through the CLI's "mpcie" command of roughly 5 kByte/s. This rate is far below the 6 MByte/s we obtain when reading the mPCIe bus with our binary LWDAQ interface. Nevertheless, the CLI provides immediate and convenient access to the mPCIe bus, and allows us to begin testing our instrument with small data exchanges.

RCM6700 Compatibility

[24-DEC-25] We designed the A3053 embedded ethernet module as a drop-in replacement for the RCM6700. Whether or not the A3053 can replace the RCM6700 in all applications is a hard question to answer. The A3053A is able to replace the RCM6700 in all our own instruments, and we have routed PIC32MZ general-purpose input-outputs (GPIOs) to all pins for which the RCM6700 provided its own GPIOs, so we believe the chances of the A3053 being able to replace the RCM6700 in any given application are high. The table below presents the mapping of A3053A signals to RCM6700 signals, organized in order of mPCIe pin number. We used Table 4.3 in the RCM6700 data sheet and Table 3 in the PIC32MZ data sheet.

The A3053A does not attempt to duplicate the RCM6700 battery backup power circuit. According to the RCM6700 data sheet, it consumes 120 μA in it standby state while the PIC32MZ consumes up to 800 μA in its standby state. The RCM6700 provides an external battery input that would allow the module to retain memory and run its watchdog timer even when the motherboard lost power. The A3053A uses the external battery contact on the mPCIe connector for one of the JTAG programming connections, and makes no effort to provide a separate battery power input.

Figure: PICKit5 Programmer for RCM6700 Mother Boards. We use a 1×8, 0.1" plug to 2×5, 0.05" socket adaptor to program an A3053A plugged into an RCM6700 motherboard. The motherboard provides a 2×5, 0.05" header for programming.

All our RCM6700 motherboards provide a programming plug. We can use this plug as an ICSP programming port for the A3053A with the help of an adaptor cable. The RCM6700 programming plug is a 2×5 0.05" rectangular plug such as the GRPB052VWQS-RC, while ICSP programming cables expect a 0.1" 1×6 rectangular plug such as the PRPC006SACN-RC, or perhaps a 0.1" 1×8 plut such as PRPC008SACN-RC. Starting with a LPPB052CFFN-RC 2×5 receptacle, we run wires to a 1×6 or 1×8 plug according to the table below. We push the 2×5 receptacle onto the RCM6700 motherboard on which we have mounted our A3053A. We connect the 1×6 of 1×8 header to our ICSP programmer. In the case of the PICKit5 programmer, we will use an 1×8 plut. The 1×6 is typical of older programmers. We can now program the A3053A with the ICSP protocol.

The RCM6700 provides a 2.5-V voltage on mPCIe pin 8 that is intended to act as the common-mode voltage for the Ethernet signal termination resistors beside the RJ-45 connector on the motherboard. The A3053A produces 3.3 V on the same pin for the same purpose. The only situation in which this increase in common-mode voltage can cause a problem is if the motherboard makes use of the original 2.5-V voltage provided by the RCM6700. The A3053A does not have a reset signal generator. It requires that the motherboard provide a reset signal /MCLR on mPCIe pin 16, which is the RCM6700's /RESET_IN pin. The A3053A does not generate its own /RESET output. It connects /RESET_IN directly to the RCM6700 /RESET output on mPCIe pin 28. The motherboard must provide its own reset monitor, such as an MCP130, to detect power-up and also to debounce a motherboard reset switch, and this reset signal must be applied to /RESET_IN.

Design

[04-AUG-25] For design files and a chronological account of the development of the A3053, see its Design and Development page.