After getting your, it is time to getting started with MCUXpresso IDE. In this Step by Step tutorial we will go through the process of creating projects in MCUXpresso IDE for Cortex-M series Microcontrollers by NXP(Founded by Philips) based on CMSIS (Cortex Microcontroller Software Interface Standard). MCUXpresso is a derivative of LPCXpresso and Kinetis Design Studio IDEs with combined support for LCP and Kinetis MCUs.
The IDE comes with integrated arm-gcc compiler and all the necessary debug drivers like LPC-Link, etc., to help you getting started with rapid embedded systems application development using our LPC17xx boards.This guide is applicable for NXP’s Cortex-M MCU families like LPC800(e.g. LPC81x), LPC1100(e.g. LPC111x), LPC1300(e.g.
LPC134x), LPC1700(e.g. LPC176x), LPC4300, etc. After creating MCUXpresso projects with CMSIS, the IDE will automatically add all the necessary startup files(for initializing MCU), headers and a project source file(C/C) depending on the settings we choose while creating the project.Download the IDEYou can download and install the IDE from the links as shown below:. You can always check the latest version @After download, install from the setup file using default settings. During installation it will also install debug probe drivers which is also used to flash the code.
Just click Yes/Next/Accept if its asks for driver install confirmation. By default the IDE will install to location – C:NXPMCUXpressoIDE.After install, follow the steps below to create a new project for either the LPC1768 or LPC1769. We have created two sample projects, one for our and another for our. The following documentation refers primarily to the LPC1769, but the project creation is identical for the LPC1768, and we have marked the sections where differences apply.Step by Step TutorialStep 1: When you start MCUXpresso, it will first ask for a path to create a workspace.
A workspace is like a master directory with settings and can contain many individual projects, more like a general “Projects” folder. When prompted enter the path where you want to create your workspace:You can choose any path, but we recommend to go with the default settings. Please be aware that the IDE allows you to create several workspaces and to switch between them. In fact, we recommend to use this feature to separate projects in a logical order that fits your needs.Step 2: In this step, we will create a new project that fits the requirements for the LPC1768 or LPC1769. The IDE will launch right after installation. Now, click on the 'New Project.'
Link in the 'Quickstart' panel (bottom left view of the IDE):Step 3: The project wizard will open as shown below. Select the target MCU (1768 or LPC1769; our example refers to the LPC1769), the click Next:Note: The wizard will show a number of board images on the right, but their appearance is of no consequence for our project settings.Step 4: Select 'C Project,' the click Next.Note: Our initial code examples are written in 'C'. If and when the need arises, you can always open a new project with the 'C' settings.Step 5: Enter a suitable name for your project, then click Next. In this example, we chose 'LCP1769Template' (use 'LPC1768Template' for the LPC1768 board), and we recommend following this naming convention.
In further posts to follow, we will copy the template code and modify it to suit the chosen application.Step 6: In this step, we install the CMSIS for the LPC1768 and LPC1769. However, before you continue, assure that the CMSIS is not already installed.If you see a reference to CMSISCORE-LPC17xx in the IDE's project window as shown below, you should skip to step 7.In order to install the CMSIS library, click on the Import button.A new “Import” window will appear.
Click on “Browse” under “Project archive (zip)”. Then select the required CMSIS library zip file for your MCU family.
Chapter 1. IntroductionParallelizing compiler technology is most mature for the Fortran 77language. The simplicity of the language without pointers or user-definedtypes makes it easy to analyze and to develop many advanced compilerpasses. By contrast, parallelization technology for modern languages, suchas Java, C, or even C, is still in its infancy. When trying to engage insuch research, we were faced with a serious challenge. We were unable tofind a parallelizing compiler infrastructure that supports interproceduralanalysis, exhibits state-of-the-art software engineering techniques toachieve shorter development time, and which would allow us to compilelarge, realistic applications. However, we feel these properties are ofparamount importance. They enable a compiler writer to develop 'productionstrength' passes.
Production strength passes, in turn, can work in thecontext of the most up-to-date compiler technology and lead to compilerresearch that can be evaluated with full suites of realistic applications.Many people have observed and criticized the lack of such thoroughevaluations in current research papers. The availability of an easy-to-usecompiler infrastructure would help improve this situation significantly.Hence, continuous research and development in this area are among the mostimportant tasks of the compiler community. Cetus contributes to thiseffort. GCCGCC is one of the most robust compiler infrastructures availableto the research community.
GCC generates highly-optimized code for avariety of architectures, which rivals in many cases the qualitygenerated by the machine vendor's compiler. Its open-source distributionand continuous updates make it attractive. However, GCC was not designedfor source-to-source transformations. Most of its passes operate on thelower-level RTL representation. Only recent versions of GCC (version 3.0onward) include an actual syntax tree representation, which has beenused in Purdue class projects for implementing a number of compilerpasses.
Other limitations are GCC compiles one source file at a time,performs separate analysis of procedures, and requires extensivemodification to support interprocedural analysis across multiplefiles.The most difficult problem faced by the students was that GCC doesnot provide a friendly API for pass writers. The API consists largely ofmacros. Passes need to be written in C and operations lack logicalgrouping (classes, namespaces, etc), as would be expected from acompiler developed in an object-oriented language.GCC's IR has an ad-hoc type system, which is not reflected in itsimplementation language (C). The type system is encoded into integersthat must be decoded and manipulated by applying a series of macros. Itis difficult to determine the purpose of fields in the IR from lookingat the source code, since in general every field is represented by thesame type. This also makes it difficult for debuggers to providemeaningful information to the user.Documentation for GCC is abundant.
The difficulty is that thesheer amount easily overwhelms the user. Generally, we have found thatthere is a very steep learning curve in modifying GCC, with a big timeinvestment to implement even trivial transformations.The above difficulties were considered primarily responsible forthe students that used GCC proceeding more slowly than those creating anew compiler design. The demonstrated higher efficiency ofimplementation was the ultimate reason for the decision to pursue thefull design of Cetus. PolarisThe Polaris compiler, which we have co-developed in prior work,was an important influence on the design of our new infrastructure.Polaris is written in C and operates on Fortran 77 programs.
So far,no extensions have been made to handle Fortran 90, which provides auser-defined type system and other modern programming language features.Polaris' IR is Fortran-oriented and extending it to other languageswould require substantial modification.Another factor we considered was that Polaris was written beforethe Standard Template Library (C STL) became available, so it includesits own container implementations. It uses a pre-ISO dialect of Cwhich now seems unusual to programmers and causes many warnings (andsometimes errors) with current compilers. Both aspects limit itsportability to other platforms.In general, Polaris is representative of compilers that aredesigned for one particular language, serve their purpose well, but aredifficult to extend. Cetus should not be thought of as 'Polaris for C'because it is designed to avoid that problem.
However, there are stillseveral Polaris features that we wanted to adopt in Cetus. Polaris' IRcan be printed in the form of code that is similar to the sourceprogram.
This property makes it easy for a user to review and understandthe steps involved in Polaris-generated transformations. Also, Polaris'API is such that the IR is in a consistent state after each call. Commonmistakes that pass writers make can be avoided in this way. SUIFThe SUIF compiler is part of the National Compiler Infrastructure(NCI), along with Zephyr, whose design began almost a decade ago. Theinfrastructure was intended as a general compiler framework for multiplelanguages.
It is written in C, like Polaris, and the currentlyavailable version supports analysis of C programs. SUIF 1 is aparallelizing compiler and SUIF 2 performs interproceduralanalysis.Both SUIF and Cetus fall into the category of extensiblesource-to-source compilers, so at first SUIF looked like the naturalchoice for our infrastructure. Three main reasons eliminated our pursuitof this option. The first was the perception that the project is nolonger active - the last major release was in 2001 and does not appearto have been updated recently. The second reason was, although SUIFintends to support multiple languages, we could not find complete frontends other than for C and an old version of Java. Work began on frontends for Fortran and C, but they are not available in the currentrelease. Hence, as is, SUIF essentially supports a single language, C.Finally, we had a strong preference for using Java as the compilerimplementation language.
Java offers several features conducive to goodsoftware engineering. It provides good debugging support, highportability, garbage collection (contributing to the ease of writingpasses), and its own automatic documentation system. These factsprompted us to pursue other compiler infrastructures. Chapter 3. LicenseIn recent years, there has been an explosion in the number ofopen-source licenses, and we do not wish to contribute further to thatproblem, but this was the only license upon which all involved partieswere able to agree. We suggest that you do not use this license forprojects that do not involve Cetus.The Cetus License is a modified Artistic License, similar to thePerl Artistic License. Artistic Licenses are generally approved, althoughthis specific license has not been submitted to OSI. You can view thelicense on the download page.
Data Dependence AnalysisData dependence analysis is a memory disambiguation techniquethrough which a compiler tries to establish dependence relations betweenscalar variables or between array accesses in a program. The existenceof dependences or of independence, provides essential information forfurther analysis and legal transformations such as loop parallelization,loop tiling, loop interchange and so on.Cetus implements an array data dependence testing framework thatincludes loop-based affine array-subscript testing. The focus of thisimplementation is towards automatic loop parallelization. This frameworkacts as a wrapper around the conventional data-dependence test; wecurrently use the Banerjee-Wolfe inequalities (Optimizing Supercompilersfor Supercomputers, Michael Wolfe) as our default dependence test. Thewrap-around framework provides Cetus with the flexibility of includingother dependence tests, thereby improving the scope of ourimplementation; (we provide the Range test since v1.1).
A whole programdata-dependence graph provides the necessary output information and theinterface, to enable subsequent analyses and transformations.Initially, the algorithm traverses all loops in the program IR andeach loop and its inner nest are tested for eligibility. The eligibilitycheck allows us to broaden/narrow the scope of the implementation.Currently, the algorithm includes the following checks.Canonical loops (Fortran DO loop format): This implements acanonical check for the loop initial assignment expression, theloop condition and the loop index increment statement.Function calls are supported with simple analysis. Knownfunction calls without side-effects can be added to a list ofparallelizable calls (e.g. System calls). We also support simpleinterprocedural side-effect analysis.Control flow modifiers are not allowed (break statements canbe handled specially for parallelization).The loop increment must be an integer constant (symbolicincrements are handled using range analysis)Loop information for all eligible loops is collected and storedinternally for further dependence analysis.SYMBOLIC ANALYSIS SUPPORT: The Data dependence framework has addedsubstantial support for using range analysis in the case of symbolicvalues.
Range information is used to determine loop bounds and loopincrements during eligibility testing. In the case of symbolic bounds,range information is used conservatively to test the maximum possiblerange of values. Symbolic information is also used to simplify arraysubscripts before they are provided to the Banerjee-Wolfe inequalitiesfor testing. This symbolic support thus adds great value to dependenceanalysis, especially to the Banerjee test.The algorithm then tests all array accesses within an entire loopnest for independence.
Arrays identified by AliasAnalysis as aliased arecurrently assumed to be dependent in all directions for the enclosingloops. Pairs of array accesses such that at least one of them is a writeaccess are provided as input to the dependence test which returns a setof direction vectors corresponding to the common enclosing loop nest forthe pair of accesses (if independence could not be proved). Thesedirection vectors are then used to build a Data Dependence Graph (DDG)for the loop nest.The data dependence graph for each loop nest becomes a part of alarger whole program based graph which is attached to the Program IRobject upon completion of dependence testing. This implementation isnew, and substantially different from release v1.0. For a user lookingto use dependence information in an analysis or transformation pass, areference to this DDG must be obtained from the Program object.
Acomprehensive API is then available via DDGraph (see Cetus javadoc) toextract dependence information related to loops. This implementation hasthe advantage that dependence testing is run fewer times and a commonAPI is available to pass users. NOTE: However, it is the pass writer'sresponsibility that after a transformation on the IR has been performed,dependence testing must be re-run in order to create an up-to-dateversion of the dependence graph which automatically replaces itself inthe Program IR. Alias AnalysisAlias analysis is a technique used to identify sets of programvariable names that may refer to the same memory location during programexecution. In C programs, aliases are created through the use ofpointers as well as reference parameter passing. Disambiguation ofvariable names can be crucial to the accuracy and the effectiveness ofother analyses and transformations performed by the compiler.
Acompile-time alias analysis would either be flow and/or contextsensitive or neither of the two. Cetus provides advanced flow-senstivityand limited context-sensitivity when generating aliasinformation.Advanced alias information is now provided in Cetus using theresult of interprocedural points-to analysis.
This information isflow-sensitive and hence, uses statement information. The result of thepoints-to analyzer is a map from a Statement to points-to informationthat exists right before the statement is executed. Pointerrelationships are used by the Alias Analysis pass to create alias sets,which are obtained through a unification-based approach.Alias information can be accessed by pass writers using a simpleAPI. The presence of alias can be checked using functions that return aboolean value, after checking for aliasing between symbols. Refer to theHIR documentation for more information on symbols. Separate ParsersParsing intentionally was separated from the IR-building methodsin the high-level interface so that other front ends could be addedindependently.
Some front ends may require more effort than others.For example, writing a parser for C is a challenge because itsgrammar does not fit easily into any of the grammar classes supportedby standard generators. The GNU C compiler was able to use anLALR(1) grammar, but it looks nothing like the ISO C grammar.
If anyrules must be rearranged to add actions in a particular location, itmust be done with extreme care to avoid breaking the grammar. Anotherproblem is C has much more complicated rules than C as far asdetermining which symbols are identifiers versus type names, requiringsubstantial symbol table maintenance while parsing. Handling Pragmas and CommentsPragmas and Comments are identified during scanning as'Annotation'-type IR. These are inserted by the parser into the IR asPreAnnotation(s). Comments are inserted as they appear in the program,except for when they appear in the middle of another IR construct,such as an AssignmentStatement.
In this case, they appear in theoutput before the corresponding statement. For comments that are atthe end of code on the same line, they appear AFTER the same line inthe output.Since v1.1, Cetus adopts a new Annotation implementation inorder to simplify the IR associated with different types ofannotations as we begin to accommodate more types. Once PreAnnotationsare parsed in and stored in the IR, the AnnotationParser convertsthese into specific IR as described in the Annotations section laterin this manual. PragmaAnnotations can be associated with specificstatements, knowing their semantics, and hence this is doneautomatically by Cetus thus allowing movement of annotations withcorresponding IR during transformations. However, in the case ofCommentAnnotations and other possibly new annotations interpreted ascomments, Cetus can only store them as stand-alone annotations thuspreventing their movement with corresponding IR.More details about the exact Annotation implementation is foundin the IR section.
Intermediate RepresentationCetus' IR contrasts with the Polaris Fortran translator's IR inthat it uses a hierarchical statement structure. The Cetus IR directlyreflects the block structure of a program. Polaris lists the statementsof each procedure in a flat way, with a reference to the outer statementbeing the only way for determining the block structure.
There are alsoimportant differences in the representation of expressions, whichfurther reflects the differences between C and Fortran. The Polaris IRincludes assignment statements, whereas Cetus represents assignments inthe form of expressions. This corresponds to the C language's feature toinclude assignment side effects in any expression.The IR is structured such that the original source program can bereproduced, but this is where source-to-source translators face anintrinsic dilemma. Keeping the IR and output similar to the input willmake it easy for the user to recognize the transformations applied bythe compiler. On the other hand, keeping the IR language independentleads to a simpler compiler architecture, but may make it impossible toreproduce the original source code as output. In Cetus, the concept ofstatements and expressions are closely related to the syntax of the Clanguage, facilitating easy source-to-source translation.
However, thedrawback is increased complexity for pass writers (since they must thinkin terms of C syntax) and limited extensibility of Cetus to additionallanguages. That problem is mitigated by the provision of severalabstract classes, which represent generic control constructs. Genericpasses can then be written using the abstract interface, while morelanguage-specific passes can use the derived classes. We feel it isimportant to work with multiple languages at an early stage, so that ourresult is not simply a design that is extensible in theory but also inpractice. Toward this goal, we have begun adding a C front end andgeneralizing the IR so that we can evaluate these design trade-offs.Other potential front ends are Java and Fortran 90. Class Hierarchy DesignOur design goal was a simple IR class hierarchy easilyunderstood by users. It should also be easy to maintain, while beingrich enough to enable future extension without major modification.
Thebasic building blocks of a program are the translation units, whichrepresent the content of a source file, and procedures, whichrepresent individual functions. Procedures include a list of simple orcompound statements, representing the program control flow in ahierarchical way. That is, compound statements, such as IF-constructsand FOR-loops include inner (simple or compound) statements,representing then and else blocks or loop bodies, respectively.Expressions represent the operations being done on variables,including the assignments to variables. Relationship Between Grammar and IRWhen designing any class hierarchy, some general principles arefollowed.
Famous Installation Artist
The main principle is that a derived class satisfies anis a relationship with its parent, such thatthe data and methods of the parent make sense in the context of thechild. This principle is followed to some extent in Cetus, but itwould be more accurate to say that a derived class can appear in thegrammar wherever its parent can appear.There is a distinction between the class hierarchy and thesyntax tree. For example, in the syntax tree, the parent of aTranslationUnit is a Program, however neither TranslationUnit norProgram have a parent in the class hierarchy. Syntax Tree InvariantsOne important aspect that makes an infrastructure useful isproviding a good set of tools to help debug future compiler passes.Cetus provides basic debugging support through the Java language,which contains exceptions and assertions as built-in features. Cetusexecutes within a Java virtual machine, so a full stack traceincluding source line numbers is available whenever an exception iscaught or the compiler terminates abnormally.Such error reporting is useless unless the IR is designed toprevent programmers from corrupting the program representation. Inother words, there must be a way of detecting the state of the IR isnot as it should be, in order to report an error. To provide errorchecking and detect common errors by pass writers, the Cetus IRmaintains several invariants.
Violating one of the invariants belowwill probably result in an exception, to theextent that it is possible for Cetus to recognize what you havedone.Invariant.CetusAnnotation (#pragma cetus.).OmpAnnotation (#pragma omp.).CommentAnnotation (e.g./).CodeAnnotation (Raw printing)Annotations can be attached to existing IR where the semanticsdefine so or can be inserted as stand-alone IR. In the above mentionedsubclasses, Cetus and Omp Annotations have specific semantics andhence if present in the input source, they are attached tocorresponding source IR. However, this is not possible for Comments asit is difficult to determine their association with the IR except forin certain cases (which are not handled currently). Hence, allComments and other annotations are inserted as stand-alone.Annotations that need to be attached to existing IR are storedas member objects of this Annotatable IR(Statements and Declarations), the new API for manipulating these ishence available through Annotatable. Standalone annotations areenclosed in special IR such asAnnotationDeclaration orAnnotationStatement (note that AnnotationStatementis different from previous release).
The API in Annotatable.COMPLETELY REPLACES. previous functionality provided throughTools.java.See the latest Cetus tutorial at forexamples on how to use the new Annotation and Annotatable API duringanalysis and transformations. Expression SimplifierExpression simplifier supports normalization and simplification ofexpressions. It internally transforms a given expression to a normalizedform so that each operand of a commutative and associative operation islocated at the same height in the tree representation; in other words,it converts a binary tree to a n-ary tree. This internal representationmakes the simplification algorithm easier and the result of thesimplification is converted back to the original internal representationof Cetus.Like its predecessor Polaris, a key feature of Cetus is theability to reason about the represented program in symbolic terms. Forexample, compiler analyses and optimizations at the source level oftenrequire the expressions in the program to be in a simplified form. Aspecific example is data dependence analysis that collects thecoefficients of affine subscript expressions, which are passed to theunderlying data dependence test package.
Contemporary Installation Artists
Cetus has functionalities thatease the manipulation of expressions for pass writers. The followingexample shows how to invoke the simplifier. The simplifier returns a newcopy of the original expression that was converted to a normalizedform.import cetus.hir.Expression e =.e = Symbolic.simplify(e);It is also possible for users to invoke individual simplificationtechnique for their own purposes. The following examples show thefunctionality of the individual simplification technique. See thejavadoc page or the source code to learn how to invoke each techniqueindividually.1+2.a+4-a - 5+a (folding)a.(b+c) - a.b+a.c (distribution)(a.2)/(8.c) - a/(4.c) (division). PrintingA major complaint about early versions of Cetus was that theprinting of IR was not flexible enough. To solve this problem, we havemade printing completely customizable by the pass writer.
Cetus Compiler Installation Artists List
Nearly allclasses implement a Printable interface, which meansthey provide a print method for printing themselvesas source code. By default, this print method calls astatic method of the same class, called defaultPrint.The call is made by invoking a Java Method object,which is similar to a function pointer in C. TheMethod object can be changed by callingsetPrintMethod and passing it a different printingroutine. SetPrintMethod allows a pass writer tochange how one particular object prints itself. If the pass writernotices that they are calling this method frequently for the same typeof object, then it may be easier to callsetClassPrintMethod, a static method which causes allnewly created objects of a particular class to use the provided printingroutine.