13.9.1. How Angel, Fusion, and the PID hardware fit together

The Ethernet interface for the PID card is provided by an Olicom EtherCom PCMCIA Ethernet card installed in either PCMCIA slot. The Olicom card uses an Intel i82595 Ethernet controller.

The UDP/IP stack is the Pacific Softworks Fusion product, ported to ARM and the Angel environment. The drivers for PCMCIA and the Ethernet card have been implemented, as has the Angel device driver to make the whole stack appear as an Angel device. Figure 13.14 shows how the components fit together.

Figure 13.14. Angel, Fusion ,and PID hardware

Angel, Fusion ,and PID hardware


The stack is initialized in the following sequence:

  1. devclnt.c:angel_InitialiseDevices() calls ethernet.c:ethernet_init()to open a socket.

  2. fusion:socket() notices that the fusion stack has not been initialized. Fusion stack initialization calls:

    1. olicom.c:olicom_init() calls:

    2. pcmcia.c:pcmcia_setup() detects Olicom card and calls:

    3. olicom.c:olicom_card_handler() with a card insertion event and then:

    4. olicom.c:read_card_params() to register olicom_isr() with pcmcia.c.

  3. Fusion stack initialization calls:

    olicom.c:olicom_updown() and, through olicom_state():

    82595.c:i595_bringup() to complete the initialization sequence.

Angel Ethernet device driver

After initialization, the Angel side of the driver is implemented as a polling device. At every call to Angel_Yield(), angel_EthernetPoll() is invoked, and non-blocking recv() calls are made to the Fusion stack to see if data is waiting on any of the sockets.

Outgoing packets are passed to the Fusion stack in a single step by calling sendto().

Interrupt handling

The bottom of the Fusion stack is driven by interrupts from the Olicom card. Interrupts are handled in the following sequence:

  1. suppasm.s:angel_DeviceInterruptHandler() calls the GETSOURCE macro in pid/target.s to identify the PCMCIA controller as the source.

  2. pcmcia.c:angel_PCMCIAIntHandler() establishes that it is an I/O interrupt and calls the routine registered during initialization.

  3. olicom.c:olicom_isr() checks the interrupt, switches off interrupts from the Olicom card, and serializes olicom_process() to do the processing with all other interrupts enabled.

  4. olicom.c:olicom_process() identifies the reason for the interrupt and passes it as an event to olicom_state().

  5. olicom.c:olicom_state() calls an appropriate routine in 82595.c to handle packet reception and transmission.

  6. 82595.c routines control the i82595 chip and transfer packets in both directions between Fusion buffers and the chip. Calls are made to Fusion functions as appropriate.

  7. olicom.c:olicom_process() checks to see whether all interrupt events have been serviced. If so, Olicom interrupts are re-enabled. If not, olicom_process() re-queues itself and then exits in case another device is waiting for the serializer lock.

Additionally, the Fusion stack can make calls to olicom_start() (to queue a new packet for transmission), olicom_ioctl(), and olicom_updown() in response to socket calls from the Angel Ethernet driver or as a result of packet processing.

Copyright © 1997, 1998 ARM Limited. All rights reserved.ARM DUI 0040D