Hardware Projects » E1/T1 Hardware Interface (including icE1usb)

h1. Atmel SAM Approach

This page describes a proposed approach of implementing the E1 adapter using [[osmo-e1-xcvr]] and an Atmel SAMx microcontroller, suhc as a SAM3S or SAM4S.

* "SAM3S Manual":http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-6500-32-bit-Cortex-M3-Microcontroller-SAM3S4-SAM3S2-SAM3S1_Datasheet.pdf (64 MHz Cortex-M3)

* "SAM4S Manual":http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-11100-32-bit%20Cortex-M4-Microcontroller-SAM4S_Datasheet.pdf (120 MHz Cortex-M4)

h2. Overview

{{graphviz_link()

digraph G {

  rankdir = LR;

  uC [label="SAM4S uC"];

  XFMR [label="Magnetics"];

  BTS -> XFMR [label="E1"];

  subgraph cluster_A {

    label = "Software Defined E1 Adapter";

    XFMR -> LIU [label="E1 (HDB3)"];

    LIU -> uC [label="E1 (Serial Bits)"];

  }

  uC -> Linux [label="Frame-aligned raw\nbits over USB"];

}

}}

* the SAM controls the LIU via SPI

* the SAM attaches to the host via USB

* The SAM *SSC Peripheral* is used to interface to the receive + transmit bit-streams of the LIU

* The SAM3 *TC Peripheral* is used for Rx frame alignment

h2. Serializing/Deserializing

* SSC can receive/transmit synchronous serial bit streams with external or internal clock

* SSC supports DMA operation between the (de)serializer and RAM using PDC (peripheral DMA controller)

* SSC can run either 

** continously (frame alignment done in software [possibly using bit-banding], as no octet alignment of frames), or

** triggered by RF input, which we supply from SSC (see below) with hardware-assisted frame alignment

h2. Frame Alignment using TC (Timer/Counter)

The idea is to use one of the TC units to perform hardware-assisted frame alignment and this way prevent us from having to do tons of bit-shifting in software in order to align the start of the 256 bit E1 frame with an octet boundary.

* received clock is fed into TCLKx

* internal 16-bit counter is set to count up to 256 (one frame duration)

* TC is operated in WAVEFORM mode

* TIOA or TIOB are operated as output routed to the SSC RF (receive frame) input

* Ra/Rb/Rc registers are used to shift the rising and falling edge of the TIOA/TIOB signal within the 256bit frame

h2. Transmit side

The transmit side is rather simple:

* use either recovered Rx clock or locally-generated clock (from GPS-DO)

* serialize the bits with no particular alignment requirements, as it's entirely up to the receiver to align to the frames we send

h2. Eval boards

For initial development and evaluation of this approach, we used SAM4S evaluation boards connected to the [[osmo-e1-xcvr]] board.

We need access to PA16 (TK), PA17 (TD), PA18 (RD), PA19 (RK).

* "SAM4S-XPRO":http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-42075-SAM4S-Xplained-Pro_User-Guide.pdf

** exposes SSC I/O (stated above) signals on external headers

** contains built-in JTAG/SWD debugger for development + flashing

** exposes SPI on external header (control of [[osmo-e1-xcvr]])

This is a picture from a development prototype using the [[osmo-e1-xcvr]] connected to a SAM4-XPRO:

!{width:50%}e1-xcvr-xpro.jpg!

h2. Circuit board design

@vogelchr has done a circuit board design, it can be found at https://github.com/vogelchr/e1_sam4_usb

!{width:50%}usb-e1-interface.jpg!

h2. Firmware

@vogelchr has done firmware development at https://github.com/vogelchr/e1_sam4_usb_fw, while @laforge has also done similar developments at http://git.osmocom.org/atmel-asf-projects/

h2. Status

Both the evalboard and the @e1_sam4_usb@ circuit board design have been validated.  The firmware has been validated with some PRBS tests.