Changeset 183369d in rtems


Ignore:
Timestamp:
Dec 17, 1998, 6:15:39 PM (21 years ago)
Author:
Joel Sherrill <joel.sherrill@…>
Branches:
4.10, 4.11, 4.8, 4.9, master
Children:
0ed9ac7
Parents:
a54541d8
Message:

Incorporated Jeff's suggestions.

Location:
doc
Files:
12 edited

Legend:

Unmodified
Added
Removed
  • doc/bsp_howto/analog.t

    ra54541d8 r183369d  
    8181At system initialization, the analog driver's initialization entry point
    8282will be invoked.  As part of initialization, the driver will perform
    83 whatever board initializatin is required and then set all
     83whatever board initialization is required and then set all
    8484outputs to their configured initial state.
    8585
     
    159159This is one of the IOCTL functions supported by the I/O control
    160160device driver entry point.  When this IOCTL function is invoked,
    161 the last value written to the specified output word along with
    162 a timestamp of when the last write was performed.
     161the following information is returned to the caller:
    163162
     163@itemize @bullet
     164@item last value written to the specified DAC
     165@item timestamp of when the last write was performed
     166@end itemize
     167
  • doc/bsp_howto/clock.t

    ra54541d8 r183369d  
    1919
    2020@section Clock Driver Global Variables
     21
     22This section describes the global variables expected to be provided by
     23this driver.
    2124
    2225@subsection Major and Minor Number
  • doc/bsp_howto/console.t

    ra54541d8 r183369d  
    3232@end itemize
    3333
    34 We may think that one need two serial drivers to deal with those two types
     34One may think that two serial drivers are needed to handle these two types
    3535of data, but Termios permits having only one driver.
    3636
     
    9191This mode is not the most efficient way to utilize the UART. But
    9292polled mode is usually necessary when one wants to print an
    93 error message in the event of a fatal error such as al fatal error
     93error message in the event of a fatal error such as a fatal error
    9494in the BSP.  This is also the simplest mode to
    9595program.  Polled mode is generally preferred if the serial port is
     
    125125
    126126@example
    127 This figure needs to be inserted in this document.
     127Figure not included in this draft
    128128@end example
    129129
  • doc/bsp_howto/discrete.t

    ra54541d8 r183369d  
    179179This is one of the IOCTL functions supported by the I/O control
    180180device driver entry point.  When this IOCTL function is invoked,
    181 the last value written to the specified output word along with
    182 a timestamp of when the last write was performed.
     181the following information is returned to the caller:
    183182
     183@itemize @bullet
     184@item last value written to the specified output word
     185@item timestamp of when the last write was performed
     186@end itemize
     187
  • doc/bsp_howto/init.t

    ra54541d8 r183369d  
    9696invoking the shared routine @code{boot_card()}.
    9797
     98The label (symbolic name) associated with the starting address of the
     99program is typically called @code{start}.  The start object file
     100is the first object file linked into the program image so it is insured
     101that the start code is at offset 0 in the @code{.text} section.  It is
     102the responsibility of the linker script in conjunction with the
     103compiler specifications file to put the start code in the correct location
     104in the application image.
     105
    98106@subsection boot_card() - Boot the Card
    99107
     
    164172
    165173One of the most important functions performed by this routine
    166 is determining where the RTEMS Executive Work Space is to be
     174is determining where the RTEMS Workspace is to be
    167175located in memory.  All RTEMS objects and task stacks will be
    168176allocated from this Workspace.  The RTEMS Workspace is distinct
    169 from the application heap used for @code{malloc()}.
    170 
    171 Many BSPs place this area at the end of RAM although this is
     177from the application heap used for @code{malloc()}.  Many BSPs
     178place the RTEMS Workspace area at the end of RAM although this is
    172179certainly not a requirement.
    173180
  • doc/bsp_howto/linkcmds.t

    ra54541d8 r183369d  
    2020An embedded systems programmer must be much more aware of the
    2121placement of their executable image in memory than the average
    22 "normal" programmer.  A program destined to be embedded as well
     22applications programmer.  A program destined to be embedded as well
    2323as the target system have some specific properties that must be
    2424taken into account. Embedded machines often mean average performances
     
    4444an embedded program is made of sections.  It is the responsibility of
    4545the application programmer to place these sections in the appropriate
    46 place in target memory.  To make this clearer, if using COFF on the
    47 Motorola m68k family of microprocessors, the following sections will
    48 be present:
     46place in target memory.  To make this clearer, if using the COFF
     47object file format on the Motorola m68k family of microprocessors,
     48the following sections will be present:
    4949
    5050@itemize @bullet
     
    418418Step 3 shows the final executable image as it logically appears in
    419419the target's non-volatile program memory.  The board initialization
    420 code will copy the initialized data initial values (which are stored in
     420code will copy the ""copy of @code{.data} section" (which are stored in
    421421ROM) to their reserved location in RAM.
    422422
  • doc/bsp_howto/makefiles.t

    ra54541d8 r183369d  
    88
    99@chapter Makefiles
     10
     11This chapter discusses the Makefiles associated with a BSP.  It does not
     12describe the process of configuring, building, and installing RTEMS. 
     13This chapter will not provide detailed information about this process.
     14Nonetheless, it is important to remember that the general process consists
     15of three parts:
     16
     17@itemize @bullet
     18@item configure
     19@item build
     20@item install
     21@end itemize
     22
     23During the configure phase, a number of files are generated.  These
     24generated files are tailored for the specific host/target combination
     25by the configure script.  This set of files includes the Makefiles used
     26to actually compile and install RTEMS.
     27
     28During the build phase, the source files are compiled into object files
     29and libraries are built.
     30
     31During the install phase, the libraries, header files, and other support
     32files are copied to the BSP specific installation point.  After installation
     33is successfully completed, the files generated by the configure and build
     34phases may be removed.
    1035
    1136@section Makefiles Used During The BSP Building Process
     
    89114CPU dependent support code or provide its own.
    90115
    91 This Makefile makes use of a neat construct in @b{GNU make} to pick
    92 up the required components:
     116This Makefile makes use of the @code{foreach} construct in @b{GNU make}
     117to pick up the required components:
    93118
    94119@example
  • doc/bsp_howto/nvmem.t

    ra54541d8 r183369d  
    6666non-volatile memory.
    6767The following is a list of the type of information normally required
    68 to configure each area of non-volatile memory
     68to configure each area of non-volatile memory.
    6969
    7070@table @b
     
    119119
    120120@item Partitions
    121 is the address of table that contains an entry to describe each
     121is the address of the table that contains an entry to describe each
    122122partition in this area.  Fields within each element of this
    123123table are defined as follows:
     
    144144whatever initializatin is required on each non-volatile memory area.
    145145
    146 The discrete I/O driver may register devices name for memory
     146The discrete I/O driver may register device names for memory
    147147partitions of particular interest to the system.  Normally this
    148148will be restricted to the device "/dev/nv_memory" to indicate
  • doc/bsp_howto/rtc.t

    ra54541d8 r183369d  
    9090for Vendor A's RTC chip would need to return TRUE if the
    9191board was a first generation one.  The @code{deviceProbe}
    92 routines are very board dependent.
     92routines are very board dependent and must be provided by
     93the BSP.
    9394
    9495@section setRealTimeToRTEMS
  • doc/bsp_howto/target.t

    ra54541d8 r183369d  
    5555
    5656This class of code provides a reusable library of peripheral device
    57 drivers which can be tailored easily to a particular board.  This
    58 reusable library provides software objects which correspond to standard
    59 controllers.  Just as the hardware engineer choose a standard controller
    60 when designing a board, the goal of this library is to let the software
    61 engineer do the same thing.
     57drivers which can be tailored easily to a particular board.  The
     58libchip library is a collection of reusable software objects that
     59correspond to standard controllers.  Just as the hardware engineer
     60chooses a standard controller when designing a board, the goal of
     61this library is to let the software engineer do the same thing.
    6262
    6363The source code for the reusable peripheral driver library may be found
     
    9191If the BSP does not exist and the board's CPU model is supported, then
    9292examine the reusable chip library and existing BSPs for a close match. 
    93 This will help reduce the development effort required.  It is often
    94 possible to copy existing components in the reusable chip library or
    95 device drivers from BSPs from different CPU families as the starting
    96 point for a new device driver.
     93Other BSPs and libchip provide starting points for the development
     94of a new BSP.  It is often possible to copy existing components in
     95the reusable chip library or device drivers from BSPs from different
     96CPU families as the starting point for a new device driver.
     97This will help reduce the development effort required. 
    9798
    9899If the board's CPU family is supported but the particular CPU model on
  • doc/bsp_howto/timer.t

    ra54541d8 r183369d  
    1616impact of specific minor changes.
    1717
    18 The gen68340 BSP also uses the TImer Driver to support a high performance
     18The gen68340 BSP also uses the Timer Driver to support a high performance
    1919mode of the on-CPU UART.
    2020
  • doc/networking/driver.t

    ra54541d8 r183369d  
    1818driver.  The source code for this driver is located in the
    1919@code{c/src/lib/libbsp/m68k/gen68360/network} directory in the RTEMS
    20 source code distribution.  You should have a copy of this driver at
    21 hand when reading the following notes.
     20source code distribution.  Having a copy of this driver at
     21hand when reading the following notes will help significantly.
    2222
    2323@section Learn about the network device
    2424
    25 Before starting to write the network driver you need to be completely
     25Before starting to write the network driver become completely
    2626familiar with the programmer's view of the device.
    2727The following points list some of the details of the
     
    3535
    3636@item If the device uses DMA, is it capable of forming a single
    37 outtoing packet from multiple fragments scattered in separate
     37outgoing packet from multiple fragments scattered in separate
    3838memory buffers?
    3939
     
    7575@section Understand the network scheduling conventions
    7676
    77 When writing code for your driver transmit and receive tasks you must
     77When writing code for the driver transmit and receive tasks,
    7878take care to follow the network scheduling conventions.  All tasks
    7979which are associated with networking share various
     
    8181of these structures the tasks
    8282execute only when they hold the network semaphore (@code{rtems_bsdnet_semaphore}).
    83 Your transmit and receive tasks must abide by this protocol which means you must
    84 be careful to avoid `deadly embraces' with the other network tasks.
    85 A number of routines are provided to make it easier for your code
    86 to conform to the network task scheduling conventions.
     83The transmit and receive tasks must abide by this protocol.  Be very
     84careful to avoid `deadly embraces' with the other network tasks.
     85A number of routines are provided to make it easier for the network
     86driver code to conform to the network task scheduling conventions.
    8787
    8888@itemize @bullet
     
    9191
    9292This function releases the network semaphore.
    93 Your task must call this function immediately before
     93The network driver tasks must call this function immediately before
    9494making any blocking RTEMS request.
    9595
     
    9797
    9898This function obtains the network semaphore.
    99 If your task has released the network semaphore to allow other
    100 network-related tasks to run while your task blocks you must call this
    101 function to reobtain the semaphore immediately after the return from the
     99If a network driver task has released the network semaphore to allow other
     100network-related tasks to run while the task blocks, then this function must
     101be called to reobtain the semaphore immediately after the return from the
    102102blocking RTEMS request.
    103103
    104104@item @code{rtems_bsdnet_event_receive(rtems_event_set, rtems_option, rtems_interval, rtems_event_set *)}
    105 Your task should call this function when it wishes to wait for an event.
    106 This function releases the network semaphore,
     105The network driver task should call this function when it wishes to wait
     106for an event.  This function releases the network semaphore,
    107107calls @code{rtems_event_receive} to wait for the specified event
    108108or events and reobtains the semaphore.
     
    111111@end itemize
    112112
    113 @section Write your driver attach function
     113@section Write the Driver Attach Function
    114114The driver attach function is responsible for configuring the driver
    115115and making the connection between the network stack
     
    186186
    187187
    188 @section Write your driver start function.
     188@section Write the Driver Start Function.
    189189This function is called each time the network stack wants to start the
    190190transmitter.  This occures whenever the network stack adds a packet
     
    197197
    198198
    199 @section Write your driver initialization function.
     199@section Write the Driver Initialization Function.
     200
    200201This function should initialize the device, attach to interrupt handler,
    201202and start the driver transmit and receive tasks.  The function
     
    213214Note that the network stack may call the driver initialization function more
    214215than once.
    215 Make sure you don't start multiple versions of the receive and transmit tasks.
    216 
    217 
    218 
    219 @section Write your driver transmit task.
     216Make sure multiple versions of the receive and transmit tasks are not accidentally
     217started.
     218
     219
     220
     221@section Write the Driver Transmit Task
     222
    220223This task is reponsible for removing packets from the driver send queue and sending them to the device.  The task should block waiting for an event from the
    221224driver start function indicating that packets are waiting to be transmitted.
     
    225228
    226229
    227 @section Write your driver receive task.
     230@section Write the Driver Receive Task
    228231This task should block until a packet arrives from the device.  If the
    229232device is an Ethernet interface the function @code{ether_input} should be called
     
    235238
    236239
    237 @section Write your driver interrupt handler.
     240@section Write the Driver Interrupt Handler
    238241A typical interrupt handler will do nothing more than the hardware
    239242manipulation required to acknowledge the interrupt and send an RTEMS event
     
    244247
    245248
    246 @section Write your driver ioctl function.
     249@section Write the Driver IOCTL Function
    247250This function handles ioctl requests directed at the device.  The ioctl
    248251commands which must be handled are:
     
    276279
    277280
    278 @section Write Your Driver Statistic-Printing Function
     281@section Write the Driver Statistic-Printing Function
    279282This function should print the values of any statistic/diagnostic
    280 counters your driver may use.  The driver ioctl function should call
     283counters the network driver may use.  The driver ioctl function should call
    281284the statistic-printing function when the ioctl command is
    282285@code{SIO_RTEMS_SHOW_STATS}.
Note: See TracChangeset for help on using the changeset viewer.