This document provides usage information about the LLVM makefile system. While loosely patterned after the BSD makefile system, LLVM has taken a departure from BSD in order to implement additional features needed by LLVM. Although makefile systems such as automake were attempted at one point, it has become clear that the features needed by LLVM and the Makefile norm are too great to use a more limited tool. Consequently, LLVM requires simply GNU Make 3.79, a widely portable makefile processor. LLVM unabashedly makes heavy use of the features of GNU Make so the dependency on GNU Make is firm. If you're not familiar with make, it is recommended that you read the GNU Makefile Manual.
While this document is rightly part of the LLVM Programmer's Manual, it is treated separately here because of the volume of content and because it is often an early source of bewilderment for new developers.
The LLVM Makefile System is the component of LLVM that is responsible for building the software, testing it, generating distributions, checking those distributions, installing and uninstalling, etc. It consists of a several files throughout the source tree. These files and other general concepts are described in this section.
The LLVM Makefile System is quite generous. It not only builds its own software, but it can build yours too. Built into the system is knowledge of the llvm/projects directory. Any directory under projects that has both a configure script and a Makefile is assumed to be a project that uses the LLVM Makefile system. Building software that uses LLVM does not require the LLVM Makefile System nor even placement in the llvm/projects directory. However, doing so will allow your project to get up and running quickly by utilizing the built-in features that are used to compile LLVM. LLVM compiles itself using the same features of the makefile system as used for projects.
For complete details on setting up your projects configuration, simply mimic the llvm/projects/sample project or for further details, consult the Projects.html page.
To use the makefile system, you simply create a file named Makefile in your directory and declare values for certain variables. The variables and values that you select determine what the makefile system will do. These variables enable rules and processing in the makefile system that automatically Do The Right Thing™.
Setting variables alone is not enough. You must include into your Makefile additional files that provide the rules of the LLVM Makefile system. The various files involved are described in the sections that follow.
Each directory to participate in the build needs to have a file named Makefile. This is the file first read by make. It has three sections:
Every project must have a Makefile.common file at its top source directory. This file serves three purposes:
Every project must have a Makefile.config at the top of its build directory. This file is generated by the configure script from the pattern provided by the Makefile.config.in file located at the top of the project's source directory. The contents of this file depend largely on what configuration items the project uses, however most projects can get what they need by just relying on LLVM's configuration found in $(LLVM_OBJ_ROOT)/Makefile.config.
This file, located at $(LLVM_SRC_ROOT)/Makefile.rules is the heart of the LLVM Makefile System. It provides all the logic, dependencies, and rules for building the targets supported by the system. What it does largely depends on the values of make variables that have been set before Makefile.rules is included.
User Makefiles need not have comments in them unless the construction is unusual or it does not strictly follow the rules and patterns of the LLVM makefile system. Makefile comments are invoked with the pound (#) character. The # character and any text following it, to the end of the line, are ignored by make.
This section provides some examples of the different kinds of modules you can build with the LLVM makefile system. In general, each directory you provide will build a single object although that object may be composed of additionally compiled components.
Only a few variable definitions are needed to build a regular library. Normally, the makefile system will build all the software into a single libname.o (pre-linked) object. This means the library is not searchable and that the distinction between compilation units has been dissolved. Optionally, you can ask for a shared library (.so) or archive library (.a) built. Archive libraries are the default. For example:
LIBRARYNAME = mylib SHARED_LIBRARY = 1 ARCHIVE_LIBRARY = 1
says to build a library named "mylib" with both a shared library (mylib.so) and an archive library (mylib.a) version. The contents of all the libraries produced will be the same, they are just constructed differently. Note that you normally do not need to specify the sources involved. The LLVM Makefile system will infer the source files from the contents of the source directory.
The LOADABLE_MODULE=1 directive can be used in conjunction with SHARED_LIBRARY=1 to indicate that the resulting shared library should be openable with the dlopen function and searchable with the dlsym function (or your operating system's equivalents). While this isn't strictly necessary on Linux and a few other platforms, it is required on systems like HP-UX and Darwin. You should use LOADABLE_MODULE for any shared library that you intend to be loaded into an tool via the -load option. See the WritingAnLLVMPass.html document for an example of why you might want to do this.
In some situations, it is desirable to build a single bitcode module from a variety of sources, instead of an archive, shared library, or bitcode library. Bitcode modules can be specified in addition to any of the other types of libraries by defining the MODULE_NAME variable. For example:
LIBRARYNAME = mylib BYTECODE_LIBRARY = 1 MODULE_NAME = mymod
will build a module named mymod.bc from the sources in the directory. This module will be an aggregation of all the bitcode modules derived from the sources. The example will also build a bitcode archive containing a bitcode module for each compiled source file. The difference is subtle, but important depending on how the module or library is to be linked.
In some situations, you need to create a loadable module. Loadable modules can be loaded into programs like opt or llc to specify additional passes to run or targets to support. Loadable modules are also useful for debugging a pass or providing a pass with another package if that pass can't be included in LLVM.
LLVM provides complete support for building such a module. All you need to do is use the LOADABLE_MODULE variable in your Makefile. For example, to build a loadable module named MyMod that uses the LLVM libraries LLVMSupport.a and LLVMSystem.a, you would specify:
LIBRARYNAME := MyMod LOADABLE_MODULE := 1 LINK_COMPONENTS := support system
Use of the LOADABLE_MODULE facility implies several things:
A loadable module is loaded by LLVM via the facilities of libtool's libltdl library which is part of lib/System implementation.
For building executable programs (tools), you must provide the name of the tool and the names of the libraries you wish to link with the tool. For example:
TOOLNAME = mytool USEDLIBS = mylib LINK_COMPONENTS = support system
says that we are to build a tool name mytool and that it requires three libraries: mylib, LLVMSupport.a and LLVMSystem.a.
Note that two different variables are use to indicate which libraries are linked: USEDLIBS and LLVMLIBS. This distinction is necessary to support projects. LLVMLIBS refers to the LLVM libraries found in the LLVM object directory. USEDLIBS refers to the libraries built by your project. In the case of building LLVM tools, USEDLIBS and LLVMLIBS can be used interchangeably since the "project" is LLVM itself and USEDLIBS refers to the same place as LLVMLIBS.
Also note that there are two different ways of specifying a library: with a .a suffix and without. Without the suffix, the entry refers to the re-linked (.o) file which will include all symbols of the library. This is useful, for example, to include all passes from a library of passes. If the .a suffix is used then the library is linked as a searchable library (with the -l option). In this case, only the symbols that are unresolved at that point will be resolved from the library, if they exist. Other (unreferenced) symbols will not be included when the .a syntax is used. Note that in order to use the .a suffix, the library in question must have been built with the ARCHIVE_LIBRARY option set.
Many tools will want to use the JIT features of LLVM. To do this, you simply specify that you want an execution 'engine', and the makefiles will automatically link in the appropriate JIT for the host or an interpreter if none is available:
TOOLNAME = my_jit_tool USEDLIBS = mylib LINK_COMPONENTS = engine
Of course, any additional libraries may be listed as other components. To get a full understanding of how this changes the linker command, it is recommended that you:
cd examples/Fibonacci make VERBOSE=1
This section describes each of the targets that can be built using the LLVM Makefile system. Any target can be invoked from any directory but not all are applicable to a given directory (e.g. "check", "dist" and "install" will always operate as if invoked from the top level directory).
| Target Name | Implied Targets | Target Description |
|---|---|---|
| all | Compile the software recursively. Default target. | |
| all-local | Compile the software in the local directory only. | |
| check | Change to the test directory in a project and run the test suite there. | |
| check-local | Run a local test suite. Generally this is only defined in the Makefile of the project's test directory. | |
| clean | Remove built objects recursively. | |
| clean-local | Remove built objects from the local directory only. | |
| dist | all | Prepare a source distribution tarball. |
| dist-check | all | Prepare a source distribution tarball and check that it builds. |
| dist-clean | clean | Clean source distribution tarball temporary files. |
| install | all | Copy built objects to installation directory. |
| preconditions | all | Check to make sure configuration and makefiles are up to date. |
| printvars | all | Prints variables defined by the makefile system (for debugging). |
| tags | Make C and C++ tags files for emacs and vi. | |
| uninstall | Remove built objects from installation directory. |
When you invoke make with no arguments, you are implicitly instructing it to seek the "all" target (goal). This target is used for building the software recursively and will do different things in different directories. For example, in a lib directory, the "all" target will compile source files and generate libraries. But, in a tools directory, it will link libraries and generate executables.
This target is the same as all but it operates only on the current directory instead of recursively.
This target can be invoked from anywhere within a project's directories but always invokes the check-local target in the project's test directory, if it exists and has a Makefile. A warning is produced otherwise. If TESTSUITE is defined on the make command line, it will be passed down to the invocation of make check-local in the test directory. The intended usage for this is to assist in running specific suites of tests. If TESTSUITE is not set, the implementation of check-local should run all normal tests. It is up to the project to define what different values for TESTSUTE will do. See the TestingGuide for further details.
This target should be implemented by the Makefile in the project's test directory. It is invoked by the check target elsewhere. Each project is free to define the actions of check-local as appropriate for that project. The LLVM project itself uses dejagnu to run a suite of feature and regresson tests. Other projects may choose to use dejagnu or any other testing mechanism.
This target cleans the build directory, recursively removing all things that the Makefile builds. The cleaning rules have been made guarded so they shouldn't go awry (via rm -f $(UNSET_VARIABLE)/* which will attempt to erase the entire directory structure.
This target does the same thing as clean but only for the current (local) directory.
This target builds a distribution tarball. It first builds the entire project using the all target and then tars up the necessary files and compresses it. The generated tarball is sufficient for a casual source distribution, but probably not for a release (see dist-check).
This target does the same thing as the dist target but also checks the distribution tarball. The check is made by unpacking the tarball to a new directory, configuring it, building it, installing it, and then verifying that the installation results are correct (by comparing to the original build). This target can take a long time to run but should be done before a release goes out to make sure that the distributed tarball can actually be built into a working release.
This is a special form of the clean clean target. It performs a normal clean but also removes things pertaining to building the distribution.
This target finalizes shared objects and executables and copies all libraries, headers, executables and documentation to the directory given with the --prefix option to configure. When completed, the prefix directory will have everything needed to use LLVM.
The LLVM makefiles can generate complete internal documentation for all the classes by using doxygen. By default, this feature is not enabled because it takes a long time and generates a massive amount of data (>100MB). If you want this feature, you must configure LLVM with the --enable-doxygen switch and ensure that a modern version of doxygen (1.3.7 or later) is available in your PATH. You can download doxygen from here.
This utility target checks to see if the Makefile in the object directory is older than the Makefile in the source directory and copies it if so. It also reruns the configure script if that needs to be done and rebuilds the Makefile.config file similarly. Users may overload this target to ensure that sanity checks are run before any building of targets as all the targets depend on preconditions.
This utility target just causes the LLVM makefiles to print out some of the makefile variables so that you can double check how things are set.
This utility target will force a reconfigure of LLVM or your project. It simply runs $(PROJ_OBJ_ROOT)/config.status --recheck to rerun the configuration tests and rebuild the configured files. This isn't generally useful as the makefiles will reconfigure themselves whenever its necessary.
This utility target, only available when $(PROJ_OBJ_ROOT) is not the same as $(PROJ_SRC_ROOT), will completely clean the $(PROJ_OBJ_ROOT) directory by removing its content entirely and reconfiguring the directory. This returns the $(PROJ_OBJ_ROOT) directory to a completely fresh state. All content in the directory except configured files and top-level makefiles will be lost.
Use with caution.
This target will generate a TAGS file in the top-level source directory. It is meant for use with emacs, XEmacs, or ViM. The TAGS file provides an index of symbol definitions so that the editor can jump you to the definition quickly.
This target is the opposite of the install target. It removes the header, library and executable files from the installation directories. Note that the directories themselves are not removed because it is not guaranteed that LLVM is the only thing installing there (e.g. --prefix=/usr).
Variables are used to tell the LLVM Makefile System what to do and to obtain information from it. Variables are also used internally by the LLVM Makefile System. Variable names that contain only the upper case alphabetic letters and underscore are intended for use by the end user. All other variables are internal to the LLVM Makefile System and should not be relied upon nor modified. The sections below describe how to use the LLVM Makefile variables.
Variables listed in the table below should be set before the inclusion of $(LEVEL)/Makefile.common. These variables provide input to the LLVM make system that tell it what to do for the current directory.
Override variables can be used to override the default values provided by the LLVM makefile system. These variables can be set in several ways:
The override variables are given below:
Variables listed in the table below can be used by the user's Makefile but should not be changed. Changing the value will generally cause the build to go wrong, so don't do it.
Variables listed below are used by the LLVM Makefile System and considered internal. You should not use these variables under any circumstances.
Archive AR.Flags BaseNameSources BCCompile.C BCCompile.CXX BCLinkLib C.Flags Compile.C CompileCommonOpts Compile.CXX ConfigStatusScript ConfigureScript CPP.Flags CPP.Flags CXX.Flags DependFiles DestArchiveLib DestBitcodeLib DestModule DestSharedLib DestTool DistAlways DistCheckDir DistCheckTop DistFiles DistName DistOther DistSources DistSubDirs DistTarBZ2 DistTarGZip DistZip ExtraLibs FakeSources INCFiles InternalTargets LD.Flags LibName.A LibName.BC LibName.LA LibName.O LibTool.Flags Link LinkModule LLVMLibDir LLVMLibsOptions LLVMLibsPaths LLVMToolDir LLVMUsedLibs LocalTargets Module ObjectsBC ObjectsLO ObjectsO ObjMakefiles ParallelTargets PreConditions ProjLibsOptions ProjLibsPaths ProjUsedLibs Ranlib RecursiveTargets SrcMakefiles Strip StripWarnMsg TableGen TDFiles ToolBuildPath TopLevelTargets UserTargets


This demo shows how you can use date/time values as X-axis
values with the Scatter
chart. Although it's a Scatter chart it can also
show a line that connects the points, as you can see on the example to the right.
The chart has two datasets, one of which is set to be drawn as being stepped.
The date/time format parsing in RGraph is done by the RGraph.parseDate
function
internally and this function is quite versatile in the formats that it accepts.
This means that you are free to use many different formats for the date/time values that you supply. Some of the different formats that are accepted are shown in the source code below.
For smaller screens, the text size is reduced and the CSS
float
is reduced.
<script src="RGraph.common.core.js"></script> <script src="RGraph.scatter.js"></script>Put this where you want the chart to show up:
<div style="float: right"> <canvas id="cvs" width="600" height="200">[No canvas support]</canvas> </div>This is the code that generates the chart - it should be placed AFTER the
canvas
tag(s):


Meteor
home
men
women
kids
new arrivals
sale
Remember me
Login
Don't have an account? Sign up
Forget your password? Reset now
99
cart
nike air more uptempo 720
Size:
9.5
Color:
Black
Quanitiy
1
2
3
4
5
Price
$190
applied coupons
---
nike air more uptempo 720
Size:
9.5
Color:
Black
Quanitiy
1
2
3
4
5
Price
$190
applied coupons
---


|
ENPM809Y_Final_Project
10.0
Project on path-finding for autonomous robots in a known environment using C++
|
Public Member Functions | |
| virtual void | HandleInput (std::stack< RobotState * > &, const std::string &)=0 |
| Process input and move the robot to the next node according to the given RobotState class. More... | |
| RobotState (std::string name="RobotState") | |
| Default constructor for RobotState class. More... | |
| virtual | ~RobotState ()=default |
| Define default destructor. | |
| std::string | get_name () |
| Get name value as string. More... | |
Definition at line 27 of file RobotState.h.
|
inlineexplicit |
Default constructor for RobotState class.
| name_ | - name of RobotState |
| stack | - address of stack to gain access to the value while out of scope |
Definition at line 42 of file RobotState.h.
|
inline |
Get name value as string.
| name | of RobotState |
Definition at line 52 of file RobotState.h.
|
pure virtual |
Process input and move the robot to the next node according to the given RobotState class.
| string | - sequence of move instruction |
| stack | - address of stack to gain access to the value while out of scope |
Implemented in state::DownState, state::LeftState, state::RightState, and state::UpState.


You can set the level of output to the debugger to none, normal, or verbose.
To set the level of output to the debugger
1. From the Options menu, choose Trace Level.
2. Choose either None, Normal, or Verbose.


Preparation time
less than 30 mins
Cooking time
over 2 hours
Serves
Serves 3-4
Turkey is not just for Christmas! The drumsticks cost very little and stretch a long way - perfect for a meaty pot-roast on a modest budget.
This pot-roast can be cooked in advance and frozen, check the tips section for freezing instructions.
Preheat the oven to 170C/150C Fan/Gas 3. Season the turkey drumstick all over with salt and pepper.
Heat the oil in a flameproof, lidded casserole over a medium heat. Add the turkey drumstick and fry for 4-5 minutes, turning regularly until lightly browned on all sides. Transfer to a plate and set aside.
Chop the carrots and celery into roughly 2.5cm/1in lengths. Add the onion, celery and carrot to the casserole and fry for 4-5 minutes, stirring regularly. Stir in the herbs and bay leaf and continue to cook for a further 30-40 seconds.
Dissolve the chicken stock cube in the just-boiled water, then pour it into the casserole along with the wine (or extra chicken stock). Stir in the tomato purée and the redcurrant jelly (or cranberry sauce) and return the turkey drumstick to the mixture.
Cover the casserole with the lid and transfer to the oven. Cook for 1½ hours. After 1½ hours, add the new potatoes to the casserole, turn the turkey drumstick over, then replace the lid and continue to cook for a further 1½ hours, or until the turkey is very tender and the meat is falling off the bone.
Remove the turkey drumstick from the casserole and transfer it to a chopping board. Set aside until cool enough to handle.
In a small bowl, whisk the cornflour with a tablespoon of cold water to form a thick paste. Stir this paste into the pot-roast sauce. Heat the sauce until it is simmering and continue to stir until thickened.
While the sauce is thickening, remove the skin from the turkey drumstick, then remove the meat from the bone in large chunks, discarding any bone or sinew.
To serve, spoon the pot-roast sauce into bowls and place equal amounts of the turkey meat on top of each portion. Serve with freshly steamed green cabbage.


0
800 bp
Observed data
Random
Generate random positions
Inside (E.g. inside a gene): 470 bp
Outside (E.g. is not transcribed): 330 bp
Clear


News
Jan, 2017:
Demo code in Pyton is now available on our
downloads
section below. The code uses our deep network to estimate 3D shape and
texture parameters of a face appearing in a single unconstrained photo. It
produces a standard ply file output. If you've downloaded the network model in
the past, we recommend that you do so again, as we've uploaded a slightly better
model along with the code.
FAQ
Q: Will you release your network models and code?
A: Yes,
and they are already online! Please
see below. More
code and results are being prepared.
Q: How do you convert the network output to a 3D representation?
A: The network output is a standard 3DMM representation. Please see
our paper or any other
paper on 3DMMs for instructions.
Our distribution includes the data required to map the 3DMM parameters back to a textured 3D representation. Our
demo code shows how to convert the network output to a
standard textured mesh file (ply format) which can be viewed using standard 3D
viewers (e.g.,
MeshLab). We are preparing a revision of
our code with pose and expression estimation. This update will be available here
soon.
Q: Why doesn't your network also
model expression / pose / lighting / etc.?
A: This project aims to show that 3DMM parameters can be
discriminative (different representations for different people) and
robust (similar representations for the same person under varied viewing conditions). We therefore focused on parameters which reflect identity: 3D shape and texture. A possible next step is indeed to model more of these appearance variations. Note that pose and expression can be estimated directly from facial landmarks as demonstrated, e.g., in
this project.
We are preparing a revision of our code with pose and expression estimation.
This update will be available here soon.
Q: Why do you say that your estimated 3DMM parameters are more robust and discriminative than those estimated by other methods?
A: We measured how well our 3D shape and texture parameters represent faces
by estimating 3DMM parameters on an unprecedented number of photos in several
challenging face recognition benchmarks. These include
- 13,233 images from LFW
- 86,120 video frames from the YTF
set
- 24,472 video frames and images from the IJB-A
- 25,784 images and frames from the
MICC data set used to measure 3D reconstruction accuracy
- 500,000 images from
CASIA used to train our network
To our knowledge, this is the first evaluation of 3D face shape estimation methods performed at this scale and under such challenging conditions. These
tests show our estimates to be substantially better
in capturing subject specific shapes than the 3DMM estimates obtained by previous methods.
Q: Why are your face recognition results not as high as those reported by other
face recognition systems?
A: Because this is not a face recognition system.
Specifically, we aim to show that our 3DMM estimates for different unconstrained photos of the same person are more similar to each other than to those of other subjects.
We do this by testing our estimates on standard face recognition benchmarks. Our goal is
therefore not to set new face recognition records, but to evaluate how robust
and discriminative are our 3DMM estimates compared to those produced by previous
methods. The results obtained with our estimated 3DMM shape and texture
parameters are the highest we know of, and not much lower than recognition
results obtained with state of the art face recognition systems using opaque
features.
But if you are interested in a recent state of the art face recognition method,
please refer to our
related, face recognition project.
Q: Does the network assume that faces are properly aligned / localized in order to produce a shape estimate?
A: In our tests, we used the bounding boxes provided in each data set as the only form of alignment (equivalent to aligning for spatial translation and scale). In particular, we do not require facial landmark detection
to align the input face. Future versions of our code may use landmark detection
only for pose and expression estimation.
Q: But your output is not aligned to the face in the image! How do you compute the
3D shape's pose?
A: The 6 degree of freedom pose of a 3D face is easy to compute, even for unconstrained images, using standard, off-the-shelf facial landmark detectors such as the one included in the
DLIB package. This was described in our
ICCV'13 paper, MATLAB pseudo code for doing it is available in
this project webpage
and the same method is effectively used in our
face frontalization and
face recognition projects (code available
for both).
Still, if you don't want to implement it yourself, we
are planing to add this to our Python demo code soon.

A: Read
our paper!
Downloads
If you find the resources below useful, please reference our paper in your work.
1. ResNet-101 deep network for regressing 3DMM shape and texture parameters
This is a deep network trained to estimate 3DMM parameters for shape and texture
from faces appearing in extreme poses and viewing conditions. The download contains
all network
parameters and the parameters required to map the network's output 3DMM features back to 3D and texture
representations. Please see our paper for instructions on this process.
2. Python code for estimating a
textured 3D shape using our deep neural network
An end-to-end demo code that estimates 3D facial shape and texture directly from an unconstrained 2D face image. For a given input image, it produces a standard
textured 3D mesh file of the face (in ply format). It accompanies the deep network available above and both are required in order
to run the demo.
This is an ongoing project and we are continually adding more features, data and
information. Please check this page again for updates.
Copyright 2016, Anh Tuan Tran, Tal Hassner,
Iacopo Masi, and
Gerard Medioni
The SOFTWARE provided in this page is provided "as is", without any guarantee made
as to its suitability or fitness for any particular use. It may contain bugs, so
use of this tool is at your own risk. We take no responsibility for any damage of
any sort that may unintentionally be caused through its use.


Ocean [af06], ocean, in Crystal Sea
Last updated Turn #128
Ocean [af06], ocean, in Crystal Sea
------------------------------------------------------------------------
26: The Savvy Aardvark [ha5r], ship, 2 hulls, 1 rowing port, 6 sails,
26: 16% damaged, arrived from Ocean [af05], owner:
26: Phantasm [n4b], Imperial Empire, duke, with two workers,
26: eight sailors
27: The Savvy Aardvark [ha5r], ship, 2 hulls, 1 rowing port, 6 sails,
27: 16% damaged, departed for Ocean [af07].
Routes leaving Ocean:
North, to Ocean [ae06], 6 days
East, to Ocean [af07], 6 days
South, to Ocean [ag06], 6 days
West, to Ocean [af05], 6 days


BULWORTH (director/writer:Warren Beatty; screenwriters:Jeremy Pikser; based on a story by Beatty/ cinematographer: Vittorio Storaro; cast:Warren Beatty (Sen. Jay Bulworth), Halle Berry (Nina), Oliver Platt (Bulworth's campaign manager), Don Cheadle (drug dealer, L.D.), Paul Sorvino (head of an insurance corp.,Graham Crockett), Jack Warden (Eddie Davers), Christine Baranski (Senator Bulworth's wife), Amiri Baraka (homeless man), 1998)
Reviewed by Dennis Schwartz
A satirical film where Warren Beatty tries to talk the black man's rap to get across his political message: which is that there's something wrong in politics that corrupts everyone in it. He plays a self-destructing liberal Democratic California senator, Bulworth ( pretty close to bullshit), who is running for re-election in 1996 and is suffering from despondency after several sleepless nights. He is unhappy with the phony he has become, so his solution is to hire an unknown hit man to kill him. He also takes out a $10 million dollar life insurance policy for his teenage daughter's benefit with an insurance representative who is influencing his vote on some impending insurance legislation.
But something happens to him along the way to a South Central L.A. black church, where he decides to tell the truth.  Anyway, he starts chastising the congregation for following the guilty O.J. Simpson and not fighting for the real needs of the community, such as the failure of inner-city schools and developing local businesses and filling the need for black leaders to replace those who got killed in the '60s and '70s; and, he blames himself and all politicians for taking the easy money the corporations give to make sure their side is always taken care of.  Instead, he tells the black congregation that the government doesn't care about them because they don't contribute enough money to re-election campaigns. Beatty believes that is the problem with the country, the great divide between the haves-and-the have-nots must be resolved, and that the politicians will always support those who contribute to them and ignore those who have no power unless there is some kind of election reform.
He encounters a sexy black woman in the church, Nina (Halle ), who re-invigorates him, reminding him how he once thought of himself as a liberal Democrat who cared about the truth, but who has now lost the way and seems no different than the Republicans. She takes him to a hip-hop club and he sheds his whiteness in favor of the black man's rap, which he will ridiculously imitate for the remainder of the campaign, to the initial fright of his campaign staff led by Oliver Platt, in the role of a stereotypical flunky, no new acting ground is broken here, as the main comedy of the film comes about as the sleazy Pratt adopts to any view that keeps him in power. The other key staff member is his veteran campaign advisor, Jack Warden, who plays his minor role low-key, trying to go with his successful meal ticket as far it could take him.
Invited to speak before a largely Jewish crowd of supporters in the entertainment field, he tells them they make crappy films and are only interested in making money. At a business luncheon he insults the big contributors to his campaign, such as, Paul Sorvino, who is head of an insurance corporation that gives him campaign money and money under the table to block an insurance bill that would help the indigent.
Falling for Nina, meeting her family in their house, he leaves the house and goes strolling in the hood and ends up trying to be a combo of Jerry Lewis and James Cagney in one body, helping some drug dealing boys in the street from getting beat on by a racist cop. This is an awkardly embarrassing scene, that was more embarrassing than funny to watch Beatty try to ingratiate himself this way to his black brothers. It reminded me in an analogous way of the liberals in the '60s who invited the Black Panthers into their wealthy homes and thought they were so chic.
Bulworth also decides he is beginning to have some fun, or maybe its the weed and coke that got to him, as he tries to get a hold of the hit man and call off the job. The most unbelievable scene in the film-a scene that was just too gooey to take without asking what Beatty was thinking of-was the conversion of the local drug dealer (Cheadle) to the cause of the community after hearing one of Beatty's speeches on TV. Even Frank Capra wasn't that schmaltzy.
Meanwhile CNN is interviewing him and C-Span is following him around in a truck, not understanding where he is going with this new image change. The story gets too ridiculous at this point to even be satirical or credible, it is just bad filmmaking; but it does try in its unclear and scrambled way to blame the media and the rich people who control it, for not being risk takers and offering fresh arguments into the political fray. In his contemptuous style (which hides a self-righteous anger), he sounds more preachy than a Sidney Lumet does in Network, as he seems to have retained an old liberal paternalistic style towards blacks from back in the days of the '60s and '70s, that he can't shake.
Amiri Baraka (poet & playwright), supposedly a voice of consciousness, plays a homeless wiseman who keeps popping up from scene-to-scene, uttering this heavy stream of consciousness rap, "We need no more ghosts, we need a spirit."
The fault of the film, is that Beatty can't gracefully pull off what he is trying to accomplish without appearing to be smug about it, like he's the white man who knows best what to do, and that anything he does is super cool because he really cares about the blacks and the poor (sic). His naive solution for race problems is to have the races fornicate together and have a mixed racial country.
Everyone in the film is a cardboard prop for Beatty to lay it into them with his political cliches.
Just when I thought Wag the Dog was the stupidest political comedy I ever saw, along comes this sophomoric venture, showing no plausible way of replacing the old lies of Senator Bulworth with his new so-called truths, and as a result it is a film that out wags the dog's tail in silliness and prattle, unable to have the demented Bulworth say what he would do when elected, except what is implied, that the people will trust him because he's so hip and daring, and he's just so with it. There was a smugness about this film that made its childish political voice seem more annoying than it should be, even taking away any enjoyment that might have been derived from its comic efforts. This is just a bad film that tried to say something about social injustice, the class differences between the rich and the poor, the unfair loss of welfare programs, the inhibiting cost of health insurance that is falsely being blamed on the government when it is the fault of insurance companies why the rates are so high, the hypocrisies of the Gulf War, and the failure of the media to be more responsive in covering all the political corruption. Beatty is just not the filmmaker I would want telling my side of the story. He has a way of glossing over his once real candidate's foibles, Bobby Kennedy and Gary Hart, while pretending to have answers that he doesn't have or at least, doesn't present them that well in the film. All he has done is make a film that is cliched and overbearing and funny in a not funny way, and he sounds no different or trustworthy than the politicians he features in the film, Clinton and Dole. And, I don't mean that as a compliment.
REVIEWED ON 9/6/99 GRADE: D
Dennis Schwartz: "Ozus' World Movie Reviews"
http://www.sover.net/~ozus
<EMAIL_ADDRESS>© ALL RIGHTS RESERVED DENNIS SCHWARTZ
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


Hacker News
new
|
past
|
comments
|
ask
|
show
|
jobs
|
submit
login
1.
∆
A Peek Into Graviton2
(
anandtech.com
)
33 points by
adwn
52 minutes ago
|
hide
|
5 comments
2.
∆
Launch HN: Datree (YC W20) – Best practices and security policies on each commit
25 points by
shimont
1 hours ago
|
hide
|
33 comments
3.
∆
Sanoid – Replication and Backups with ZFS
(
github.com
)
53 points by
mkj
4 hours ago
|
hide
|
13 comments
4.
∆
Tips for the Depressed
(
nplusonemag.com
)
34 points by
bookofjoe
1 hours ago
|
hide
|
8 comments
5.
∆
Zoom In: Speculative claims about neural circuits
(
distill.pub
)
11 points by
dsr12
1 hours ago
|
hide
|
discuss
6.
∆
WebGPU Shading Language
(
gpuweb.github.io
)
35 points by
pjmlp
4 hours ago
|
hide
|
13 comments
7.
∆
COVID-19 Therapeutics Accelerator
(
gatesfoundation.org
)
659 points by
sandGorgon
11 hours ago
|
hide
|
115 comments
8.
∆
Ask HN: What's the best corporate password manager?
139 points by
flippyhead
5 hours ago
|
hide
|
143 comments
9.
∆
Firefox 74
(
mozilla.org
)
384 points by
replax
4 hours ago
|
hide
|
175 comments
10.
∆
Object Oriented Role Analysis and Modeling
(
wikipedia.org
)
22 points by
dmux
3 hours ago
|
hide
|
12 comments
11.
∆
The Mathematics of the Gods and the Algorithms of Men: A Cultural History
(
spectator.co.uk
)
48 points by
Hooke
8 hours ago
|
hide
|
9 comments
12.
∆
Project Coldfeet
(
wikipedia.org
)
88 points by
Thevet
9 hours ago
|
hide
|
19 comments
13.
∆
Vstr: C string library designed to work optimally with vector I/O
(
and.org
)
76 points by
lelf
8 hours ago
|
hide
|
19 comments
14.
∆
Why Honeywell can't claim “the world's most powerful quantum computer”
(
venturebeat.com
)
5 points by
correlaterdude
2 hours ago
|
hide
|
1 comments
15.
∆
High-density hybrid powercapacitors: A new frontier in the energy race
(
newatlas.com
)
58 points by
bornelsewhere
9 hours ago
|
hide
|
39 comments
More
Applications are open for YC Summer 2020
Guidelines
|
FAQ
|
Support
|
API
|
Security
|
List
|
Bookmarklet
|
Legal
|
Apply to YC
|
Contact
Search:


Derek Eder
@derekeder
Chart of # vacant buildings reported per day in Chicago: https://www.google.com/fusiontables/embedviz?gco_displayAnnotations=true&gco_wmode=opaque&containerId=gviz_canvas&rmax=250&q=select+col1%2C+count()+from+1614852+&qrs=where+col1+%3E%3D+&qre=+and+col1+%3C%3D+&qe=+group+by++col1+order+by+col1+asc&viz=GVIZ&t=TIMELINE&width=900&height=400 Definitely spike similar to one that happend last year.
4/17/2012, 12:49:14 PM
Favs: 1
Retweets: 0
link


Files | |
| file | le_args.h [code] |
| file | le_basics.h [code] |
| file | le_build_config.h [code] |
| file | le_clock.h [code] |
| file | le_dir.h [code] |
| file | le_doublyLinkedList.h [code] |
| file | le_eventLoop.h [code] |
| file | le_fdMonitor.h [code] |
| file | le_fileLock.h [code] |
| file | le_hashmap.h [code] |
| file | le_hex.h [code] |
| file | le_log.h [code] |
| file | le_mem.h [code] |
| file | le_messaging.h [code] |
| file | le_mutex.h [code] |
| file | le_path.h [code] |
| file | le_pathIter.h [code] |
| file | le_print.h [code] |
| file | le_safeRef.h [code] |
| file | le_semaphore.h [code] |
| file | le_signals.h [code] |
| file | le_singlyLinkedList.h [code] |
| file | le_test.h [code] |
| file | le_thread.h [code] |
| file | le_timer.h [code] |
| file | le_utf8.h [code] |
| file | legato.h [code] |


This check validates pods using privilege escalation features against a predefined allowlist.
- Why is this important?
-
Privilege escalation features are necessary to implement several of our core functions. For example, Swift needs
privileged access to the storage nodes to format and mount its disks; Neutron needs privileged access to the network
interfaces to reach into customer networks; etc. In order to reduce the risks of these privileged operations
interfering with each other, this policy restricts their use to known and validated usecases.
- How do I extend the allowlist to cover my new requirements?
-
Set up your desired deployment in qa-de-1 (where this check runs in audit-only mode) with the minimum required
privileges. Then ask in #team_services; we can set up the respective allowlist entry for you. Once the allowlist is
deployed to prod, you can go ahead with your deployment to prod.
- Why not use the standard PodSecurity Admission webhook for this?
-
We want to avoid adding more admission webhooks than necessary, since every webhook is in the hot path for all
updates of Kubernetes objects. Also, Gatekeeper policies are much more versatile and can match allowed
configurations more precisely.


Toggle navigation
Admin
Event deployments
Event info
Quests List
Customize your app
Event deployments
Add new event
ID
Event name
Actions


{{ page.date | date: "%-d %B %Y" }} – Hear more from Chris {{ page.title }} {{ content }} Please enable JavaScript to view the comments powered by Disqus. comments powered by Disqus Privacy Policy


|
Nano102_112 Series BSP
V3.03.002
The Board Support Package for Nano102_112 Series
|
#include <Nano1X2Series.h>
Data Fields | |
| __I uint32_t | PDID |
| __IO uint32_t | RST_SRC |
| __IO uint32_t | IPRST_CTL1 |
| __IO uint32_t | IPRST_CTL2 |
| uint32_t | RESERVE0 [4] |
| __IO uint32_t | TEMPCTL |
| uint32_t | RESERVE1 [3] |
| __IO uint32_t | PA_L_MFP |
| __IO uint32_t | PA_H_MFP |
| __IO uint32_t | PB_L_MFP |
| __IO uint32_t | PB_H_MFP |
| __IO uint32_t | PC_L_MFP |
| __IO uint32_t | PC_H_MFP |
| __IO uint32_t | PD_L_MFP |
| __IO uint32_t | PD_H_MFP |
| __IO uint32_t | PE_L_MFP |
| __IO uint32_t | PE_H_MFP |
| __IO uint32_t | PF_L_MFP |
| uint32_t | RESERVE2 [1] |
| __IO uint32_t | PORCTL |
| __IO uint32_t | BODCTL |
| __IO uint32_t | BODSTS |
| __IO uint32_t | Int_VREFCTL |
| __IO uint32_t | LDO_CTL |
| uint32_t | RESERVE3 [3] |
| __IO uint32_t | IRCTRIMCTL |
| __IO uint32_t | IRCTRIMIEN |
| __IO uint32_t | IRCTRIMINT |
| uint32_t | RESERVE4 [29] |
| __IO uint32_t | RegLockAddr |
@addtogroup SYS System Global Control Registers(SYS) Memory Mapped Structure for SYS Controller
Definition at line 2677 of file Nano1X2Series.h.
| __IO uint32_t SYS_T::BODCTL |
| Bits | Field | Descriptions |
|---|---|---|
| [0] | BOD17_EN | Brown-Out Detector 1.7V Function Enable Control |
| This is a protected register. Please refer to open lock sequence to program it. | ||
| The default value is set by flash controller user configuration register config0 bit[20:19] | ||
| Users can disable BOD17_EN but it takes effective (disabled) only in Power-down mode. | ||
| Once existing Power-down mode, BOD17 will be enabled by HW automatically. | ||
| When CPU reads this bit, CPU will read whether BOD17 function enabled or not. | ||
| In other words,CPU will always read high. | ||
| 0 = Brown-out Detector 1.7V function Disabled. | ||
| 1 = Brown-out Detector 1.7V function Enabled. | ||
| [1] | BOD20_EN | Brown-Out Detector 2.0 V Function Enable Control |
| This is a protected register. Please refer to open lock sequence to program it. | ||
| 0 = Brown-out Detector 2.0 V function Disabled. | ||
| 1 = Brown-out Detector 2.0 V function Enabled. | ||
| BOD20_EN is default on. | ||
| If SW disables it, Brown-out Detector 2.0 V function is not disabled until chip enters power-down mode. | ||
| If system is not in power-down mode, BOD20_EN will be enabled by hardware automatically. | ||
| [2] | BOD25_EN | Brown-Out Detector 2.5 V Function Enable Control |
| This is a protected register. Please refer to open lock sequence to program it. | ||
| 0 = Brown-out Detector 2.5 V function Disabled. | ||
| 1 = Brown-out Detector 2.5 V function Enabled. | ||
| [4] | BOD17_RST_EN | BOD 1.7 V Reset Enable Control |
| This is a protected register. Please refer to open lock sequence to program it. | ||
| 0 = Reset does not issue when BOD17 occurs. | ||
| 1 = Reset issues when BOD17 occurs. | ||
| The default value is set by flash controller user configuration register config0 bit[20:19] | ||
| [5] | BOD20_RST_EN | BOD 2.0 V Reset Enable Control |
| This is a protected register. Please refer to open lock sequence to program it. | ||
| 0 = Reset does not issue when BOD20 occurs. | ||
| 1 = Reset issues when BOD20 occurs. | ||
| The default value is set by flash controller user configuration register config0 bit[20:19] | ||
| [6] | BOD25_RST_EN | BOD 2.5 V Reset Enable Control |
| This is a protected register. Please refer to open lock sequence to program it. | ||
| 0 = Reset does not issue when BOD25 occurs. | ||
| 1 = Reset issues when BOD25 occurs. | ||
| The default value is set by flash controller user configuration register config0 bit[20:19] | ||
| [8] | BOD17_INT_EN | BOD 1.7 V Interrupt Enable Control |
| This is a protected register. Please refer to open lock sequence to program it. | ||
| 0 = Interrupt does not issue when BOD17 occurs. | ||
| 1 = Interrupt issues when BOD17 occurs. | ||
| [9] | BOD20_INT_EN | BOD 2.0 V Interrupt Enable Control |
| 0 = Interrupt does not issue when BOD20 occurs. | ||
| 1 = Interrupt issues when BOD20 occurs. | ||
| [10] | BOD25_INT_EN | BOD 2.5 V Interrupt Enable Control |
| This is a protected register. Please refer to open lock sequence to program it. | ||
| 0 = Interrupt does not issue when BOD25 occurs. | ||
| 1 = Interrupt issues when BOD25 occurs. | ||
| [15:12] | BOD17_TRIM | BOD 1.7 TRIM Value |
| This is a protected register. Please refer to open lock sequence to program it. | ||
| This value is used to control BOD17 detect voltage level, nominal 1.7 V. | ||
| Higher trim value, higher detection voltage. | ||
| [19:16] | BOD20_TRIM | BOD 2.0 TRIM Value |
| This is a protected register. Please refer to open lock sequence to program it. | ||
| This value is used to control BOD20 detect voltage level, nominal 2.0 V. | ||
| Higher trim value, higher detection voltage. | ||
| [23:20] | BOD25_TRIM | BOD 2.5 TRIM Value |
| This is a protected register. Please refer to open lock sequence to program it. | ||
| This value is used to control BOD25 detect voltage level, nominal 2.5 V. | ||
| Higher trim value, higher detection voltage. |
Definition at line 3406 of file Nano1X2Series.h.
| __IO uint32_t SYS_T::BODSTS |
| Bits | Field | Descriptions |
|---|---|---|
| [0] | BOD_INT | Brown-Out Detector Interrupt Status |
| 0 = Brown-out Detector does not detect any voltage drift at VDD down through or up through the target detected voltage after interrupt is enabled. | ||
| 1 = When Brown-out Detector detects the VDD is dropped down through the target detected voltage or the VDD is raised up through the target detected voltage and Brown-out interrupt is enabled, this bit will be set to 1. | ||
| This bit is cleared by writing 1 to it. | ||
| [1] | BOD17_drop | Brown-Out Detector Lower Than 1.7V Status |
| Setting BOD17_drop high means once the detected voltage is lower than target detected voltage setting (1.7V). | ||
| Software can write 1 to clear BOD17_drop. | ||
| [2] | BOD20_drop | Brown-Out Detector Lower Than 2.0V Status |
| Setting BOD20_drop high means once the detected voltage is lower than target detected voltage setting (2.0V). | ||
| Software can write 1 to clear BOD20_drop. | ||
| [3] | BOD25_drop | Brown-Out Detector Lower Than 2.5V Status |
| Setting BOD25_drop high means once the detected voltage is lower than target detected voltage setting (2.5V). | ||
| Software can write 1 to clear BOD25_drop. | ||
| [4] | BOD17_rise | Brown-Out Detector Higher Than 1.7V Status |
| Setting BOD17_rise high means once the detected voltage is higher than target detected voltage setting (1.7V). | ||
| Software can write 1 to clear BOD17_rise. | ||
| [5] | BOD20_rise | Brown-Out Detector Higher Than 2.0V Status |
| Setting BOD20_rise high means once the detected voltage is higher than target detected voltage setting (2.0V). | ||
| Software can write 1 to clear BOD20_rise. | ||
| [6] | BOD25_rise | Brown-Out Detector Higher Than 2.5V Status |
| Setting BOD25_rise high means once the detected voltage is higher than target detected voltage setting (2.5V). | ||
| Software can write 1 to clear BOD25_rise. | ||
| [8] | BOD17 | Brown-Out Detector 1.7V Status |
| This bit reflects the BOD17 status. | ||
| BOD17 is high if detected voltage is higher than 1.7 V. | ||
| BOD17 is low if detected voltage is lower than 1.7 V. | ||
| Note: This bit is ready-only. | ||
| [9] | BOD20 | Brown-Out Detector 2.0V Status |
| This bit reflects the BOD20 status. | ||
| BOD20 is high if detected voltage is higher than 2.0 V. | ||
| BOD20 is low if detected voltage is lower than 2.0 V. | ||
| Note: This bit is ready-only. | ||
| [10] | BOD25 | Brown-Out Detector 2.5V Status |
| This bit reflects the BOD25 status. | ||
| BOD25 is high if detected voltage is higher than 2.5 V. | ||
| BOD25 is low if detected voltage is lower than 2.5 V. | ||
| Note: This bit is ready-only. |
Definition at line 3453 of file Nano1X2Series.h.
| __IO uint32_t SYS_T::Int_VREFCTL |
| Bits | Field | Descriptions |
|---|---|---|
| [0] | BGP_EN | Band-Gap Enable Control |
| This is a protected register. Please refer to open lock sequence to program it. | ||
| Band-gap is the reference voltage of internal reference voltage. | ||
| User must enable band-gap if want to enable internal 1.5, 1.8V or 2.5V reference voltage. | ||
| 0 = Disabled. | ||
| 1 = Enabled. | ||
| [1] | REG_EN | Regulator Enable Control |
| Enable internal 1.5, 1.8V or 2.5V reference voltage. | ||
| This is a protected register. Please refer to open lock sequence to program it. | ||
| 0 = Disabled. | ||
| 1 = Enabled. | ||
| [3:2] | SEL25 | Regulator Output Voltage Selection |
| Select internal reference voltage level. | ||
| This is a protected register. Please refer to open lock sequence to program it. | ||
| 00 = 1.5V. | ||
| 01 = 1.8V. | ||
| 10 = 2.5V. | ||
| 11 = 2.5V. | ||
| [4] | EXT_MODE | Regulator External Mode |
| This is a protected register. Please refer to open lock sequence to program it. | ||
| Users can output regulator output voltage in VREF pin if EXT_MODE is high. | ||
| 0 = No connection with external VREF pin. | ||
| 1 = Connect to external VREF pin. | ||
| Connect a 1uF to 10uF capacitor to AVSS will let internal voltage reference be more stable. | ||
| [11:8] | VREF_TRIM | Internal Voltage Reference Trim |
Definition at line 3488 of file Nano1X2Series.h.
| __IO uint32_t SYS_T::IPRST_CTL1 |
| Bits | Field | Descriptions |
|---|---|---|
| [0] | CHIP_RST | Chip One-Shot Reset |
| This is a protected register. Please refer to open lock sequence to program it. | ||
| Setting this bit will reset the whole chip, including Cortex-M0 core and all peripherals like power-on reset and this bit will automatically return to "0" after the 2 clock cycles. | ||
| The chip setting from flash will be also reloaded when chip one shot reset. | ||
| 0 = Normal. | ||
| 1 = Reset chip. | ||
| Note: In the following conditions, chip setting from flash will be reloaded. | ||
| Power-on Reset | ||
| Brown-out-Detected Reset | ||
| Low level on the nRESET pin | ||
| Set IPRST_CTL1[CHIP_RST] | ||
| [1] | CPU_RST | Cortex-M0 Core One-Shot Reset |
| This is a protected register. Please refer to open lock sequence to program it. | ||
| Setting this bit will only reset the Cortex-M0 core and Flash Memory Controller (FMC), and this bit will automatically return to "0" after the 2 clock cycles | ||
| 0 = Normal. | ||
| 1 = Reset Cortex-M0 core. | ||
| [2] | DMA_RST | DMA Controller Reset |
| This is a protected register. Please refer to open lock sequence to program it. | ||
| Set this bit "1" will generate a reset signal to the DMA. | ||
| SW needs to set this bit to low to release reset signal. | ||
| 0 = Normal operation. | ||
| 1 = DMA IP reset. |
Definition at line 2758 of file Nano1X2Series.h.
| __IO uint32_t SYS_T::IPRST_CTL2 |
| Bits | Field | Descriptions |
|---|---|---|
| [1] | GPIO_RST | GPIO Controller Reset |
| 0 = GPIO module normal operation. | ||
| 1 = GPIO module reset. | ||
| [2] | TMR0_RST | Timer0 Controller Reset |
| 0 = Timer0 module normal operation. | ||
| 1 = Timer0 module reset. | ||
| [3] | TMR1_RST | Timer1 Controller Reset |
| 0 = Timer1 module normal operation. | ||
| 1 = Timer1 module reset. | ||
| [4] | TMR2_RST | Timer2 Controller Reset |
| 0 = Timer2 module normal operation. | ||
| 1 = Timer2 module reset. | ||
| [5] | TMR3_RST | Timer3 Controller Reset |
| 0 = Timer3 module normal operation. | ||
| 1 = Timer3 module reset. | ||
| [8] | I2C0_RST | I2C0 Controller Reset |
| 0 = I2C0 module normal operation. | ||
| 1 = I2C0 module reset. | ||
| [9] | I2C1_RST | I2C1 Controller Reset |
| 0 = I2C1 module normal operation. | ||
| 1 = I2C1 module reset. | ||
| [12] | SPI0_RST | SPI0 Controller Reset |
| 0 = SPI0 module normal operation. | ||
| 1 = SPI0 module reset. | ||
| [13] | SPI1_RST | SPI1 Controller Reset |
| 0 = SPI1 module normal operation. | ||
| 1 = SPI1 module reset. | ||
| [16] | UART0_RST | UART0 Controller Reset |
| 0 = UART0 module normal operation. | ||
| 1 = UART0 module reset. | ||
| [17] | UART1_RST | UART1 Controller Reset |
| 0 = UART1 module normal operation. | ||
| 1 = UART1 module reset. | ||
| [20] | PWM0_RST | PWM0 Controller Reset |
| 0 = PWM0 module normal operation. | ||
| 1 = PWM0 module reset. | ||
| [22] | ACMP01_RST | Comparator Controller Reset |
| 0 = Comparator module normal operation. | ||
| 1 = Comparator module reset. | ||
| [26] | LCD_RST | LCD Controller Reset |
| 0 = LCD module normal operation. | ||
| 1 = LCD module reset. | ||
| [28] | ADC_RST | ADC Controller Reset |
| 0 = ADC module normal operation. | ||
| 1 = ADC module reset. | ||
| [30] | SC0_RST | SmartCard 0 Controller Reset |
| 0 = SmartCard module normal operation. | ||
| 1 = SmartCard module reset. | ||
| [31] | SC1_RST | SmartCard1 Controller Reset |
| 0 = SmartCard module normal operation. | ||
| 1 = SmartCard module reset. |
Definition at line 2819 of file Nano1X2Series.h.
| __IO uint32_t SYS_T::IRCTRIMCTL |
| Bits | Field | Descriptions |
|---|---|---|
| [1:0] | TRIM_SEL | Trim Frequency Selection |
| This field indicates the target frequency of HIRC auto trim. | ||
| If no any target frequency is selected (TRIM_SEL is 00), the HIRC auto trim function is disabled. | ||
| During auto trim operation, if 32.768 kHz clock error detected or trim retry limitation count reached, this field will be cleared to 00 automatically. | ||
| 00 = Disable HIRC auto trim function | ||
| 01 = Enable HIRC auto trim function and trim HIRC to 11.0592 MHz | ||
| 10 = Enable HIRC auto trim function and trim HIRC to 12 MHz | ||
| 11 = Enable HIRC auto trim function and trim HIRC to 16 MHz | ||
| [5:4] | TRIM_LOOP | Trim Calculation Loop |
| This field defines that trim value calculation is based on how many 32.768 kHz clock. | ||
| 00 = 4 x 32.768 kHz clock | ||
| 01 = 8 x 32.768 kHz clock | ||
| 10 = 16 x 32.768 kHz clock | ||
| 11 = 32 x 32.768 kHz clock | ||
| [7:6] | TRIM_RETRY_CNT | Trim Value Update Limitation Count |
| This field defines that how many times the auto trim circuit will try to update the HIRC trim value before the frequency of HIRC locked. | ||
| Once the HIRC locked, the internal trim value update counter will be reset. | ||
| If the trim value update counter reached this limitation value and frequency of HIRC still doesn't lock, the auto trim operation will be disabled and TRIM_SEL will be cleared to 00. | ||
| 00 = Trim retry count limitation is 64 | ||
| 01 = Trim retry count limitation is 128 | ||
| 10 = Trim retry count limitation is 256 | ||
| 11 = Trim retry count limitation is 512 | ||
| [8] | ERR_STOP | Trim Stop When 32.768 KHz Error Detected |
| This bit is used to control if stop the HIRC trim operation when 32.768 kHz clock error is detected. | ||
| If set this bit high and 32.768 kHz clock error detected, the status 32K_ERR_INT would be set high and HIRC trim operation was stopped. | ||
| If this bit is low and 32.768 kHz clock error detected, the status 23K_ERR_INT would be set high and HIRC trim operation is continuously. | ||
| 0 = Continue the HIRC trim operation even if 32.768 kHz clock error detected. | ||
| 1 = Stop the HIRC trim operation if 32.768 kHz clock error detected. |
Definition at line 3549 of file Nano1X2Series.h.
| __IO uint32_t SYS_T::IRCTRIMIEN |
| Bits | Field | Descriptions |
|---|---|---|
| [1] | TRIM_FAIL_IEN | Trim Failure Interrupt Enable Control |
| This bit controls if an interrupt will be triggered while HIRC trim value update limitation count reached and HIRC frequency still not locked on target frequency set by TRIM_SEL. | ||
| If this bit is high and TRIM_FAIL_INT is set during auto trim operation, an interrupt will be triggered to notify that HIRC trim value update limitation count was reached. | ||
| 0 = TRIM_FAIL_INT status Disabled to trigger an interrupt to CPU. | ||
| 1 = TRIM_FAIL_INT status Enabled to trigger an interrupt to CPU. | ||
| [2] | 32K_ERR_IEN | 32.768 KHz Clock Error Interrupt Enable Control |
| This bit controls if CPU would get an interrupt while 32.768 kHz clock is inaccuracy during auto trim operation. | ||
| If this bit is high, and 32K_ERR_INT is set during auto trim operation, an interrupt will be triggered to notify the 32.768 kHz clock frequency is inaccuracy. | ||
| 0 = 32K_ERR_INT status Disabled to trigger an interrupt to CPU. | ||
| 1 = 32K_ERR_INT status Enabled to trigger an interrupt to CPU. |
Definition at line 3569 of file Nano1X2Series.h.
| __IO uint32_t SYS_T::IRCTRIMINT |
| Bits | Field | Descriptions |
|---|---|---|
| [0] | FREQ_LOCK | HIRC Frequency Lock Status |
| This bit indicates the HIRC frequency lock. | ||
| This is a status bit and doesn't trigger any interrupt. | ||
| [1] | TRIM_FAIL_INT | Trim Failure Interrupt Status |
| This bit indicates that HIRC trim value update limitation count reached and HIRC clock frequency still doesn't lock. | ||
| Once this bit is set, the auto trim operation stopped and TRIM_SEL will be cleared to 00 by hardware automatically. | ||
| If this bit is set and TRIM_FAIL_IEN is high, an interrupt will be triggered to notify that HIRC trim value update limitation count was reached. | ||
| Write 1 to clear this to zero. | ||
| 0 = Trim value update limitation count doesn't reach. | ||
| 1 = Trim value update limitation count reached and HIRC frequency still doesn't lock. | ||
| [2] | 32K_ERR_INT | 32.768 KHz Clock Error Interrupt Status |
| This bit indicates that 32.768 kHz clock frequency is inaccuracy. | ||
| Once this bit is set, the auto trim operation stopped and TRIM_SEL will be cleared to 00 by hardware automatically. | ||
| If this bit is set and 32K_ERR_IEN is high, an interrupt will be triggered to notify the 32.768 kHz clock frequency is inaccuracy. | ||
| Write 1 to clear this to zero. | ||
| 0 = 32.768 kHz clock frequency is accuracy. | ||
| 1 = 32.768 kHz clock frequency is inaccuracy. |
Definition at line 3596 of file Nano1X2Series.h.
| __IO uint32_t SYS_T::LDO_CTL |
| Bits | Field | Descriptions |
|---|---|---|
| [0] | LDO_PD | LDO Power Off |
| This is a protected register. Please refer to open lock sequence to program it. | ||
| Set this bit high will off LDO and cause Chip in unexpected state. User must keep this bit low. | ||
| 0 = LDO Enabled. | ||
| 1 = LDO Disabled. | ||
| [3:2] | LDO_LEVEL | LDO Output Voltage Select |
| This is a protected register. Please refer to open lock sequence to program it. | ||
| 00 = Reserved. | ||
| 01 = 1.6V. | ||
| 10 = 1.8V. | ||
| 11 = 1.8V. |
Definition at line 3509 of file Nano1X2Series.h.
| __IO uint32_t SYS_T::PA_H_MFP |
| Bits | Field | Descriptions |
|---|---|---|
| [3:0] | PA8_MFP | PA.8 Pin Function Selection |
| 0000 = GPIOA[8] | ||
| 0100 = SmartCard0 Power pin | ||
| [7:4] | PA9_MFP | PA.9 Pin Function Selection |
| 0000 = GPIOA[9] | ||
| 0100 = SmartCard0 RST pin | ||
| [11:8] | PA10_MFP | PA.10 Pin Function Selection |
| 0000 = GPIOA[10] | ||
| 0100 = SmartCard0 CLK pin | ||
| [15:12] | PA11_MFP | PA.11 Pin Function Selection |
| 0000 = GPIOA[11] | ||
| 0010 = ADC external trigger input. | ||
| 0100 = SmartCard0 DATA pin(SC0_UART_RXD) | ||
| [18:16] | PA12_MFP | PA.12 Pin Function Selection |
| 0000 = GPIOA[12] | ||
| 0011 = Comparator1 P-end input | ||
| 0101 = I2C 0 clock pin | ||
| 0110 = SPI1 1st MOSI (Master Out, Slave In) pin | ||
| 0111 = UART0 Data transmitter output pin(This pin could modulate with PWM0 output. Please refer PWM_SEL(UARTx_CTL[26:24])). | ||
| 1000 = LCD segment output 19 at 48-pin package | ||
| [22:20] | PA13_MFP | PA.13 Pin Function Selection |
| 0000 = GPIOA[13] | ||
| 0011 = Comparator1 N-end input | ||
| 0101 = I2C0 data I/O pin | ||
| 0110 = SPI1 1st MISO (Master In, Slave Out) pin | ||
| 0111 = UART0 Data receiver input pin | ||
| 1000 = LCD segment output 18 at 48-pin package | ||
| [26:24] | PA14_MFP | PA.14 Pin Function Selection |
| 0000 = GPIOA[14] | ||
| 0101 = I2C1 clock pin | ||
| 0110 = SPI1 serial clock pin | ||
| 1000 = LCD segment output 17 at 48-pin package, LCD segment output 31 at 64-pin package | ||
| 1001 = Comparator0 charge/discharge path | ||
| [31:28] | PA15_MFP | PA.15 Pin Function Selection |
| 0000 = GPIOA[15] | ||
| 0010 = Timer3 capture input | ||
| 0011 = Comparator1 output | ||
| 0101 = I2C1 data I/O pin | ||
| 0110 = SPI1 1st slave select pin | ||
| 1000 = LCD segment output 16 at 48-pin package, LCD segment output 30 at 64-pin package |
Definition at line 2941 of file Nano1X2Series.h.
| __IO uint32_t SYS_T::PA_L_MFP |
| Bits | Field | Descriptions |
|---|---|---|
| [3:0] | PA0_MFP | PA.0 Pin Function Selection |
| 0000 = GPIOA[0] | ||
| 0010 = ADC input channel 0 | ||
| [6:4] | PA1_MFP | PA.1 Pin Function Selection |
| 0000 = GPIOA[1] | ||
| 0010 = ADC analog input1 | ||
| 0011 = Comparator0 P-end input3 | ||
| 1001 = Comparator0 charge/discharge path | ||
| [11:8] | PA2_MFP | PA.2 Pin Function Selection |
| 0000 = GPIOA[2] | ||
| 0001 = External interrupt0 input pin | ||
| 0010 = ADC analog input2 | ||
| 0011 = Comparator0 P-end input2 | ||
| 0100 = SmartCard0 clock pin(SC0_UART_TXD) | ||
| 1001 = Comparator0 charge/discharge path | ||
| [14:12] | PA3_MFP | PA.3 Pin Function Selection |
| 0000 = GPIOA[3] | ||
| 0001 = External interrupt 1 | ||
| 0010 = ADC analog input3 | ||
| 0011 = Comparator0 P-end input1 | ||
| 0100 = SmartCard0 DATA pin(SC0_UART_RXD) | ||
| 1001 = Comparator0 charge/discharge path | ||
| [19:16] | PA4_MFP | PA.4 Pin Function Selection |
| 0000 = GPIOA[4] | ||
| 0010 = ADC analog input4 | ||
| 0011 = Comparator0 P-end input0 | ||
| 0100 = SmartCard0 card detect pin | ||
| 1001 = Comparator0 charge/discharge path | ||
| [23:20] | PA5_MFP | PA.5 Pin Function Selection |
| 0000 = GPIOA[5] | ||
| 0010 = ADC analog input5 | ||
| 0011 = Comparator0 N-end input0 | ||
| 0100 = SmartCard0 Power pin | ||
| 0101 = I2C1 data I/O pin | ||
| 0110 = SPI1 1st slave select pin | ||
| 1001 = Comparator0 charge/discharge path | ||
| [27:24] | PA6_MFP | PA.6 Pin Function Selection |
| 0000 = GPIOA[6] | ||
| 0010 = ADC analog input6 | ||
| 0011 = Comparator0 output | ||
| 0100 = SmartCard0 RST pin | ||
| 1001 = Comparator0 charge/discharge path | ||
| [31:28] | PA7_MFP | PA.7 Pin Function Selection |
| 0000 = GPIOA[7] | ||
| 0010 = ADC input channel 7 | ||
| 0100 = SmartCard1 card detect |
Definition at line 2891 of file Nano1X2Series.h.
| __IO uint32_t SYS_T::PB_H_MFP |
| Bits | Field | Descriptions |
|---|---|---|
| [3:0] | PB8_MFP | PB.8 Pin Function Selection |
| 0000 = GPIOB[8] | ||
| 0001 = External interrupt1 input pin | ||
| 0010 = Timer0 external counter input or Timer0 toggle out. | ||
| 0011 = PWM0 Channel0 output | ||
| 0100 = Snooper pin | ||
| 1000 = LCD segment output 32 at 100-pin package | ||
| [7:4] | PB9_MFP | PB.9 Pin Function Selection |
| 0000 = GPIOB[9] | ||
| 0011 = PWM0 Channel1 output | ||
| 1000 = LCD segment output 31 at 100-pin package | ||
| [11:8] | PB10_MFP | PB.10 Pin Function Selection |
| 0000 = GPIOB[10] | ||
| 0110 = SPI0 2nd MOSI (Master Out, Slave In) pin | ||
| 0111 = UART1 Data receiver input pin | ||
| 1000 = LCD segment output 24 at 64-pin package, LCD segment output 28 at 100-pin package | ||
| [15:12] | PB11_MFP | PB.11 Pin Function Selection |
| 0000 = GPIOB[11] | ||
| 0010 = Timer1 external counter input or Timer1 toggle out | ||
| 0110 = SPI0 2nd MISO (Master In, Slave Out) pin | ||
| 0111 = UART1 Request to Send output pin | ||
| 1000 = LCD segment output 23 at 64-pin package, LCD segment output 27 at 100-pin package | ||
| [19:16] | PB12_MFP | PB.12 Pin Function Selection |
| 0000 = GPIOB[12] | ||
| 0001 = Frequency Divider0 output pin | ||
| 0010 = Timer0 external counter input or Timer0 toggle out. | ||
| 0110 = SPI0 1st MOSI (Master Out, Slave In) pin | ||
| 0111 = UART0 Request to Send output pin | ||
| 1000 = LCD segment output 15 at 48-pin package, LCD segment output 22 at 64-pin package, LCD segment output 26 at 100-pin package | ||
| [23:20] | PB13_MFP | PB.13 Pin Function Selection |
| 0000 = GPIOB[13] | ||
| 0110 = SPI0 1st MISO (Master In, Slave Out) pin | ||
| 0111 = UART0 Data receiver input pin | ||
| 1000 = LCD segment output 14 at 48-pin package, LCD segment output 21 at 64-pin package, LCD segment output 25 at 100-pin package | ||
| [27:24] | PB14_MFP | PB.14 Pin Function Selection |
| 0000 = GPIOB[14] | ||
| 0110 = SPI0 serial clock pin | ||
| 0111 = UART0 Data transmitter output pin(This pin could modulate with PWM0 output) | ||
| 1000 = LCD segment output 13 at 48-pin package, LCD segment output 20 at 64-pin package, LCD segment output 24 at 100-pin package | ||
| [31:28] | PB15_MFP | PB.15 Pin Function Selection |
| 0000 = GPIOB[15] | ||
| 0110 = SPI0 1st slave select pin | ||
| 0111 = UART0 Clear to Send input pin | ||
| 1000 = LCD segment output 12 at 48-pin package, LCD segment output 19 at 64-pin package, LCD segment output 23 at 100-pin package |
Definition at line 3050 of file Nano1X2Series.h.
| __IO uint32_t SYS_T::PB_L_MFP |
| Bits | Field | Descriptions |
|---|---|---|
| [3:0] | PB0_MFP | PB.0 Pin Function Selection |
| 0000 = GPIOB[0] | ||
| 0001 = Frequency Divider1 output pin | ||
| 0111 = UART0 Data transmitter output pin(This pin could modulate with PWM0 output. Please refer PWM_SEL(UARTx_CTL[26:24])). | ||
| 1000 = LCD segment output 29 at 64-pin package | ||
| [7:4] | PB1_MFP | PB.1 Pin Function Selection |
| 0000 = GPIOB[1] | ||
| 0001 = External interrupt1 input pin | ||
| 0010 = Timer 2 capture input | ||
| 0111 = UART0 Data receiver input pin | ||
| 1000 = LCD segment output 28 at 64-pin package | ||
| [11:8] | PB2_MFP | PB.2 Pin Function Selection |
| 0000 = GPIOB[2] | ||
| 0010 = Timer3 external counter input | ||
| 0101 = I2C0 clock pin | ||
| 0110 = SPI1 2nd MOSI (Master Out, Slave In) pin | ||
| 0111 = UART0 Request to Send output pin | ||
| 1000 = LCD segment output 27 at 64-pin package | ||
| [15:12] | PB3_MFP | PB.3 Pin Function Selection |
| 0000 = GPIOB[3] | ||
| 0010 = Timer2 external counter input | ||
| 0101 = I2C0 data I/O pin | ||
| 0110 = SPI1 2nd MISO (Master In, Slave Out) pin | ||
| 0111 = UART0 Clear to Send input pin | ||
| 1000 = LCD segment output 26 at 64-pin package | ||
| [19:16] | PB4_MFP | PB.4 Pin Function Selection |
| 0000 = GPIOB[4] | ||
| 0110 = SPI1 2nd MISO (Master In, Slave Out) pin | ||
| 0111 = UART1 Request to Send output pin | ||
| [23:20] | PB5_MFP | PB.5 Pin Function Selection |
| 0000 = GPIOB[5] | ||
| 0110 = SPI1 2nd MOSI (Master Out, Slave In) pin SmartCard0 RST | ||
| 0111 = UART1 Data receiver input pin | ||
| 1000 = LCD segment output 35 at 100-pin package | ||
| [27:24] | PB6_MFP | PB.6 Pin Function Selection |
| 0000 = GPIOB[6] | ||
| 0001 = Frequency Divider0 output pin | ||
| 0110 = SPI1 2nd slave select pin | ||
| 0111 = UART1 Data transmitter output pin(This pin could modulate with PWM0 output. Please refer PWM_SEL(UARTx_CTL[26:24])). | ||
| 1000 = LCD segment output 25 at 64-pin package, LCD segment output 34 at 100-pin package | ||
| [31:28] | PB7_MFP | PB.7 Pin Function Selection |
| 0000 = GPIOB[7] | ||
| 0100 = SmartCard0 card detect | ||
| 0111 = UART1 Clear to Send input pin | ||
| 1000 = LCD segment output 33 at 100-pin package |
Definition at line 2996 of file Nano1X2Series.h.
| __IO uint32_t SYS_T::PC_H_MFP |
| Bits | Field | Descriptions |
|---|---|---|
| [3:0] | PC8_MFP | PC.8 Pin Function Selection |
| 0000 = GPIOC[8] | ||
| 0100 = SmartCard0 RST pin | ||
| 0111 = UART1 Data transmitter output pin(This pin could modulate with PWM0 output. Please refer PWM_SEL(UARTx_CTL[26:24])). | ||
| 1000 = LCD segment output 3 at 48-pin package, LCD segment output 10 at 64-pin package, LCD segment output 14 at 100-pin package | ||
| [7:4] | PC9_MFP | PC.9 Pin Function Selection |
| 1000 = LCD segment output 2 at 48-pin package, LCD segment output 9 at 64-pin package, LCD segment output 13 at 100-pin package | ||
| 0000 = GPIOC[9] | ||
| [11:8] | PC10_MFP | PC.10 Pin Function Selection |
| 0000 = GPIOC[10] | ||
| 0100 = SmartCard1 card detect | ||
| 0101 = I2C1 clock pin | ||
| 1000 = LCD segment output 12 at 100-pin package | ||
| [15:12] | PC11_MFP | PC.11 Pin Function Selection |
| 0000 = GPIOC[11] | ||
| 0100 = SmartCard1 PWR pin | ||
| 0101 = I2C 1 data I/O pin | ||
| 1000 = LCD segment output 11 at 100-pin package | ||
| [19:16] | PC12_MFP | PC.12 Pin Function Selection |
| 0000 = GPIOC[12] | ||
| 0100 = SmartCard1 clock pin(SC1_UART_TXD) | ||
| 1000 = LCD segment output 10 at 100-pin package | ||
| [23:20] | PC13_MFP | PC.13 Pin Function Selection |
| 0000 = GPIOC[13] | ||
| 0100 = SmartCard1 DATA pin(SC1_UART_RXD) | ||
| 1000 = LCD segment output 9 at 100-pin package | ||
| [27:24] | PC14_MFP | PC.14 Pin Function Selection |
| 0000 = GPIOC[14] | ||
| 0100 = SmartCard1 card detect | ||
| 1000 = LCD segment output 1 at 48-pin package, LCD segment output 8 at 64-pin package, LCD segment output 8 at 100-pin package | ||
| [31:28] | PC15_MFP | PC.15 Pin Function Selection |
| 0000 = GPIOC[15] | ||
| 0100 = SmartCard1 PWR pin | ||
| 1000 = LCD segment output 0 at 48-pin package, LCD segment output 7 at 64-pin package, LCD segment output 7 at 100-pin package |
Definition at line 3145 of file Nano1X2Series.h.
| __IO uint32_t SYS_T::PC_L_MFP |
| Bits | Field | Descriptions |
|---|---|---|
| [3:0] | PC0_MFP | PC.0 Pin Function Selection |
| 0000 = GPIOC[0] | ||
| 0011 = PWM0 Channel0 output | ||
| 0101 = I2C0 clock pin | ||
| 0110 = SPI0 2nd slave select pin | ||
| 1000 = LCD segment output 11 at 48-pin package, LCD segment output 18 at 64-pin package, LCD segment output 22 at 100-pin package | ||
| [7:4] | PC1_MFP | PC.1 Pin Function Selection |
| 0000 = GPIOC[1] | ||
| 0011 = PWM0 Channel1 output | ||
| 0101 = I2C0 data I/O pin | ||
| 1000 = LCD segment output 10 at 48-pin package, LCD segment output 17 at 64-pin package, LCD segment output 21 at 100-pin package | ||
| [11:8] | PC2_MFP | PC.2 Pin Function Selection |
| 0000 = GPIOC[2] | ||
| 0011 = PWM0 Channel2 output | ||
| 0101 = I2C1 clock pin | ||
| 1000 = LCD segment output 9 at 48-pin package, LCD segment output 16 at 64-pin package, LCD segment output 20 at 100-pin package | ||
| [15:12] | PC3_MFP | PC.3 Pin Function Selection |
| 0000 = GPIOC[3] | ||
| 0011 = PWM0 Channel3 output | ||
| 0101 = I2C1 data I/O pin | ||
| 1000 = LCD segment output 8 at 48-pin package, LCD segment output 15 at 64-pin package, LCD segment output 19 at 100-pin package | ||
| [19:16] | PC4_MFP | PC.4 Pin Function Selection |
| 0000 = GPIOC[4] | ||
| 0001 = External interrupt0 input pin | ||
| 0100 = SmartCard0 clock pin(SC0_UART_TXD) | ||
| 0111 = UART1 Clear to Send input pin | ||
| 1000 = LCD segment output 7 at 48-pin package, LCD segment output 14 at 64-pin package, LCD segment output 18 at 100-pin package | ||
| [23:20] | PC5_MFP | PC.5 Pin Function Selection |
| 0000 = GPIOC[5] | ||
| 0100 = SmartCard0 card detect pin | ||
| 1000 = LCD segment output 6 at 48-pin package, LCD segment output 13 at 64-pin package, LCD segment output 17 at 100-pin package | ||
| [27:24] | PC6_MFP | PC.6 Pin Function Selection |
| 0000 = GPIOC[6] | ||
| 0100 = SmartCard0 DATA pin(SC0_UART_RXD) | ||
| 0111 = UART1 Request to Send output pin | ||
| 1000 = LCD segment output 5 at 48-pin package, LCD segment output 12 at 64-pin package, LCD segment output 16 at 100-pin package | ||
| [31:28] | PC7_MFP | PC.7 Pin Function Selection |
| 0000 = GPIOC[7] | ||
| 0100 = SmartCard0 Power pin | ||
| 0111 = UART1 Data receiver input pin | ||
| 1000 = LCD segment output 4 at 48-pin package, LCD segment output 11 at 64-pin package, LCD segment output 15 at 100-pin package |
Definition at line 3101 of file Nano1X2Series.h.
| __IO uint32_t SYS_T::PD_H_MFP |
| Bits | Field | Descriptions |
|---|---|---|
| [2:0] | PD8_MFP | PD.8 Pin Function Selection |
| 0000 = GPIOD[8] | ||
| 0100 = SmartCard1 DATA pin(SC1_UART_RXD) | ||
| 1000 = LCD common output 2 at 48-pin, LCD common output 2 at 64-pin package, LCD common output 2 at 100-pin package | ||
| [6:4] | PD9_MFP | PD.9 Pin Function Selection |
| 0000 = GPIOD[9] | ||
| 0011 = PWM0 Channel3 output | ||
| 0100 = SmartCard1 RST pin | ||
| 1000 = LCD common output 1 at 48-pin, LCD common output 1 at 64-pin package, LCD common output 1 at 100-pin package | ||
| [10:8] | PD10_MFP | PD.10 Pin Function Selection |
| 0000 = GPIOD[10] | ||
| 0010 = Timer1 capture input | ||
| 0011 = PWM0 Channel2 output | ||
| 1000 = LCD common output 0 at 48-pin, LCD common output 0 at 64-pin package, LCD common output 0 at 100-pin package | ||
| [14:12] | PD11_MFP | PD.11 Pin Function Selection |
| 0000 = GPIOD[11] | ||
| 0010 = Timer0 capture input | ||
| 0011 = PWM0 Channel1 output | ||
| 1000 = LCD external capacitor pin of charge pump circuit at 64-pin package, LCD external capacitor pin of charge pump circuit at 100-pin package | ||
| [18:16] | PD12_MFP | PD.12 Pin Function Selection |
| 0000 = GPIOD[12] | ||
| 0001 = Frequency Divider0 output pin | ||
| 0010 = Timer1 external counter input or Timer1 toggle out | ||
| 0011 = PWM0 Channel0 output | ||
| 1000 = LCD external capacitor pin of charge pump circuit at 64-pin package, LCD external capacitor pin of charge pump circuit at 100-pin package | ||
| 1001 = 1, 1/2, 1/4, 1/16 Hz clock output | ||
| [22:20] | PD13_MFP | PD.13 Pin Function Selection |
| 0000 = GPIOD[13] | ||
| 0001 = External interrupt 1 input pin | ||
| 1000 = LCD Unit voltage for LCD charge pump circuit at 48-pin package, LCD Unit voltage for LCD charge pump circuit at 64-pin package, LCD Unit voltage for LCD charge pump circuit at 100-pin package | ||
| [27:24] | PD14_MFP | PD.14 Pin Function Selection |
| 0000 = GPIOD[14] | ||
| 1000 = LCD Unit voltage for LCD charge pump circuit at 48-pin package, LCD Unit voltage for LCD charge pump circuit at 64-pin package, LCD Unit voltage for LCD charge pump circuit at 100-pin package | ||
| [30:28] | PD15_MFP | PD.15 Pin Function Selection |
| 0000 = GPIOD[15] | ||
| 1000 = LCD Unit voltage for LCD charge pump circuit at 48-pin package, LCD Unit voltage for LCD charge pump circuit at 64-pin package, LCD Unit voltage for LCD charge pump circuit at 100-pin package |
Definition at line 3227 of file Nano1X2Series.h.
| __IO uint32_t SYS_T::PD_L_MFP |
| Bits | Field | Descriptions |
|---|---|---|
| [3:0] | PD0_MFP | PD.0 Pin Function Selection |
| 0000 = GPIOD[0] | ||
| 1000 = LCD segment output 6 at 64-pin package, LCD segment output 6 at 100-pin package | ||
| [7:4] | PD1_MFP | PD.1 Pin Function Selection |
| 0000 = GPIOD[1] | ||
| 1000 = LCD segment output 5 at 64-pin package, LCD segment output 5 at 100-pin package | ||
| [11:8] | PD2_MFP | PD.2 Pin Function Selection |
| 0000 = GPIOD[2] | ||
| 1000 = LCD segment output 4 at 64-pin package, LCD segment output 4 at 100-pin package | ||
| [15:12] | PD3_MFP | PD.3 Pin Function Selection |
| 0000 = GPIOD[3] | ||
| 1000 = LCD segment output 3 at 64-pin package, LCD segment output 3 at 100-pin package | ||
| [19:16] | PD4_MFP | PD.4 Pin Function Selection |
| 0000 = GPIOD[4] | ||
| 0100 = SmartCard1 RST pin | ||
| 1000 = LCD segment output 2 at 64-pin package, LCD segment output 2 at 100-pin package | ||
| [23:20] | PD5_MFP | PD.5 Pin Function Selection |
| 0000 = GPIOD[5] | ||
| 1000 = LCD segment output 1 at 64-pin package(or as LD_COM5), LCD segment output 1 at 100-pin package(or as LD_COM5) | ||
| [27:24] | PD6_MFP | PD.6 Pin Function Selection |
| 0000 = GPIOD[6] | ||
| 1000 = LCD segment output 0 at 64-pin package(or as LD_COM4), LCD segment output 0 at 100-pin package(or as LD_COM4) | ||
| [31:28] | PD7_MFP | PD.7 Pin Function Selection |
| 0000 = GPIOD[7] | ||
| 0100 = SmartCard1 clock pin(SC1_UART_TXD) | ||
| 1000 = LCD common output 3 at 48-pin package, LCD common output 3 at 64-pin, LCD common output 3 at 100-pin package |
Definition at line 3181 of file Nano1X2Series.h.
| __I uint32_t SYS_T::PDID |
| Bits | Field | Descriptions |
|---|---|---|
| [31:0] | PDID | Part Device ID |
| This register reflects device part number code. | ||
| Software can read this register to identify which device is used. |
Definition at line 2692 of file Nano1X2Series.h.
| __IO uint32_t SYS_T::PE_H_MFP |
| Bits | Field | Descriptions |
|---|---|---|
| [3:0] | PE8_MFP | PE.8 Pin Function Selection |
| 0000 = GPIOE[8] | ||
| 0011 = PWM0 Channel2 output | ||
| 1000 = LCD segment output 30 at 100-pin package | ||
| [7:4] | PE9_MFP | PE.9 Pin Function Selection |
| 0000 = GPIOE[9] | ||
| 0011 = PWM0 Channel3 output | ||
| 1000 = LCD segment output 29 at 100-pin package |
Definition at line 3279 of file Nano1X2Series.h.
| __IO uint32_t SYS_T::PE_L_MFP |
| Bits | Field | Descriptions |
|---|---|---|
| [2:0] | PE0_MFP | PE.0 Pin Function Selection |
| 0000 = GPIOE[0] | ||
| 0110 = SPI0 1st MOSI (Master Out, Slave In) pin | ||
| [6:4] | PE1_MFP | PE.1 Pin Function Selection |
| 0000 = GPIOE[1] | ||
| 0110 = SPI0 1st MISO (Master In, Slave Out) pin | ||
| [10:8] | PE2_MFP | PE.2 Pin Function Selection |
| 0000 = GPIOE[2] | ||
| 0110 = SPI0 serial clock pin | ||
| [15] | PE3_MFP | PE.3 Pin Function Selection |
| 0000 = GPIOE[4] | ||
| 0110 = SPI0 1st slave select pin | ||
| [18:16] | PE4_MFP | PE.4 Pin Function Selection |
| 0000 = GPIOE[4] | ||
| 0100 = SmartCard1 RST pin | ||
| [23:20] | PE5_MFP | PE.5 Pin Function Selection |
| 0000 = GPIOE[5] | ||
| 0100 = SmartCard1 PWR pin | ||
| [27:24] | PE6_MFP | PE.6 Pin Function Selection |
| 0000 = GPIOE[6] | ||
| 0100 = SmartCard1 clock pin(SC1_UART_TXD) | ||
| [31:28] | PE7_MFP | PE.7 Pin Function Selection |
| 0000 = GPIOE[7] | ||
| 0100 = SmartCard1 DATA pin(SC1_UART_RXD) |
Definition at line 3261 of file Nano1X2Series.h.
| __IO uint32_t SYS_T::PF_L_MFP |
| Bits | Field | Descriptions |
|---|---|---|
| [3:0] | PF0_MFP | PF.0 Pin Function Selection |
| 0000 = GPIOF[1] | ||
| 0010 = Timer3 external counter input or Timer3 toggle out. | ||
| 1111 = External 32.768 kHz crystal input pin(default) | ||
| [7:4] | PF1_MFP | PF.1 Pin Function Selection |
| 0000 = GPIOF[1] | ||
| 0010 = Timer2 external counter input or Timer2 toggle out. | ||
| 1111 = External 32.768 kHz crystal output pin(default) | ||
| [11:8] | PF2_MFP | PF.2 Pin Function Selection |
| 0000 = GPIOF[2] | ||
| 0001 = External interrupt1 input pin | ||
| 0010 = Timer3 capture input | ||
| 0111 = UART1 Data receiver input pin | ||
| 1111 = External 4~24 MHz crystal input pin(default) | ||
| [15:12] | PF3_MFP | PF.3 Pin Function Selection |
| 0000 = GPIOF[3] | ||
| 0001 = External interrupt0 input pin | ||
| 0010 = Timer 2 capture input | ||
| 0111 = UART1 Data transmitter output pin(This pin could modulate with PWM0 output. Please refer PWM_SEL(UARTx_CTL[26:24])). | ||
| 1111 = External 4~24 MHz crystal output pin | ||
| [19:16] | PF4_MFP | PF.4 Pin Function Selection |
| 0000 = GPIOF[4] | ||
| 0001 = Frequency Divider1 output pin | ||
| 0010 = Timer1 capture input | ||
| 0011 = PWM0 Channel2 output | ||
| 1001 = 1, 1/2, 1/4, 1/8, 1/16 Hz clock output | ||
| 1111 = Serial Wired Debugger Clock pin | ||
| [23:20] | PF5_MFP | PF.5 Pin Function Selection |
| 0000 = GPIOF[5] | ||
| 0010 = Timer0 capture input | ||
| 0011 = PWM0 Channel3 output | ||
| 1001 = Comparator0 charge/discharge path | ||
| 1111 = Serial Wired Debugger Data pin |
Definition at line 3322 of file Nano1X2Series.h.
| __IO uint32_t SYS_T::PORCTL |
| Bits | Field | Descriptions |
|---|---|---|
| [15:0] | POR_DIS_CODE | Power-On Reset Enable Control |
| This is a protected register. Please refer to open lock sequence to program it. | ||
| When powered on, the POR circuit generates a reset signal to reset the whole chip function, but noise on the power may cause the POR active again. | ||
| If setting the POR_DIS_CODE to 0x5AA5, the POR reset function will be disabled and the POR function will be active again when POR_DIS_CODE is set to another value or POR_DIS_CODE is reset by chip other reset functions, including: /RESET, Watchdog Timer reset, BOD reset, ICE reset command and the software-chip reset function. |
Definition at line 3338 of file Nano1X2Series.h.
| __IO uint32_t SYS_T::RegLockAddr |
| Bits | Field | Descriptions |
|---|---|---|
| [0] | RegUnLock | Protected Register Enable Control |
| 0 = Protected register are Locked. Any write to the target register is ignored. | ||
| 1 = Protected registers are Unlocked. |
Definition at line 3611 of file Nano1X2Series.h.
| uint32_t SYS_T::RESERVE0[4] |
Definition at line 2821 of file Nano1X2Series.h.
| uint32_t SYS_T::RESERVE1[3] |
Definition at line 2834 of file Nano1X2Series.h.
| uint32_t SYS_T::RESERVE2[1] |
Definition at line 3323 of file Nano1X2Series.h.
| uint32_t SYS_T::RESERVE3[3] |
Definition at line 3510 of file Nano1X2Series.h.
| uint32_t SYS_T::RESERVE4[29] |
Definition at line 3597 of file Nano1X2Series.h.
| __IO uint32_t SYS_T::RST_SRC |
| Bits | Field | Descriptions |
|---|---|---|
| [0] | RSTS_POR | The RSTS_POR Flag Is Set By The "Reset Signal" From The Power-On Reset (POR) Module Or Bit CHIP_RST (IPRSTC1[0]) To Indicate The Previous Reset Source |
| 0 = No reset from POR or CHIP_RST. | ||
| 1 = Power-on Reset (POR) or CHIP_RST had issued the reset signal to reset the system. | ||
| Note: This bit is cleared by writing 1 to it. | ||
| [1] | RSTS_PAD | The RSTS_PAD Flag Is Set By The "Reset Signal" From The /RESET Pin Or Power Related Reset Sources To Indicate The Previous Reset Source |
| 0 = No reset from nRESET pin. | ||
| 1 = The /RESET pin had issued the reset signal to reset the system. | ||
| Note: This bit is cleared by writing 1 to it. | ||
| [2] | RSTS_WDT | The RSTS_WDT Flag Is Set By The "Reset Signal" From The Watchdog Timer Module To Indicate The Previous Reset Source |
| 0 = No reset from Watchdog Timer. | ||
| 1 = The Watchdog Timer module had issued the reset signal to reset the system. | ||
| Note: This bit is cleared by writing 1 to it. | ||
| [4] | RSTS_BOD | The RSTS_BOD Flag Is Set By The "Reset Signal" From The Brown-Out-Detected Module To Indicate The Previous Reset Source |
| 0 = No reset from BOD. | ||
| 1 = Brown-out-Detected module had issued the reset signal to reset the system. | ||
| Note: This bit is cleared by writing 1 to it. | ||
| [5] | RSTS_SYS | The RSTS_SYS Flag Is Set By The "Reset Signal" From The Cortex_M0 Kernel To Indicate The Previous Reset Source |
| 0 = No reset from Cortex_M0. | ||
| 1 = Cortex_M0 had issued the reset signal to reset the system by writing 1 to the bit SYSRESTREQ(AIRCR[2], Application Interrupt and Reset Control Register) in system control registers of Cortex_M0 kernel. | ||
| Note: This bit is cleared by writing 1 to it. | ||
| [7] | RSTS_CPU | The RSTS_CPU Flag Is Set By Hardware If Software Writes CPU_RST (IPRST_CTL1[1]) "1" To Rest Cortex-M0 Core And Flash Memory Controller (FMC) |
| 0 = No reset from CPU. | ||
| 1 = Cortex-M0 core and FMC are reset by software setting CPU_RST to 1. | ||
| Note: This bit is cleared by writing 1 to it. |
Definition at line 2726 of file Nano1X2Series.h.
| __IO uint32_t SYS_T::TEMPCTL |
| Bits | Field | Descriptions |
|---|---|---|
| [0] | VTEMP_EN | Temperature Sensor Enable Control |
| 0 = Temperature sensor function Disabled (default). | ||
| 1 = Temperature sensor function Enabled. |
Definition at line 2833 of file Nano1X2Series.h.


Protocols
Note:
I'm leaning toward a re-vamp of the protocol description scheme away from strict levels and more toward a bit-field support / no support for various protocol features.
Early thoughts
Just as the basic Assign Onward protocol supports multiple types of cryptographic methods, demonstrating the ability to include new methods as needed1For instance: to transition to quantum ready cryptography.
the protocol handler itself supports multiple protocols, demonstrating the path toward interoperability with future protocols. Some sense of the protocol development plan is found in the roadmap.
The Ⓐ¹ protocol is a basic, single recorder protocol. Many optimizations are possible in a single recorder scenario, such as assumption that the chain never forks because there is a single entity responsible for maintaining it. This means that the block chain is guaranteed sequential, non-forking and non-merging - and that transactions recorded thereon can also be reliably sequenced, so that once recorded information like public key identities and shares received amounts can be referred to in the future by just a sequence number in a particular blockchain.
Ⓐ²
Ⓐ² protocol expands to support multiple, possibly competing, block chain recorders. Temporary forks and later re-merges of the blockchain are anticipated, and as such many of the optimizations in Ⓐ¹ which assume no forking become invalid. No matter, when software supports both Ⓐ¹ and Ⓐ² protocols, all they need to do is determine which protocol applies and handle accordingly.
and many more
On the one hand, it would be nice to develop a single protocol to serve most use cases. On the other, it would be naïve to assume that a single protocol will set forth and optimally address all the myriad of presently unknown uses for lightweight blockchain impmementations. While it is entirely possible to develop a single blockchain and endlessly modify an develop it over the years, I believe it is also practical to develop replacement protocols which can start fresh and take over for existing protocols,5takeover to happen on the merits of the new protocol, if it is a truly superior protocol then it should be able to overcome the inertia of the existing implementations and replace them.
particularly in an ecosystem where no single blockchain is attempting to rule the entire world.
Assign Onward
6 July 2018
MIT License
Copyright (c) 2018 Assign Onward
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
 IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.


{% extends "layout.html" %} {% block body %}
{% if ns[0].name == "UK Biobank Array European" %} UK Biobank array - Meta-analysis (White British, European, African, South Asian, East Asian, Admixed, Related) {% else %} {% if ns[0].name == "UK Biobank Exome European" %} UK Biobank exome - Meta-analysis (White British, European, African, South Asian, East Asian, Admixed, Related) {% else %} {{ ns[0].name }} {% endif %} {% endif %}
Examples for UK Biobank array - Gene: F5, Variant: 1:169519049-T-C, RS ID: rs6025, Region: 10:114686614-114786614, Phenotype: Asthma
Note: We have aggregated summary statistics from over 750,000 individuals across three population cohorts: UK Biobank, Million Veterans Program and Biobank Japan. We are continuously adding data from other population cohorts in Global Biobank Engine. Please contact us if you want it to be featured.
For UK Biobank we present summary statistic results from the UK Biobank hospital in-patient health-related outcomes summary information data (Data-Field 41202); computational grouping of phenotypes with cancer (Category 100092) registry, death registry data (Category 100093), algorithmically-defined outcomes (Category 42), and verbal questionnaire data (Category 100071); and manually curated grouping of phenotypes.
We encourage use of the initial browser but note that case-control results are provided as general guides and specific results may not have yet been subjected to the data quality, statistical and population genetics review that would normally be required for publication or clinical inference.


Ghana captain Andre Ayew lauds teammates over good conduct in Black Stars camp
Ghana captain, Andre Dede Ayew has lauded his colleagues for the comportment and disciplined maintained in camp during the team’s double header in the 2021 Africa Cup of Nations (AFCON).
Ghana played against South Africa and Sao Tome in Group C of the 2021 AFCON qualifiers.
The Stars defeated South Africa at home by 2-0 and picked a slim win against Sao Tome in the second game played on Monday.
Ayew was speaking to reporters about the performance of the team and he lauded the players for the discipline maintained in camp in the two matches played.
“I very happy and I want to congratulate all the players for the win. Camp has been brilliant and discipline has been perfect.
He further said, the team will continue to replicate these performances and hope they secure qualification to the 2021 Africa Cup of Nations.
“We have six points and no team in our group did that in this international week so that proves that we did something good.
“This is just the beginning and we have six points now and we have to continue like this and I am happy and hope we continue like this”, he ended.
There have been reports concerning indiscipline in the camp of the Black Stars in recent times especially at the 2019 Africa Cup of Nations.
Ayew’s comments goes to prove that the reported cases of indiscipline might have been true.


| src |
|
0% |
0/45 |
0% |
0/32 |
0% |
0/15 |
0% |
0/45 |
| src/components |
|
16.67% |
8/48 |
0% |
0/22 |
6.25% |
1/16 |
17.02% |
8/47 |
| src/components/appLayout |
|
7.5% |
6/80 |
0% |
0/24 |
0% |
0/29 |
7.79% |
6/77 |
| src/components/cells |
|
7.55% |
4/53 |
0% |
0/26 |
0% |
0/15 |
7.84% |
4/51 |
| src/components/cells/cell |
|
4.05% |
9/222 |
0% |
0/118 |
0% |
0/61 |
4.31% |
9/209 |
| src/components/cells/component |
|
2.53% |
11/435 |
0% |
0/226 |
0% |
0/94 |
2.62% |
11/420 |
| src/components/cells/metricsGraphs |
|
3.3% |
3/91 |
0% |
0/46 |
0% |
0/20 |
3.41% |
3/88 |
| src/components/cells/metricsGraphs/timeSeriesGraph |
|
14.71% |
5/34 |
0% |
0/14 |
0% |
0/20 |
15.63% |
5/32 |
| src/components/common |
|
7.45% |
7/94 |
0% |
0/46 |
0% |
0/16 |
7.61% |
7/92 |
| src/components/common/color |
|
73.33% |
55/75 |
68.18% |
15/22 |
65.22% |
15/23 |
75% |
54/72 |
| src/components/common/error |
|
56% |
14/25 |
7.14% |
1/14 |
18.18% |
2/11 |
60.87% |
14/23 |
| src/components/common/state |
|
77.92% |
60/77 |
66.04% |
35/53 |
69.57% |
16/23 |
78.38% |
58/74 |
| src/components/common/toptoolbar |
|
3.7% |
4/108 |
0% |
0/71 |
0% |
0/36 |
3.92% |
4/102 |
| src/components/overview |
|
2.17% |
5/230 |
0% |
0/138 |
0% |
0/62 |
2.28% |
5/219 |
| src/components/tracing |
|
50% |
2/4 |
100% |
0/0 |
0% |
0/2 |
50% |
2/4 |
| src/components/tracing/search |
|
3.14% |
7/223 |
0% |
0/153 |
0% |
0/69 |
3.33% |
7/210 |
| src/components/tracing/view |
|
2.49% |
6/241 |
0% |
0/155 |
0% |
0/46 |
2.54% |
6/236 |
| src/components/tracing/view/timeline |
|
1.96% |
4/204 |
0% |
0/80 |
0% |
0/42 |
1.99% |
4/201 |
| src/icons |
|
25% |
6/24 |
100% |
0/0 |
0% |
0/9 |
25% |
6/24 |
| src/utils |
|
100% |
4/4 |
100% |
0/0 |
100% |
0/0 |
100% |
4/4 |
| src/utils/api |
|
96.55% |
56/58 |
100% |
47/47 |
100% |
10/10 |
96.55% |
56/58 |
| src/utils/common |
|
100% |
33/33 |
100% |
18/18 |
100% |
6/6 |
100% |
33/33 |
| src/utils/tracing |
|
100% |
150/150 |
100% |
118/118 |
100% |
30/30 |
100% |
146/146 |


Fluent configuration
SapphireDb supports the configuration of models and action handlers through a fluent API.
This method is optional and additional to the configuration through attributes but it has some advantages.
You can separate the code of the pure model class and the code for the configuration into different files for better readability for example.
Configure model
To use the fluent API you first have to create a class that implements the interface ISapphireModelConfiguration<T>
.
This class contains a method where you can use the fluent API.
\n
{\n
\tpublic void Configure(SapphireModelBuilder modelBuilder)\n
\t{\n
\t\tmodelBuilder.SetQueryFunction(information => { return message => message.Content == "test123"; });\n
\t\tmodelBuilder.AddQueryAuth("requireAdmin");\n\n
\t\tmodelBuilder.AddCreateEvent(before: (message, information) =>\n
\t\t{\n
\t\t\tConsole.WriteLine(message.Content.ToString());\n
\t\t});\n\n
\t\tmodelBuilder.Property(m => m.CreatedOn).AddQueryAuth("requireAdmin");\n
\t\tmodelBuilder.Property(m => m.Content).MakeNonCreatable();\n
\t}\n
}
]]>
Configure action handler
The configuration of an action handler pretty much equals the configuration of a model.
AsyncTask()\n
\t{\n
\t\tfor (int i = 0; i <= 100; i++)\n
\t\t{\n
\t\t\tThread.Sleep(10);\n
\t\t}\n\n
\t\treturn 33;\n
\t}\n\n
\tpublic string MethodWithParameters(string param1, string param2)\n
\t{\n
\t\treturn param1 + param2;\n
\t}\n\n
\tpublic void NoReturn()\n
\t{\n
\t\tConsole.WriteLine("This is a test");\n
\t}\n
}
\f:(csharp:ExampleActionsConfiguration.cs)
public class UserActionsConfiguration : ISapphireActionConfiguration\n
{\n
\tpublic void Configure(SapphireActionHandlerBuilder actionHandlerBuilder)\n
\t{\n
\t\tactionHandlerBuilder.Action("MethodWithParameters").AddActionAuth("requireAdmin");\n
\t}\n
}
]]>


Children’s Day celebrations held at FIITJEE Global School in Vellore
by Staff ReporterFIITJEE Global School organised a mega Children’s Day celebration at its Vellore campus, where over 200 parents participated along with their little children in the age-group of two and half years to six years.
There were several fun activities, games, and a grand fancy dress competition.
Tinytots displayed their skills on the stage, dressed up as professionals, celebrities and cultural ambassadors. Apart from the winners every child was rewarded for their active participation.
Gifts and memorabilia were distributed by the FIITJEE Global School’s Group Kindergarten Head, Aarti Sardana.
The event was marked by a lively emcee entertaining the audience with funny introductions and engaging children all through.
Children enjoyed jumping on bouncies and loved devouring the cotton candy floss.
On the occasion Magic Inkpots - the Kindergarten world of FIITJEE Global School was launched with much fanfare. The build-up to the event was preceded by a massive marketing drive that included kiosks, leaflet distribution, and social media activations


sestatus
Section: (8)Updated:<PHONE_NUMBER>
Index Return to Main Contents
NAME
sestatus - SELinux status toolSYNOPSIS
sestatus [-v] [-b] This tool is used to get the status of a system running SELinux.DESCRIPTION
This manual page describes the sestatus program.This tool is used to get the status of a system running SELinux. It displays data about whether SELinux is enabled, disabled, the loaded policy and whether it is in enforcing or permissive mode. It can also be used to display the security context of files and processes listed in the /etc/sestatus.conf file.
> sestatus
SELinux status: enabled
SELinuxfs mount: /selinux
Current Mode: permissive
Policy version: 16
OPTIONS
-
-v
Checks the contexts of a files , and a processes listed in the /etc/sestatus.conf file. It also checks the context of the target, in cases of symlinks.-b Display the current state of booleans.
FILES
/etc/sestatus.confAUTHOR
This man page was written by Daniel Walsh<EMAIL_ADDRESS>program was written by Chris PeBenito<EMAIL_ADDRESS>Index
This document was created by man2html, using the manual pages.
Time: 05:34:29 GMT, December 24, 2015


Latest version
Development versions
Basic version (without mod support)
This version is recommended for development, as it won't need you to provide the libraries for every mod in
it.
Full version (with mod support)
This version includes all mod support. You may need the development versions of the supported mods as well.
What's changed? Changelog
Archived versions
Version 3.0.9C
Version 3.0.9B
Version 3.0.9
Version 3.0.8B
Version 3.0.8
Version 3.0.7
Version 3.0.6
Version 3.0.5
Older versions than 3.0.5 have not been archived. I don't have them anymore...