Communication Card and Driver Design Based on Simplified HDLC Protocol
Communication card hardware design
1 The main features of the communication card
The purpose of the hardware design of the communication card is to intelligently communicate: There are 4 DMA channels and corresponding data buffer memory areas on the card. In the data receiving process, the communication card will automatically receive the frame data, determine the frame length, and submit the received frame data to the system at the end of the frame. In the process of sending data, the system only needs to submit the sent data to the card, and the specific sending process is completed by the card itself, without increasing the overhead of the host due to multiple communication. The card has two working modes of internal/external clocks. The modem can be omitted in close range. The baud rate is 600b/s to 64Kb/s. Two channels are provided to meet the RS-232/CCITT V.24 and RS-422A standards. signal.
2 Communication card circuit design
The communication card is mainly composed of DMA controller, bus competition arbiter, serial communication controller, data buffer memory SRAM, memory I/O image and physical address generator, bus interface and protection, baud rate generator, interface circuit, etc. Unit circuit composition.
The DMA controller serves as the master device of the communication card, controls data reception and transmission on the card (from the communication controller and CPU), and is responsible for arbitration priority. Since the host CPU is allowed to access the SRAM of the card during data communication, and the host sends a control command to one of the ways, the remaining three-way communication is not affected, which will make the host CPU and the card DMA compete for the control of the card bus. . The bus does not give the host CPU instruction queue status sequence, it can not directly design multi-host competing, so in the card bus gate array design a state machine, constantly monitor the bus contention, complete the card bus actually Dispute and arbitration functions. The device that completes the serial communication of the HDLC protocol is the INTEL 8274 multiprogramming serial controller that can perform two independent serial receive/send full-duplex communications. In order to make 4 channels in the sending or receiving process of a frame of data, the host does not intervene, so a frame of data to be sent is sent by the CPU into the SRAM on the card before the start of transmission; similarly, during the receiving process The DMA on the card puts the received data into the SRAM. After a frame is received, it is fetched with the batch command and put into the system memory. The SRAM on the card does not occupy the host memory address and uses the I/O image. After the adapter is inserted into the host, the host accesses it through the system I/O address. This is done by the address generator. The bus interface includes data transceivers, data switching circuits, control circuits such as read, write, and interrupt, address decoding, and so on. The baud rate generator provides a programmable clock generator. The user can set the communication rate for use in the internal clock mode. The interface circuit provides interface signals that conform to RS-232/CCITT V.24 and RS-422A standards.
3 communication flow design
If you want to send a frame of data, the CPU uses the batch command to put the data in the card's SRAM, and then set the corresponding transmit DMA channel. The DMA channel is a non-automatic reload mode, and the 8274 controller is started to send. Then the CPU does not need to be managed. It is automatically sent by the hardware on the card.
If you need to receive data, start the receive channel. The receiving channel automatically searches for input signals. When a data frame is searched for, it is managed by the DMA controller on the card, and the received data is put into the SRAM of the card, and the CPU is requested to interrupt and read the data.
4 bus competition design
Because it is possible to perform four-way communication at the same time, and the CPU can issue a control command or access the SRAM memory on the card at any time, the CPU and the main device of the card contend for the status of the card bus. Since the ISA bus fails to give a queued state sequence of CPU instructions, this brings difficulties to bus arbitration, and the bus competition and arbitration of this card are completed by the state machine of the programmable logic device design. The state machine uses a 4MHz signal as the clock, a total of 3 states:
1 CPU control status.
2 DMA control status.
3 In the idle state, neither the CPU nor the DMA can gain control.
When the state machine detects that there is no CPU and the DMA is requesting bus usage rights, it enters an idle state, and once the CPU or DMA requests the bus, the state machine immediately transfers the bus usage rights to the CPU or DMA. If the DMA is requesting bus usage rights during the CPU control state, the state machine still determines the CPU control bus and allows the DMA to wait until the detection CPU instruction is completed and the state machine transitions to the DMA control state. If in the DMA control state, the CPU applies for the bus usage rights, the state machine still determines the DMA control bus and allows the CPU to wait until the DMA bytes are transferred and the state machine is switched to the CPU control state. The CPU and DMA use right of the bus is a single instruction or byte transfer, and no bus block is set. Therefore, the CPU and DMA can frequently exchange usage rights without waiting for a long time.
Communication Card Driver Design
1 Device Driver I/O Model
The driver of the communication card is a standard kernel-mode device driver developed using the DDK software of Windows XP. It uses a unified "file" form, which the user can access using the file manipulation function in the WIN32 subsystem by representing the file name of the communication card device. The device driver and program can be set to be automatically loaded or manually loaded according to the user's needs, and the driver can also be dynamically loaded. The driver of the communication card is designed to support the synchronous I/O model, and it can also be an asynchronous I/O model.
2 send data I/O routine design
In the user mode, the sending task is submitted to the kernel mode, and the I/O management program is responsible for calling the driver program. The driver program sends the IRP to the hardware. If the current transmitter is not busy, the specific sending operation is completely completed by the transmitter and the driver The program returns a flag that has already been sent by this frame. The specific sending completion result can be obtained after the sending task is completed. However, if the program submits a send task to the current device sender, the sender is processing the previous frame, then there are two methods to handle.
1 Immediate Mode: Immediately returns an error. The current device is busy and cannot be sent.
Blocking method: The I/O Manager program will dispatch the corresponding asynchronous processing routines, put the current sending task into the task queue, and return a flag: I/O hangs, the current device is busy, and the sending task submits the task queue. The driver submits the send task in the task queue to the sender when the sender is idle. After completing the sending task, set the relevant file handle to the signal state to notify the completion of the sending task.
3 Receive Data I/O Routines
Receive data routines are designed using a client/server model. Since the user's receive request and the hardware receive are not synchronized, in the design, to avoid losing data, consider creating a dedicated receive thread. In this way, synchronization of user requests, receiving threads, and communication between hardware layers must be carefully designed.
1 Communication between hardware layer and receiving thread
Synchronization of communication between the hardware layer and the receiving thread is achieved through the synchronization of event objects. The synchronous event object is usually in a no-signal state and is only signaled if it successfully receives a frame. The receiving line waits for the synchronization event object for a long time. When no data is received, the synchronization event object is blocked due to no signal state. When the hardware detects the data, the real-time interrupt service routine is responsible for setting the synchronization event object to the signal state, and the receiving thread will release the blocking. The received data on the communication card SRAM is read into the receive thread buffer queue, and then the synchronous event object is set to a no-signal state, and the receiving thread again blocks, waiting to receive the next frame of data.
2 Communication between the user layer and the receiving thread
When the user submits the receiving task, the driver's scheduler reads the buffer queue of the receiving thread, sets the flag to "empty", sets the buffer queue event to no signal state, and returns if the buffer is empty. , Then â— Immediate Mode: Immediately returns no data.
â— Blocking mode: Blocks until there is a data queue. Each buffer in the receiving queue corresponds to a notification event. If the receiving thread reads the data in the SRAM into the queue, the corresponding notification event is set to a signal state. The user request waits for the notification event, as long as there is data in the queue. In the read return, or it is blocked.
4 hard interrupt service program design
Communication cards have real-time performance in full-duplex communications, and at higher baud rates, there are many hard interrupts. In order to prevent high-priority interrupts from excessively preempting CPU time, real-time interrupt service routines and deferred procedure call methods are used in the design.
In Windows XP, each kernel function and process runs at a specific priority. Higher-priority functions or events can preempt lower priority, and vice versa. The real-time interrupt service routine ISR runs at the DIRQL level and has a high priority. It can only be preempted by more advanced hard interrupts, and does not respond to hard interrupts of the same or lower priority. Therefore, in the real-time interrupt service routine, only minimal necessary work is performed, ie, the interrupt vector is read out, and a large amount of data transfer and processing is given to the delay process DPC to complete. Because the DPC process runs at DISPATCH_LEVEL, it is a relatively low priority and it can be preempted by hard interrupts at any level. In this way, it not only ensures the timely response of hard interrupts, but also improves the performance of the program.
5 driver entry routines
Windows XP provides a default standard entry point, DriverEntry(), for each kernel-mode driver. In the design, considering that the routine runs at the PASSIVE_LEVE level, the system only runs the routine once and discards it. Therefore, important data and objects used in the driver cannot be saved in the DriverEntry() routine. A block of NoPaged memory is allocated during initialization to save. The driver's DriverEntry() routine of the communication card driver mainly accomplishes the following functions.
Read the hardware configuration information of Registry; declare I/O address, interrupt and other resources; create the device name MPSC representing the communication card, this name is visible to the WIN32 subsystem; set the entry point of the dispatch routine; allocate a NoPaged memory, Store important information; connect hard interrupts, set up interrupt service routines; initialize kernel objects such as threads, events, semaphores, DPCs; return status STATUS_SUCCESS.
If you encounter an error in the above process, you need to do the following: disconnect hard interrupts; release hardware resources; package related error messages and record them; return error messages.
6 Issues to Consider in Designing Drivers
Because the communication card has certain real-time in the application, in order to overcome the uncertainty of the interruption, improve the performance of the system, have developed the most difficult asynchronous driver program in all drivers of Windows XP system. In the kernel development of the system, asynchronous model I/O operation, the synchronization of the kernel objects is very complicated, and subtle mistakes will lead to a complete system crash. The following issues need to be noted in the design of the driver.
â— The kernel objects used in the program: events, semaphores, threads, and spin locks must all be stored in Nopaged memory. Otherwise, the system will crash.
â— In the DPC routine, if you want to access the interrupt service routine ISR program uses the port address, be sure to place the access statement in the system-provided synchronization routine, because when the DPC routine accesses the port, it is possible It is preempted by a high priority ISR routine and causes data errors.
â— The driver must not access the runtime functions of the WIN32 subsystem.
Featuring Level VI energy efficiency and meet IEC/EN/UL 62368-1 safety standards, the external AC to DC power adapters are available in variety of international different AC input blade versions for United States, Europe, Korea, U.K. and Australia, and provides 8 safety protections. The 25 to 39 wattage series wall mount power adapters follows the PC flame retardant plastic case and 3 years warranty.
25 ~ 39 Watt Wall Plug Adapters
Europe Plug Adapter,230V Ac Adapter,Variable Power Supplies,Power Supply Adapter,Pos Power Adapter
Shenzhenshi Zhenhuan Electronic Co Ltd , https://www.szzhpower.com