We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
How does one enable line wrapping in the UVision editor? I am unable to locate a control in the dialogs, and searching the help for "wrap" does not yeild anything related. Thanks.
ALL FILES/MODULES Start with this header... ALL of them! (The Module Description get replaced with module specific information)
/* ________________________________________________________________________ ****************************************************************************. * | ENVIRONMENT | * Copyright (c) 2010 |------------------------| * ACME Corporation | IDE: Kiel | * 1234 Main Street | Tool: uVision 4 | * Springfield, ST 123456 | Rev: 4.11 MDK-ARM | * (800) 555-1212 Ext. 1234 |------------------------| * | Lang: ANSI "C" | * MODULE NAME filename.ext | Arch: Harvard | * MODULE VERSION 0.00 | Pragmas: None | * | Caveats: None | * APPLICATION [Project Name] | Macros: None | * | Kernel: None | * |------------------------| * | CPU: [processor] | * SRS Document EP 123 v1.00 | CLK: [base MHz ] | * SDRL No. EP 456 v1.01 | PPM: [Osc tol ] | * DRAWING No. DWG-123456 Rev - | MIPS: [ MIPS ] | * | CODE: [code size] | * JOB NUMBER 2010-0404 | xData: [external ] | * WBS ELEMENT -003 | iData: [internal ] | * | bData: [banked ] | *--------------------------------------------------+------------------------| * Environment Notes: | Executables: | * | NAMEIF.HEX (EPROM) | * Capable of being batch-file driven and is not | NAMEIF. (DEBUG) | * dependant upon compiler/assembler/linker | (AOMF debugging) | * brand or version provided the code is built |------------------------| * using ANSI "C" standards and ARM7 core | Make/Support Files: | * directives which contain ANSI "C" Libraries. | | * | ProjX.BAT (cmd line) | * All files required are contained within the | ProjX.LNK (lnk ctrl) | * project directory with the exception of the | | * linked library files. (fix that later) | ProjX.SYM (Symbols) | * | ProjX.MAP (Map file) | * | | *--------------------------------------------------^------------------------' * * MODULE DESCRIPTION: * * Generally "Comments" are either Strategic or Tactical in nature. * While some comments can be categorized as Orientation. * * Strategic comments describe what a section of code is supposed to * accomplish. Strategic comments should be placed before the code * section that implements the task. * * Tactical comments describes the specifics on how the code is * implementing a task. Typically these tactical comments are on an * end-of -line basis. Tactical comments serve to enlighten the * non-obvious behavior or method implemented, and not a re-statement * of what the code performs: * * Orientation and Strategic are closely related, but they do differ. * Orientation comments provide the reader with a wider conceptual view * of the code module. Orientation comments can be information about * the system's environment like the OS, CPU, Memory, IDE, Versions, * etc. While Strategic and Tactical are the dominant forms, * Orientation should be still be contained in all source code modules. * * The over-use of tactical comments will result in source code that * takes too long to read, and begins to devalue and hide the * worth-while comments. Strategic comments should be the primary and * dominant form of commenting source code. * * Tactical comments should be as detailed as needed to inform the * programmer. The common used for Tactical comments is when * describing the side-effects of code implementation or when the code * performs something that is not obvious to the standard or novice * programmer. Always write on a level that is explanatory the reader, * and never assume the reader is as competent as you think you are. * * Tactical comments in "C" typically use the double-slash notation, * while the Strategic comments are flower-boxed. Orientation comments * are typically found at the top of the module. * * - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - * * All code meets high relibality standards for the military/aerospace * and automotive industries. The code is compliant with such standards * with only minor exceptions. (e.g. certified" IDEs/tools, and other * practices in which I have deemed should not have been banned, but * merely restricted---like offsetof ) * * Additional levels of the Hi-Rel practices shall be implemented only * if there is a need and/or it is cost effective. * * ---------------------------------------------------------------------- * WARNING - This document contains technical data whose export is * restricted by the Arms Export Control Act (Title 22, U.S.C., Sec 2751 * et seq.) or the Export Administration Act of 1979, as amended, Title * 50 U.S.C., App 2401 et seq. Violation of these export laws are subject * to severe criminal penalties. Dissemination in accordance with * provisions of DOD Directive 5230.25 (Reference C). * ---------------------------------------------------------------------- * * ===================================================================== * === === === === * === v0.00 === FILE UPDATE AND REVISION HISTORY === 01-Jan-10 === * === === === === * ===================================================================== * * *Version [Description of change] DD-Mmm-YY Author/Engineer *------- -------------------------------------- --------- ----------------- * v0.00 <Original Write> 01-Jan-10 Cpt. Vince Foster * * ___________________________________________________________________________ */
Perfected taste
--Cpt. Vince Foster 2nd Cannon Place Fort Marcy Park, VA