Architecture of USB E1/T1/J1 adapter
So far we have for many years the Osmo-e1-xcvr board which remains unused. It contains the LIU but no logic that can actually control the LIU and/or process the data.The interface of the LIU is
- receive data + clock (output)
- transmit data + clock (input)
- SPI for control (SDO,SDI,SCLK,CS) + IRQ
- LOS (loss of signal) output (can be read via SPI, not required on controller)
- four 1-bit ports for rx/tx+clk per E1 Line
- three shared 1-bit ports for SPI (shared)
- part of a multi-bit input port as IRQ input
- part of a multi-bit output port as CS output
As a result, a XMOS based device for four E1 ports needs 19 1-bit ports plus 2x 4-bit ports. This is possible with a XU[F]216 part in TQFP-128 package.
No I/O voltage translation is required, and plenty of pins remain unused for LEDs or control of a GPS-DO to provide a proper clock reference.On the USB side, isochronous endpoints should be used for the bitstream. The question in terms of software is how much processing should the XMOS code do, and how much do we perform on the host CPU. Classic E1 interfaces perform functions like
- frame synchronization
- (optional) CRC-4
- timeslot de-multiplex
- (optional) HDLC inside signaling slots
#1 Updated by laforge over 1 year ago
- Status changed from New to Stalled
- % Done changed from 20 to 40
- its 7 single-bit ports are used for RD/RK, TD/TK, SPI_MOSI, SPI_MISO, SPI_CLK
- a single line of one 4-bit port is used for SPI_CS generation
- a single line of one 4-bit port is used for IRQ input
This means that a smaller single-port device should be possible to support from the same firmware, as even the CS/IRQ will use a partial 4-bit port, like in a 4-port design.
So I think in terms of a hardware architecture, it is quite clear how a design would look like, if I ever find time to actually implement it.
#4 Updated by laforge about 1 year ago
Dieter has had the idea to build this using the PRU unit[s] of a TI AM335x processor.
The idea would be to at least prototype using a beaglebord + the PRU-Cape
The main differences of a PRU based solution are:
|+||could run OsmoBSC or OsmoMGW or whatever one would want to run on the ARM core|
|+||can directly provide Ethernet, so no worries with custom USB drivers on Windows (Dieter)|
|0||no need to learn about XMOS programming (But then, PRU programming...)|
|-||need to investigate Linux kernel interface to PRU (remoteproc, rpmsg, virtio)|
|+||not having to rely on exotic low-stock part (XMOS)|
|0||both variants could be produced in series|
|-||LIU+XMOS likely lower cost than AM335x-SOM+LIU|
|-||not possible in a "USB Adapter form factor for usb-powered use" with Laptop or as general peripheral. Well, actually, yes, using USB gadget on the AM335x, but it will be rather large|
where "+" means advantage for PRU, while "-" means disadvantage of PRU compared to XMOS. "0" is neutral.
thread about clock indications: http://listserv.isdn4linux.de/pipermail/isdn4linux/2018-May/006316.html (make sure to read all three messages)