Create an Animated LCD Display
LCD display using dynamically-animated SVGs.
A basic LCD digit consists of 7 segments . Each segment can be toggled on or off to display a total of 128 (2^7) states. 16 of these states correspond to a visual display of the numbers 0-9 and A-F. We’ll also include H, E, and L so we can spell ‘HELL0’).
Some displays have more segments . Diagonal segments can be included to display a greater range of letters. Some also contain a decimal point, so that floating-point numbers can be displayed.
To keep things simple, we’ll just stick to 0-9, A-F. But after you read this tutorial, try extending the display yourself!
How should we make these digits? We require segments that can easily be scaled to a large range of sizes while maintaining their position. We require segments that are individually manipulatable to generate patterns corresponding to letters. We want this to all happen without messy computation.
We can describe the LCD as a vector. Let’s use Scalable Vector Graphics .
SVG?
SVG is a an XML-derived markup language that tells browsers how to draw 2-D graphics.
There are some SVG primitives
that can be used to draw pictures. These are <rect>
, <circle>
, <ellipse>
, <line>
, <polyline>
, <polygon>
, and <path>
.
<svg xmlns="http://www.w3.org/2000/svg" version="1.1"
viewBox="0 0 32 32" height="32" width="32" style="border: 1px solid black">
<g><circle cx="16" cy="16" r="11"
fill-color="black" stroke="gold" stroke-width="5"/>
<circle cx="48" cy="48" r="11"
fill-color="black" stroke="gold" stroke-width="5"/></g>
</svg>
This code draws a black circle (fill-color) with center (16px, 16px), radius 11px, and a 5px (stroke-width) outline (stroke). It draws another circle at (48px, 48px) that you can’t see yet.
Cool, but wait: why do I only see one circle when there are two circles defined? viewBox
.
The viewBox
SVG tag specifies four values: min-x, min-y, width, height
.
viewBox
maps a rectangular area in user-space to the bounds of the SVG element.
This means that if the viewport width and height are equal to the first circle’s width and height, that circle fills the entire space. The second circle we drew at center (48px, 48px) exists, but it is hidden.
If we change width and height to 64px each, the first circle will take up the upper-left quadrant of the square, and the second circle will come into view in the bottom-left quadrant:
<svg xmlns="http://www.w3.org/2000/svg" version="1.1"
viewBox="0 0 64 64" height="32" width="32" style="border: 1px solid black">
<g><circle cx="16" cy="16" r="11"
fill-color="black" stroke="gold" stroke-width="5"/>
<circle cx="48" cy="48" r="11"
fill-color="black" stroke="gold" stroke-width="5"/></g>
</svg>
If you think through it, this makes sense. We’re mapping a rectangle 2x larger to our drawing, which has the effect of “zooming out” by a factor of 4 (we decreased width by a factor of 2 and area by 2^2).
Takeaway: we can set the viewBox to the bounds of our SVG element. When we change the height and width of the SVG, the element will be Scaled according to its Vector Graphic definition.
<svg xmlns="http://www.w3.org/2000/svg" version="1.1"
viewBox="0 0 32 32" height="128" width="128" style="border: 1px solid black">
<g><circle cx="16" cy="16" r="11"
fill-color="black" stroke="gold" stroke-width="5"/></g>
</svg>
Four times as big; just as crisp: no pixelation!
okay great, circles, but what about the LCD?
To draw the LCD, we can describe each digit as a collection of seven paths in space. We’ll compose seven path elements per digit. I’ll refer to these paths as grains, since they look a bit like grains of rice on the screen.
Path elements are the most powerful elements of SVG. They can be used to create complex paths like lines, curves, arcs, and LCD screens.
A path has a d
attribute. It contains a single string of browser instructions of how to draw the path.
The string is a combination of numeric coordinates and letter commands. M
means Move and is followed by an X and Y coordinate. L
means line-to: draw a line from the current position to the X and Y specified. h
means draw a horizontal line from the current X position to the given X position (the y-coordinate stays the same). z
means ‘close path’, or go back to the start.
So for this grain:
<path d="M2.1 2L.2 0h31.6l-1.9 2L28 4H4z" fill="tomato"/>
- Move to (2.1, 2).
- Draw a line to (0.2, 0).
- Draw a horizontal line to x=31.6.
- Draw a line to (1.9, 2).
- Draw a line to (28, 4).
- Draw a horizontal line to x=4.
- Return to the original point, (2.1, 2).
- Fill the enclosed space with tomato.
Profit:
look at the picture above and go through the eight steps. Hint: it starts at the bottom-left.
Every path has its own fill color and fill-opacity. We can set the fill color to be whatever color we’d like the digits to appear as, and then we can toggle the fill-opacity to turn a path “on” or “off”.
Here’s what the entire digit looks like:
<svg xmlns="http://www.w3.org/2000/svg" height="64" width="32">
<g fill="#0f0">
<path d="M2.1 2L.2 0h31.6l-1.9 2L28 4H4z" fill="tomato"/>
<path d="M0 16V1.2L2 3l1.9 2V29l-2 1-1.8.9z" fill-opacity="0.1"/>
<path d="M30 30l-2-1V5l2-1.9 2-2V31l-2-1z" fill-opacity="0.3"/>
<path d="M16 33.9H3.9l-1.9-1L.2 32l.2-.1 1.8-1 1.7-.8H28l1.9 1 1.8 1-1.9.9-1.9 1z" fill-opacity="0.5"/>
<path d="M0 48L.2 33l2 1 1.8 1v24l-2 1.8-1.8 2z" fill-opacity="0.6"/>
<path d="M30 60.9l-2-2V35l2-.9 2-1V62.9z" fill-opacity="0.8"/>
<path d="M1.5 62.6l1.9-2 .6-.5h24l1.4 1.4 1.9 <IP_ADDRESS>H.2z" fill-opacity="1.0"/>
</g>
</svg>
See how we can change color and opacity? See how each path is uniquely described by a single d
attribute that tells the browser how to draw the path? Are you getting excited? We’re almost there!
Code the grains!
It is possible to code SVG without using a GUI, just like we did above with the circles. However, working out the details for drawing each path yourself is tedious and error-prone. An open-source tool like Inkscape makes the task much more pleasant. It’s how I generated the paths you see above.
This is not an in-depth Inkscape tutorial. But I will give a brief overview of how I drew the digit.
File > New From Template > choose “default px”.
You’ll be presented with a lovely blank canvas. Let’s resize it to fit the shape we wish to draw.
File > Document Properties > Page tab.
Change the units from “mm” to “px” and set the width and height to 32px and 64px.
> Grid tab
Click “New” to generate a rectangular grid. This will give us something for our paths' lines to snap to. Close out of the Properties pane.
Edit > Create Guides Around the Page.
Now zoom in and you should have a nice grid on which to begin drawing your crystal.
I made each of my crystal elements 5px wide, with a slight gap between them of about a pixel. I drew the left side and then used Edit > Duplicate (Ctrl+D) and Object > Flip Horizontal (H) to mirror on the right side what I drew on the left to ensure symmetry.
I did the same thing with the top and bottom elements + a flip vertical instead.
All of my grains had four sides, except the middle crossbar: a rectangle with a triangle on other end.
Don’t worry if it’s not quite perfect. A pixel off here or there will make it look more natural, since a real LCD is going to have a few imperfections too. Experiment with shapes. Give it your own style.
When you finish drawing:
Edit > XML Editor.
See those seven paths under the svg:g id="layer1"
dropdown? Bingo! Each one of these paths corresponds to the outline of one of our seven grains.
Once you have drawn the seven grains, use the fill tool to fill in the background.
Now check XML editor again. See how it’s put in new paths for the fill? Since all that we care about is the fill, and we only used the outline to build containers to fill out, we can “Delete Node” on the top seven items in the list. As you delete each one, the outline will disappear from the picture.
Now you’re ready to save the SVG and grab the code.
File > Save A Copy
Choose Plain SVG (*.svg) for the format. This will get rid of extra Inkscape metadata.
open that file!
Go ahead and open up the .svg file in an editor of your choice. Interesting, huh? At the bottom, you’ll see a <g>
tag that contains seven <path>
tags. <g>
is just a way of telling SVG that you are grouping related elements: in this case, seven <path>
grains into a digit.
You want to grab the path information. It won’t look quite the same as my example above though. Here’s what one of my paths looked like before I cleaned it up:
<path
transform="translate(0,1058.5196)"
id="path5715"
d="M 3.6841521,2.5178497 1.2616471,0.09369836 H 16.01122 30.760792 L 28.338287,2.5178497 25.915782,4.942001 H 16.01122 6.1066572 Z"
style="fill:#00ff00;fill-opacity:1;stroke:#000000;stroke-width:0.01031554;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
/>
Lots of decimal places and a strange transform applied. The transform is something that happens when you’re drawing in Inkscape. The transform property, path data from d
and viewBox
all interact to make your element display properly. However, we don’t want to have this excess. Can’t we just convert the path based on the transform
and get rid of the transform
attribute altogether?
Yes. We can use SVGOMG to clean this up.
 In the toolbar on the right, Un-check “Merge Paths”. We need separate paths in order to manipulate them individually. You can play with the precision slider. This gets rid of some of the extra decimal places. Have a look at the preview image while you do this. At a certain point, the quality of the image starts to suffer when there’s not enough information in the path to provide an accurate geometric description. This is a tradeoff between file-size and rendering precision.
Grab the cleaned-up paths and you should have something like I posted above with your own SVG paths. You’re now ready to wire up this display!
hit me with those digits ~ programatically generating svg
We dynamically generate digits in the display using JS. Each path will have two attributes:
d
to provide the browser data on how to draw the pathstyle
to tell the browser how to style and fill the path it draws
style
is invariant for each grain. We’ll manipulate the fill-opacity later. All that differs is d
.
i need some space for my na me
If you’ve used VanillaJS to create an HTML element, this is similar. However, we’re putting svg inside of HTML. That’s fine to do, but svg and HTML do not have the same namespace .
 Imagine you have two people at the office named Bob. The boss calls out, “Hey Bob, can you make me a copy of your report?” There are two Bobs. There are two reports. Which Bob will think it’s him? Which report(s) will the boss get? There is no way to tell!
A code example: the HTML <title>
tag here
vs the SVG <title>
tag, here
. Wait, did you mean “Title of the document for the title bar”, or “Title of the SVG group”? Oh, SVG namespace? Okay, title of the SVG group. Now we’re sorted.
Namespaces capture the notion that the same name can mean a different thing in a different context. Here, the contexts are HTML and SVG. We use a namespace to define the context in which we are using a name, resolving ambiguity around its meaning. We get one report, and it’s the one we want.
Whenever we create an svg tag, we’ll use document.createElementNS()
, specifying the svg
namespace before the tag name. Like this:
var svg = document.createElementNS("http://www.w3.org/2000/svg", "svg");
createDigit
This is the core of the display code. It generates a 7-grained digit with a unique ID per grain. We stored each of the d
elements from the paths we created in an array, in order in which we are going to address them (top, top-left, top-right, middle, bottom-left, bottom-right, bottom).
We create an HTML container div
to hold the digit.
var digit = document.createElement("div");
digit.id = "digit";
We put the svg
element into the container. We set the viewbox, width, and height. We set the xlink
.
var svg = document.createElementNS("http://www.w3.org/2000/svg", "svg");
svg.setAttribute("viewBox", "0 0 32 64");
svg.setAttribute("width", this.width);
svg.setAttribute("height", this.height);
svg.setAttributeNS(
"http://www.w3.org/2000/xmlns/",
"xmlns:xlink",
"http://www.w3.org/1999/xlink"
);
digit.appendChild(svg);
We append a g
element to the svg
element to hold our seven grains.
var g = document.createElementNS("http://www.w3.org/2000/svg", "g");
g.setAttributeNS(null, "id", layerID);
svg.appendChild(g);
We append each of the seven path
elements to the g
element. We stored those path d
elements from the Inkscape file in an array.
const path_d = [
"M 2.102706,2.0144078 0.21966194,0.08855428 8.1139619,0.07386242 c 4.3418651,-0.0080805 11.4445871,-0.0080805 15.7838261,0 L 31.787315,0.08855428 29.918288,2.0150532 28.049261,3.9415521 16.017505,3.9409067 3.98575,3.9402615 Z",
// ... //
"last path",
];
for (var i = 0; i <= 6; i++) {
var path = document.createElementNS("http://www.w3.org/2000/svg", "path");
path.setAttributeNS(null, "id", "c_" + containerID + "_d_" + id + "_" + i);
path.setAttributeNS(null, "d", path_d[i]);
path.setAttributeNS(
null,
"style",
"fill:" + this.GRAIN_COLOR + ";fill-opacity:0.3;stroke:none"
);
g.appendChild(path);
}
Finally, we return the div
container from the function.
We can call this function as many times as we want to generate the digits for our counter. We’ll get a div
for each digit which we can then mount in a container box holding all the digits: our display.
why is the first argument to setAttributeNS
null?!
We do not need to provide a namespace prefix to id
, d
, or style
attributes, since there is no ambiguity around their usage within our <svg>
tag. Also, we do not want to namespace these attributes, because it will make selecting them with document.querySelector
incredibly tricky.
what about the weird IDs?
In order to display numbers on the LCD, we have to programmatically manipulate individual grains of digits. This means we need a unique ID for each grain and also for each digit.
In the demo you saw at the top of the page, we had to support the case of multiple counters per page. We must ensure uniqueness across these IDs as well.
This generates three levels of ID:
- container (holding an arbitrary number of displays, which are instances of our LCD object)
- digit (within container)
- grain (within digit)
I represent these IDs as numeric and zero-indexed in this format: c_{containerID}_d_{digitID}_i_{grainID}
. If there is a 3-digit display in the first container, we can access the 7 grains of the first (leftmost) digit by c_0_d_0_i_0
through c_0_d_0_i_6
.
let’s wire up the display!
Things are going to get fairly messy if we try to code things without organization, so let’s create an Object called LCD
. Inside the object we’ll define variables and methods to display output.
We construct this object by giving it a number of digits, a color, a height, and a background color.
We will make everything but the number of digits optional.
We define the width in terms of the height, so we only require a height for the display.
instanceID
is a unique numeric ID that is incremented once each time an LCD is created. We will also refer to it as containerID
: it is what we use to uniquely access a container of digits, or a display.
digitsOn
is an object that maps human-readable digits or letters we want to display to the indices of grains that must be turned on to display this digit (or letter). Try working your way through one of the numbers, envisioning the array’s indices turned on. Remember, we index in this order: top, top-left, top-right, middle, bottom-left, bottom-right, bottom.
We set fill-opacity
values for on (HIGH) and off (LOW).
We define a variable to hold the current value of the counter.
var LCD = (function () {
var id = 0;
function LCD(config = {}) {
const { numDigits, color, height, bgColor } = config;
if (!Number.isInteger(numDigits) || numDigits < 1) {
throw new Error("Cannot have non-integral number of digits");
}
this.backgroundColor = bgColor;
this.instanceID = ++id;
this.numDigits = numDigits || 3;
this.GRAIN_COLOR = color || "#00FF00";
this.height = height || "64"; //aspect ratio for the SVG is 1:2
this.width = height / 2;
this.padding = 8;
this.digitsOn = {
0: [0, 1, 2, 4, 5, 6],
1: [2, 5],
2: [0, 2, 3, 4, 6],
3: [0, 2, 3, 5, 6],
4: [1, 2, 3, 5],
5: [0, 1, 3, 5, 6],
6: [0, 1, 3, 4, 5, 6],
7: [0, 2, 5],
8: [0, 1, 2, 3, 4, 5, 6],
9: [0, 1, 2, 3, 5],
A: [0, 1, 2, 3, 4, 5],
B: [1, 3, 4, 5, 6],
C: [0, 1, 4, 6],
D: [2, 3, 4, 5, 6],
E: [0, 1, 3, 4, 6],
F: [0, 1, 3, 4],
H: [1, 2, 3, 4, 5],
L: [1, 4, 6],
};
this.HIGH_OPACITY = "1.0";
this.LOW_OPACITY = "0.15";
this.value = null;
}
return LCD;
})();
a namespace for the display
We wrapped this object in an IIFE (immediately-invoked function expression) . This provides a private namespace for the variables within our class, allowing us to expose only certain methods. We don’t want the user to be able to accidentally modify the number of digits in the display, for example.
We can expose methods of our choice to the user. A common exposure technique is get
ters and set
ters that do just what they sound like: get or set values of variables within the object.
I do not use the word class here. Why? JavaScript does not have classes
, in the traditional object-oriented sense. Although there is a new class
keyword in ES6, this is just syntactic sugar for prototypal inheritance
.
Objects inherit through other objects via the prototype chain. More to come on this topic, as it really deserves its own series.
a touch of CSS
I have a CSS reset
, a little padding, and then two flexboxes
: one to display the digits in each display, and one to display each display (how meta). I also added a CSS transition on fill-opacity
for prettiness. The browser automatically tweens
the values for us. Less JS to manage!
body {
padding: 10px;
background-color: #ffe;
}
#pageContainer {
display: flex;
width: 700px;
margin: auto;
padding: 10px;
flex-flow: row wrap;
border: 1px solid black;
}
.lcd-container {
margin: 10px;
border: 1px solid black;
display: flex;
flex-flow: row nowrap;
border-style: groove;
justify-content: center;
align-items: center;
}
div#digit {
padding: 4px;
}
svg > path {
transition: fill-opacity 250ms ease-in;
}
A good place for you to begin.
Here’s a CodePen that’s unfinished. Fork it, and try building out the rest of the class.
Here are some method names that might help get you going:
- init
- unmount
- getSize
- getValue
- setDigit
- setCounter
- resetDigit
- resetDisplay
- displayError
You can always peek at the finished product for hints. But imagine that you can use the object to display ‘999’ on the screen like this:
var display = new LCD({
numDigits: 3,
color: "#000000",
height: 40,
bgColor: "#FFFFFF",
});
let C = document.createElement("div");
display.init(C);
display.setCounter(999);
document.body.appendChild(C);
wait though, you coded more
You are correct. I included tinycolor
to dynamically generate random yet contrasty background and text colors for my random timers. I also set random values for the timers to start at and a random number of digits, and then I set up a setInterval
to have them all count upwards in unison.


Character Selection Menu
You can find a character by writing his or her name or a part of it in the box below.
Name:
Class:
Level:
%players%
%pages%


Unity's Co-Founders
Unity was founded in 1889 in Kansas City, Missouri, by Charles and Myrtle Fillmore. After Mrs. Fillmore’s remarkable healing using prayer and affirmations, many friends became interested in how she accomplished this healing. Unity grew from small prayer circles in living rooms to the worldwide movement it is today.
Unity Defined by Charles Filmore
"Unity is a link in the great educational movement inaugurated by Jesus Christ; our objective is to discern the truth in Christianity and prove it. The truth that we teach is not new; neither do we claim special revelations or discovery of new religious principles. Our purpose is to help and teach mankind to use and prove the eternal Truth taught by the Master."


Fitness Club Hours
- Monday-Thursday: 6:00am - 6:00pm
- Friday: 6:00am - 4:00pm
- Saturday: 8:00am - 6:00pm
- Sunday: Closed
Welcome to Forward Fitness Club. Our mission is to help our clients meet their fitness AND nutrition goals.
If you have struggled with getting healthy and need the motivation and resources to make a healthy lifestyle change, contact us today. Our facility includes state-of-the-art equipment,convenient group
training classes and nutrition tips and information to keep you healthy.
We provide a FREE, one-week membership for you to experience the benefits of our equipment and facility. This one-week trial gives you complete access to our equipment, training classes and nutrition planning.
Apply at the link below to start your free trial!


Spoofing Attacks
Contents
Description
- This is an attack based on the creation of Internet Protocol (IP) packets with a forged IP source address. This forging makes the packet appear as if it was sent from a different machine.
- This technique is very useful as part of certain other attacks, as a way of trying to disguise identity, and as a way to defeat portions of network security like IP address authentication.
- Carrying out an IP spoofing attack can be difficult, because it often means the header of thousand s of packets must be modified, one packet at a time . This can’t usually be done on a computer that’s running Microsoft Windows.
- To perform IP spoofing, the header of the packet must be modified. This header contains the following (among other data):
- Source IP
- Destination IP
- Checksum value
- Order value
* When packets are transmitted to the Internet, they will most likely arrive at their destination out of order and must be reassembled using the order sent value.
- When trust relationships exist between machines, these spoofing attacks can be especially effective. Some corporate networks make it a common practice to have trust relationships between various internal systems, so that a user can access other machines without a username or password as long as they are connecting from another machine on the internal network.
- Because of this connection from another system, they are assumed to have been authenticated by that system.
- By spoofing a connection from another machine in a trust relationship with the target, an attacker might be able to access the target machine without authenticating.
Nonblind Spoofing
- To perform this type of spoofing attack, the attacker needs to be on the same subnet as the target. The attacker can then use a packet sniffer to view the sequence and acknowledgment numbers, which means that the attacker doesn't have to worry about calculating them accurately and correctly. The biggest threat of spoofing in this case is session hijacking.
Blind Spooling
- In this attack, the sequence and acknowledgment numbers are unreachable and unknown.
- To try to provide a basis for guessing or calculating the sequence and acknowledgment numbers, several sample packets are sent to the target machine to obtain sample sequence numbers.
- It was once a common practice to use simple methods to generate these sequence numbers, which also made them easy to guess and calculate.
- Now, sequence numbers are typically the result of random number generation which makes it harder to predict the sequence.
Denial of Service Attack
- IP spoofing is almost always a component of denial-of-service, or DOS, attacks. Because the goal of these attacks is to consume bandwidth or other resources, there is no need to worry about properly completing the handshake or transactions.
- To consume these resources, the attacker wants to flood the victim with as many packets as possible and as quickly as possible.
- To prolong the attack, the attacker will forge source IP addresses on these packets to make tracing and stopping the DoS as difficult as possible.
- When multiple hosts are involved, and all of them are sending spoofed traffic, it can be very hard to block the traffic quickly. This tends to be a task where attackers use their army of bots.
Anatomy of an Exploit
- Nonblind Attack:
- The attacker sets up a packet sniffer and collects the packet data from the system they are targeting to see what the pattern of sequence and acknowledgment numbers are.
- If a pattern can be detected. The attacker can construct a packet that uses that pattern and spoofs the IP address they want to attack.
Real-World Examples
- The most famous use of an IP spoofing attack is probably that of Kevin Mitnick's attack against Tsutomu Shimomura in December 2004. It's important to note, first, that IP spoofing was a component of this attack but not the sole vulnerability used.
- The initial sign of this attack was some probes against various machines. apparently to see if there might be an exploitable trust relationship between these machines.
- Then SYN flooding was used to make the first victim computer unable to respond to requests, while the attacking machine first probed for specific TCP behavior and sequencing. Then spoofed IP address of the first victim computer was used to issue a SYN request to the second victim computer, and Mitnick eventually gained root access on the second victim computer.
Test Techniques
- IP spoofing really isn’t a solvable problem, but the use of encryption and decryption should be tested as in some of the other attacks like man-in-the-middle or session-hijacking.
External Links
Panel title
Percipit Mnesarchum
Molestie Phaedrum Luptatum
constituam Habeo adipisci Inani
zril Forensibus sea Habeo
adipisci Minimum corrumpit Regione
suscipit Has et partem Percipit
Mnesarchum Molestie Phaedrum
Luptatum constituam Habeo
adipisci Inani zril Vel
nisl albucius Habeo adipisci Minimum
corrumpit Regione suscipit Percipit
maiestatis Regione suscipit Percipit
maiestatis
Subtitle


DMSP 5D-2/F8 is one of a series of meteorological satellites developed and operated by the
Air Force under the Defense Meteorological Satellite Program (DMSP). Its pre-launch designation was DMSP
5D-2/S9. This program, previously known as DAPP (Data Acquisition and Processing Program), was classified
until March 1973. The objective of this program is to provide global visual and infrared cloudcover data
and specialized environmental data to support Department of Defense operational weather analysis and
forecasting requirements. Operationally, the program consists of two satellites in sun-synchronous polar
orbits, with the ascending node of one satellite in early morning and the other at local noon.
The local time nodes for DMSP F8 are 06:00 and 18:00.
The 6.4-m-long
spacecraft is separated into four sections: (1) a precision mounting platform for sensors and equipment
requiring precise alignment; (2) an equipment support module containing the electronics, reaction wheels,
and some meteorological sensors; (3) a reaction control equipment support structure containing the
third-stage rocket motor and supporting the ascent phase reaction control equipment; and (4) a 9.29-sq-m
solar cell panel. The spacecraft stabilization is controlled by a combination flywheel and magnetic control
coil system so sensors are maintained in the desired earth-looking mode. One feature is the precision-pointing
accuracy of the primary imager to 0.01 deg provided by a star sensor and an updated ephemeris navigation
system. This allows automatic geographical mapping of the digital imagery to the nearest picture element.
The operational linescan system is the primary data acquisition system that provides real-time or stored,
multi-orbit, day-and-night, visual and infrared imagery of clouds. A supplementary sensor package contains
five special sensors: (1) a microwave temperature sounder, (2) an advanced X-ray detector, (3) an
ionospheric/scintillation monitor, (4) a precipitating electron/ion spectrometer, and (5) a microwave imager.
An infrared temperature and moisture sounder and a magnetometer may also be included on this spacecraft.
Either recorded or real-time data are transmitted to ground-receiving sites by two redundant S-band
transmitters. Recorded data are read out to tracking sites located at Fairchild AFB, Wash., and at
Loring AFB, Maine, and relayed by SATCOM to Air Force Global Weather Central, Offutt AFB, Nebraska.
Version:2.2.2
DMSP 5D-2/F8 is one of a series of meteorological satellites developed and operated by the
Air Force under the Defense Meteorological Satellite Program (DMSP). Its pre-launch designation was DMSP
5D-2/S9. This program, previously known as DAPP (Data Acquisition and Processing Program), was classified
until March 1973. The objective of this program is to provide global visual and infrared cloudcover data
and specialized environmental data to support Department of Defense operational weather analysis and
forecasting requirements. Operationally, the program consists of two satellites in sun-synchronous polar
orbits, with the ascending node of one satellite in early morning and the other at local noon.
The local time nodes for DMSP F8 are 06:00 and 18:00.
The 6.4-m-long
spacecraft is separated into four sections: (1) a precision mounting platform for sensors and equipment
requiring precise alignment; (2) an equipment support module containing the electronics, reaction wheels,
and some meteorological sensors; (3) a reaction control equipment support structure containing the
third-stage rocket motor and supporting the ascent phase reaction control equipment; and (4) a 9.29-sq-m
solar cell panel. The spacecraft stabilization is controlled by a combination flywheel and magnetic control
coil system so sensors are maintained in the desired earth-looking mode. One feature is the precision-pointing
accuracy of the primary imager to 0.01 deg provided by a star sensor and an updated ephemeris navigation
system. This allows automatic geographical mapping of the digital imagery to the nearest picture element.
The operational linescan system is the primary data acquisition system that provides real-time or stored,
multi-orbit, day-and-night, visual and infrared imagery of clouds. A supplementary sensor package contains
five special sensors: (1) a microwave temperature sounder, (2) an advanced X-ray detector, (3) an
ionospheric/scintillation monitor, (4) a precipitating electron/ion spectrometer, and (5) a microwave imager.
An infrared temperature and moisture sounder and a magnetometer may also be included on this spacecraft.
Either recorded or real-time data are transmitted to ground-receiving sites by two redundant S-band
transmitters. Recorded data are read out to tracking sites located at Fairchild AFB, Wash., and at
Loring AFB, Maine, and relayed by SATCOM to Air Force Global Weather Central, Offutt AFB, Nebraska.
| Role | Person | |
|---|---|---|
| 1. | GeneralContact | spase://SMWG/Person/Dieter.K.Bilitza |
Information about the DMSP 5D-2/F08 mission.
Information about the Defense Meteorological Satellite Program.


404 Not Found
The request
/inspinia_admin-v2.7.1/css/plugins/fonts/glyphicons-halflings-regular.eot?
was not found on this server.


Select a limited number of colors to use in the pixelized version of this image. Use the eye dropper in the colorpicker to select colors from the image below, if desired.
Select a color to paint with. Use the eye dropper in the colorpicker to select colors from the image below, if desired. Click and drag (slowly) on the image to repaint with your new color.


| Home | Libraries | People | FAQ | More |
When building Boost.Interprocess architecture, I took some basic guidelines that can be summarized by these points:
Boost.Interprocess is built above 3 basic classes: a memory algorithm, a segment manager and a managed memory segment:
The memory algorithm is an object that is placed in the first bytes of a shared memory/memory mapped file segment. The memory algorithm can return portions of that segment to users marking them as used and the user can return those portions to the memory algorithm so that the memory algorithm mark them as free again. There is an exception though: some bytes beyond the end of the memory algorithm object, are reserved and can't be used for this dynamic allocation. This "reserved" zone will be used to place other additional objects in a well-known place.
To sum up, a memory algorithm has the same mission as malloc/free of standard C library, but it just can return portions of the segment where it is placed. The layout of a memory segment would be:
Layout of the memory segment: ____________ __________ ____________________________________________ | | | | | memory | reserved | The memory algorithm will return portions | | algorithm | | of the rest of the segment. | |____________|__________|____________________________________________|
The memory algorithm takes care of memory synchronizations, just like malloc/free guarantees that two threads can call malloc/free at the same time. This is usually achieved placing a process-shared mutex as a member of the memory algorithm. Take in care that the memory algorithm knows nothing about the segment (if it is shared memory, a shared memory file, etc.). For the memory algorithm the segment is just a fixed size memory buffer.
The memory algorithm is also a configuration point for the rest of the Boost.Interprocess framework since it defines two basic types as member typedefs:
typedef /*implementation dependent*/ void_pointer; typedef /*implementation dependent*/ mutex_family;
The void_pointer
typedef defines the pointer type that will be used in the
Boost.Interprocess framework (segment manager, allocators, containers). If the memory
algorithm is ready to be placed in a shared memory/mapped file mapped in different base
addresses, this pointer type will be defined as offset_ptr<void>
or a similar relative
pointer. If the memory algorithm will be used just with fixed address mapping,
void_pointer
can be defined as void*
.
The rest of the interface of a Boost.Interprocess memory algorithm is described in
Writing a new shared memory allocation algorithm
section. As memory algorithm examples, you can see the implementations
simple_seq_fit
or
rbtree_best_fit
classes.
The segment manager, is an object also placed in the first bytes of the managed memory segment (shared memory, memory mapped file), that offers more sophisticated services built above the memory algorithm. How can both the segment manager and memory algorithm be placed in the beginning of the segment? That's because the segment manager owns the memory algorithm: The truth is that the memory algorithm is embedded in the segment manager:
The layout of managed memory segment: _______ _________________ | | | | | some | memory | other |<- The memory algorithm considers |members|algorithm|members| "other members" as reserved memory, so |_______|_________|_______| it does not use it for dynamic allocation. |_________________________|____________________________________________ | | | | segment manager | The memory algorithm will return portions | | | of the rest of the segment. | |_________________________|____________________________________________|
The segment manager initializes the memory algorithm and tells the memory manager that it should not use the memory where the rest of the segment manager's member are placed for dynamic allocations. The other members of the segment manager are a recursive mutex (defined by the memory algorithm's mutex_family::recursive_mutex typedef member), and two indexes (maps): one to implement named allocations, and another one to implement "unique instance" allocations.
typeid(T).name()
operation.
The memory needed to store [name pointer, object information] pairs in the index is
allocated also via the memory algorithm, so we can tell that internal indexes
are just like ordinary user objects built in the segment. The rest of the memory
to store the name of the object, the object itself, and meta-data for
destruction/deallocation is allocated using the memory algorithm in a single
allocate()
call.
As seen, the segment manager knows nothing about shared memory/memory mapped files. The segment manager itself does not allocate portions of the segment, it just asks the memory algorithm to allocate the needed memory from the rest of the segment. The segment manager is a class built above the memory algorithm that offers named object construction, unique instance constructions, and many other services.
The segment manager is implemented in Boost.Interprocess by
the segment_manager
class.
template<class CharType ,class MemoryAlgorithm ,template<class IndexConfig> class IndexType> class segment_manager;
As seen, the segment manager is quite generic: we can specify the character type to be used to identify named objects, we can specify the memory algorithm that will control dynamically the portions of the memory segment, and we can specify also the index type that will store the [name pointer, object information] mapping. We can construct our own index types as explained in Building custom indexes section.
The Boost.Interprocess managed memory segments that construct the shared memory/memory
mapped file, place there the segment manager and forward the user requests to the
segment manager. For example, basic_managed_shared_memory
is a Boost.Interprocess managed memory segment that works with shared memory.
basic_managed_mapped_file
works with memory mapped files, etc...
Basically, the interface of a Boost.Interprocess managed memory segment is the same as the segment manager but it also offers functions to "open", "create", or "open or create" shared memory/memory-mapped files segments and initialize all needed resources. Managed memory segment classes are not built in shared memory or memory mapped files, they are normal C++ classes that store a pointer to the segment manager (which is built in shared memory or memory mapped files).
Apart from this, managed memory segments offer specific functions: managed_mapped_file
offers functions to flush memory contents to the file, managed_heap_memory
offers
functions to expand the memory, etc...
Most of the functions of Boost.Interprocess managed memory segments can be shared between all managed memory segments, since many times they just forward the functions to the segment manager. Because of this, in Boost.Interprocess all managed memory segments derive from a common class that implements memory-independent (shared memory, memory mapped files) functions: boost::interprocess::detail::basic_managed_memory_impl
Deriving from this class, Boost.Interprocess implements several managed memory classes, for different memory backends:
basic_managed_shared_memory
(for shared memory).
basic_managed_mapped_file
(for memory mapped files).
basic_managed_heap_memory
(for heap allocated memory).
basic_managed_external_buffer
(for user provided external buffer).
The Boost.Interprocess STL-like allocators are fairly simple and follow the usual C++ allocator approach. Normally, allocators for STL containers are based above new/delete operators and above those, they implement pools, arenas and other allocation tricks.
In Boost.Interprocess allocators, the approach is similar, but all allocators are based on the segment manager. The segment manager is the only one that provides from simple memory allocation to named object creations. Boost.Interprocess allocators always store a pointer to the segment manager, so that they can obtain memory from the segment or share a common pool between allocators.
As you can imagine, the member pointers of the allocator are not a raw pointers, but
pointer types defined by the segment_manager::void_pointer
type. Apart from this,
the pointer
typedef of Boost.Interprocess allocators is also of the same type of
segment_manager::void_pointer
.
This means that if our allocation algorithm defines void_pointer
as offset_ptr<void>
,
boost::interprocess::allocator<T>
will store an offset_ptr<segment_manager>
to point to the segment manager and the boost::interprocess::allocator<T>::pointer
type
will be offset_ptr<T>
. This way, Boost.Interprocess allocators can be placed in the
memory segment managed by the segment manager, that is, shared memory, memory mapped files,
etc...
Segregated storage pools are simple and follow the classic segregated storage algorithm.
The pool is implemented by the private_node_pool and shared_node_pool classes.
Adaptive pools are a variation of segregated lists but they have a more complicated approach:
The adaptive pool is implemented by the private_adaptive_node_pool and adaptive_node_pool classes.
Boost.Interprocess containers are standard conforming counterparts of STL containers
in boost::interprocess
namespace, but with these little details:
operator==()
to know if this is possible.
pointer
type defined by the allocator of the container. This
allows placing containers in managed memory segments mapped in different base addresses.
This section tries to explain the performance characteristics of Boost.Interprocess, so that you can optimize Boost.Interprocess usage if you need more performance.
You can have two types of raw memory allocations with Boost.Interprocess classes:
allocate()
and deallocate()
functions of
managed_shared_memory/managed_mapped_file... managed memory segments. This call is
translated to a MemoryAlgorithm::allocate()
function, which means that you
will need just the time that the memory algorithm associated with the managed memory segment
needs to allocate data.
boost::interprocess::allocator<...>
with
Boost.Interprocess containers. This allocator calls the same MemoryAlgorithm::allocate()
function than the explicit method, every time a vector/string has to reallocate its
buffer or every time you insert an object in a node container.
If you see that memory allocation is a bottleneck in your application, you have these alternatives:
flat_map
family instead
of the map family if you mainly do searches and the insertion/removal is mainly done
in an initialization phase. The overhead is now when the ordered vector has to
reallocate its storage and move data. You can also call the reserve()
method
of these containers when you know beforehand how much data you will insert.
However in these containers iterators are invalidated in insertions so this
substitution is only effective in some applications.
allocate()
only when the pool runs out of nodes. This is pretty
efficient (much more than the current default general-purpose algorithm) and this
can save a lot of memory. See
Segregated storage node allocators and
Adaptive node allocators for more information.
Boost.Interprocess allows the same parallelism as two threads writing to a common structure, except when the user creates/searches named/unique objects. The steps when creating a named object are these:
insert()
function in the index. So the time this
requires is dependent on the index type (ordered vector, tree, hash...).
This can require a call to the memory algorithm allocation function if
the index has to be reallocated, it's a node allocator, uses pooled allocations...
The steps when destroying a named object using the name of the object
(destroy<T>(name)
) are these:
find(const key_type &)
and erase(iterator)
members of the index. This can require element reordering if the index is a
balanced tree, an ordered vector...
The steps when destroying a named object using the pointer of the object
(destroy_ptr(T *ptr)
) are these:
Depending on the index type, this can be different:
boost::interprocess::is_node_index
specialization): Take the iterator stored near the object and call
erase(iterator)
. This can require element reordering if the index is a
balanced tree, an ordered vector...
If you see that the performance is not good enough you have these alternatives:


1.  What is Jayshree's favorite color?
2.  Who is Jayshree's favorite Friends' character?
3.  Which one of these is Jayshree's favourite TV Series?
4.  What would Jayshree do if she won the lottery?
5.  Which of the following is Jayshree's dream city?
6.  Which one of these is Jayshree's favourite Bollywood movie?
7.  Who is Jayshree's favourite cricketer?
8. Who does Jayshree claim is her favourite footballer?
9.  Which of these is Jayshree's favorite football club?


VBV
Superhero Matchup
Choose Your Characters and See Who Would Win
Select your Character
VS
Fight!
Select your Character


Company Intro<EMAIL_ADDRESS>Work Hours and Days<EMAIL_ADDRESS>Pay Frequency<EMAIL_ADDRESS>Paid Holidays<EMAIL_ADDRESS>Vacation and Sick Days<EMAIL_ADDRESS>Separate vacation/Sick time<EMAIL_ADDRESS>Vacation Process<EMAIL_ADDRESS>Maternity Leave Time<EMAIL_ADDRESS>Maternity Leave Pay<EMAIL_ADDRESS>Workers Compensation<EMAIL_ADDRESS>Bereavement<EMAIL_ADDRESS>Other Comments: {{@POST.other_comments}}


Greatest TC
问题描述 :
TC (Tian Chao) is magical place, as you all know…
The railways and the rail-stations in TC are fragile and always meet with different kinds of problems. In order to reach the destination safely on time, you are asked to develop a system which has two types of main functions as below.
1: A B C D, reporting whether we can get from station A to station B without passing the railway that connects station C and station D.
2: A B C, reporting whether we can get from station A to station B without passing station C.
Please notice that the railways are UNDIRECTED.
The railways and the rail-stations in TC are fragile and always meet with different kinds of problems. In order to reach the destination safely on time, you are asked to develop a system which has two types of main functions as below.
1: A B C D, reporting whether we can get from station A to station B without passing the railway that connects station C and station D.
2: A B C, reporting whether we can get from station A to station B without passing station C.
Please notice that the railways are UNDIRECTED.
输入:
For each test case, the first line will contain two integers N (2<=N<=100000) and M (1<=M<=500000), namely the number of stations and railways in TC. Then each of the next M lines will have two integers, describing the two stations that a certain railway is connecting. After this, there comes a line containing a single integer Q (Q<=300000), which means the number of queries to make on the system. The next Q lines will be queries. Each query begins with a integer, indicating the type of query, followed by 4 (the first type) or 3 (the second type) integers describing the details of the query as what mentioned above.
The stations are always labeled from 1 to N.
The stations are always labeled from 1 to N.
输出:
For each test case, the first line will contain two integers N (2<=N<=100000) and M (1<=M<=500000), namely the number of stations and railways in TC. Then each of the next M lines will have two integers, describing the two stations that a certain railway is connecting. After this, there comes a line containing a single integer Q (Q<=300000), which means the number of queries to make on the system. The next Q lines will be queries. Each query begins with a integer, indicating the type of query, followed by 4 (the first type) or 3 (the second type) integers describing the details of the query as what mentioned above.
The stations are always labeled from 1 to N.
The stations are always labeled from 1 to N.
样例输入:
13 15 1 2 2 3 3 5 2 4 4 6 2 6 1 4 1 7 7 8 7 9 7 10 8 11 8 12 9 12 12 13 5 1 5 13 1 2 1 6 2 1 4 1 13 6 7 8 2 13 6 7 2 13 6 8
样例输出:
yes yes yes no yes
#include<cstdio> #include<cstring> #include<cstdlib> #include<iostream> #include<string> #include<queue> #include<stack> #include<vector> #include<map> #include<set> #include<cmath> #include<list> #include<cctype> #include<ctime> #include<algorithm> using namespace std; #define min(a,b) ((a)<(b)?(a):(b)) #define max(a,b) ((a)>(b)?(a):(b)) #define inf -1u>>1 #define MP(x,y) make_pair(x,y) #define two(x) (1<<x) #define eps 1e-8 const double pi=acos(-1.0); /***************By Asakura*****************/ #define N 100005 #define M 500005 struct edge{ int v; int next; int vis; }ee[M*2]; int n,m,root,low[N],dfn[N],p[N],leave[N],deep[N],tot,cnt; int dp[25][N]; void init() { tot=0; cnt=0; memset(p,-1,sizeof(p)); memset(dfn,0,sizeof(dfn)); memset(low,0,sizeof(low)); memset(dp,-1,sizeof(dp)); memset(deep,-1,sizeof(deep)); memset(leave,-1,sizeof(leave)); } void add(int u,int v) { ee[cnt].v=v;ee[cnt].next=p[u];ee[cnt].vis=0; p[u]=cnt++; ee[cnt].v=u;ee[cnt].next=p[v];ee[cnt].vis=0; p[v]=cnt++; } void dfs(int u,int dep) { dfn[u]=low[u]=++tot; deep[u]=dep; int i; for(i=p[u];~i;i=ee[i].next) { if(ee[i].vis)continue; ee[i].vis=ee[i^1].vis=1; int v=ee[i].v; if(!dfn[v]) { dfs(v,dep+1); low[u]=min(low[u],low[v]); dp[1][v]=u; } else low[u]=min(low[u],dfn[v]); } leave[u]=tot; } void tarjan() { int i,j; for(i=1;i<=n;i++) if(!dfn[i]) dfs(i,0); for(i=2;i<20;i++) for(j=1;j<=n;j++) if(dp[i-1][j]!=-1) dp[i][j]=dp[i-1][dp[i-1][j]]; } bool s_tree(int x,int root) { if(dfn[x]>=dfn[root]&&leave[x]<=leave[root]) return true; return false; } int find(int x,int sp) { int i,cnt=1,t=x; if(sp<0) return -1; while(sp) { if(sp&1) t=dp[cnt][t]; cnt++; sp>>=1; } return t; } bool judgeE(int s,int t,int u,int v) { if(deep[u]<deep[v]) swap(u,v); bool flag=0; bool f1=s_tree(s,u); bool f2=s_tree(t,u); if(!f1&&!f2) flag=1; else if(f1&&f2) flag=1; else if(f1^f2&&low[u]<=dfn[v]) flag=1; return flag; } bool judgeV(int s,int t,int u) { bool f1=s_tree(s,u); bool f2=s_tree(t,u); bool flag=0; int tmd1,tmd2; if(!f1&&!f2) flag=1; else if(f1&&!f2) { tmd1=find(s,deep[s]-deep[u]-1); if(low[tmd1]<dfn[u]&&tmd1!=-1) flag=1; } else if(!f1&&f2) { tmd2=find(t,deep[t]-deep[u]-1); if(low[tmd2]<dfn[u]&&tmd2!=-1) flag=1; } else { tmd1=find(s,deep[s]-deep[u]-1); tmd2=find(t,deep[t]-deep[u]-1); if(tmd1==tmd2) flag=1; else if(low[tmd1]<dfn[u]&&low[tmd2]<dfn[u]) flag=1; } return flag; } int main() { int u,v,q,type,s,t,a,b,i; while(scanf("%d%d",&n,&m)!=EOF) { init(); for(i=1;i<=m;i++) { scanf("%d%d",&u,&v); add(u,v); } tarjan(); scanf("%d",&q); while(q--) { scanf("%d",&type); if(type==1) { scanf("%d%d%d%d",&s,&t,&u,&v); if(judgeE(s,t,u,v)) puts("yes"); else puts("no"); } else { scanf("%d%d%d",&s,&t,&u); if(judgeV(s,t,u)) puts("yes"); else puts("no"); } } } return 0; }
(adsbygoogle = window.adsbygoogle || []).push({});
这些内容在微博都看过了，没有新意了。。嘛，总比没得好。弱弱问句：二叨是不是坐着月子啊？
这些内容在微博都看过了，没有新意了。。嘛，总比没得好。弱弱问句：二叨是不是坐着月子啊？
这些内容在微博都看过了，没有新意了。。嘛，总比没得好。弱弱问句：二叨是不是坐着月子啊？
这些内容在微博都看过了，没有新意了。。嘛，总比没得好。弱弱问句：二叨是不是坐着月子啊？
这些内容在微博都看过了，没有新意了。。嘛，总比没得好。弱弱问句：二叨是不是坐着月子啊？
这些内容在微博都看过了，没有新意了。。嘛，总比没得好。弱弱问句：二叨是不是坐着月子啊？
这些内容在微博都看过了，没有新意了。。嘛，总比没得好。弱弱问句：二叨是不是坐着月子啊？
这些内容在微博都看过了，没有新意了。。嘛，总比没得好。弱弱问句：二叨是不是坐着月子啊？
这些内容在微博都看过了，没有新意了。。嘛，总比没得好。弱弱问句：二叨是不是坐着月子啊？
这些内容在微博都看过了，没有新意了。。嘛，总比没得好。弱弱问句：二叨是不是坐着月子啊？
这些内容在微博都看过了，没有新意了。。嘛，总比没得好。弱弱问句：二叨是不是坐着月子啊？
这些内容在微博都看过了，没有新意了。。嘛，总比没得好。弱弱问句：二叨是不是坐着月子啊？
这个也是算法导论的习题
漏了一个"不"，已修正:)
不错，现在就缺少新的资料
很好。代码比书上的简练！
跟书上的解法不一样，不知道哪个效率要高些
有的，已更新
这道题目的核心一句话是：取还是不取。
如果当前取，则index+1作为参数。如果当前不取，则任用index作为参数。
有谁知道直接遍历的方法中第8行是什么意思嘛？
漏了一个"不"，已修正:)
网站做得很好看，内容也多，全。前段时间在博客园里看到有人说：网页的好坏看字体。觉得微软雅黑的字体很好看，然后现在这个网站也用的这个字体！nice!
very good solutions.
Thanks for taking the time to examine this, I really feel strongly about it and love studying a lot more on this topic. If possible, as you acquire experience
辛苦了，顶
整理的很好，学习了


Dr._Stone
One fateful day, all of humanity was petrified by a blinding flash of light. After several millennia, high schooler Taiju awakens and finds himself lost in a world of statues. However, he's not alone! His science-loving friend Senku's been up and running for a few months and he's got a grand plan in mind—to kickstart civilization with the power of science!


Kinabalu Coders is a nick name for our more lengthy official name: Persatuan Pengaturcara dan Pembina ICT Sabah (Sabah Coders and ICT Builders Association). An officially registered entity with the Malaysian Registrar of Societies in May 2014, our members consist of leads, organisers, and active participants of the open technology communities and technology-based development industries in Sabah. Kinabalu Coders acts as a conduit that allows for open communities to engage together, with little constrain on formalities that many non-registered groups often face.
Our main goal is to increase the socio-economic standard of local communities using ICT and computerised applications. We also drive social awareness and expose up-to-date creative and innovative concepts conceived from the IT world; and strive to improve the overall proficiency of our local developer community.
Each of the open community is led by passionate volunteers. To find out more about our specific community and activity, connect with us or contact the leads and organisers listed for each community.
Makerspace is a meetup of community-led activities for robotics and maker enthusiasts. Activities centres around peer-learning and knowledge sharing in the form of workshops, presentations, and lectures. Our makerspace test lab is equipped with affordable, open source electronic materials, workshop equipment such as CNC machines, 3D printing, and other awesome maker equipment.
Major event(s): RoboNeo
Google Developer Group Kota Kinabalu (or simply known as GDGKK) is an open group where you can come learn about building services using Google technologies. We'll be bringing in technology experts from within and outside of KK to share their knowledge, and use this platform to support each other in building up our expertise.
Major event(s): Google I/O Extended, DevFest
CoderDojo is an open source, volunteer led network of free computer programming clubs for young people aged 7 to 17. CoderDojo puts an emphasis on self-motivated learning through project work, peer-to-peer mentoring and the creation of socially innovative projects.
Coming soon.
Rails Girls KK is a programme designed to teach women programming skills using the Ruby on Rails language. Its aim is to give tools and a community for women to understand technology and to build their ideas. Participants learn sketching, prototyping, basic programming and get introduced to the world of technology. Starting January 2015.
The Software Testing Community is an effort to promote best practices in software development by creating awareness of the importance of testing in their work. Other than scheduled knowledge sharing sessions, study group sessions will be done starting January 2015, and is based on Udacity's Software Testing syllabus developed by Google.
We always welcome support in form of cash and preferably kind. Contact any of our open community leads listed above to find out how you can help.
More than anything, we would love your support by attending our events and activities. If you have something to share, or if you are keen to create a specific tech-related open community and need a platform to do so, let us know, too. We are happy to lend you a hand.
Come to any of our supported open community activities, and you're in! Feel free to email us to provide some feedback, give us suggestions, or just say hello!


[1]
room , i booked this thru booking.com and should have probably available myself of their help .
[2]
sunday night -/: i had alerted the hotel of the late check-in time -lrb-/-lrb- approx 2 .


Protocols
The following protocols are available globally.
-
This protocol should be inhereted by the Environment enum.
See moreDeclaration
Swift
public protocol EnvironmentProtocol
-
Undocumented
See moreDeclaration
Swift
public protocol TransformerProtocol : NSObject
-
Use this protocol to define repositories as enums.
See moreDeclaration
Swift
public protocol EndpointProtocol
-
Use this protocol to create interceptors that can be passed to Configuration instances. Every class which implements this protocol will intercept between request completion and callbacks.
See moreDeclaration
Swift
public protocol InterceptorProtocol
-
This protocol is used to register a middleware in order to modify body and headers of a request. (e.g. it can be used with Crypto Swift library to encrypt or decrypt the data.
See moreDeclaration
Swift
public protocol RequestMiddlewareProtocol


Wyatt
1.0.1
Main Page
Classes
Files
Class List
Class Index
Class Hierarchy
Class Members
Class Hierarchy
Go to the textual class hierarchy
Generated by
1.8.11


Class for handling the UI of the Inventory.
More...
Class for handling the UI of the Inventory.
◆ Start()
| void InventoryUI.Start |
( |
| ) |
|
|
private |
◆ Update()
| void InventoryUI.Update |
( |
| ) |
|
|
private |
◆ UpdateStats()
| void InventoryUI.UpdateStats |
( |
| ) |
|
◆ UpdateUI()
| void InventoryUI.UpdateUI |
( |
| ) |
|
|
private |
Update the UI when an item changes.
◆ FirstButton
| GameObject InventoryUI.FirstButton |
Reference to the first item slot button.
◆ inventory
◆ inventoryUI
| GameObject InventoryUI.inventoryUI |
◆ itemParent
| Transform InventoryUI.itemParent |
Reference to container of all the Item slots.
◆ slots
◆ stats
| TextMeshProUGUI InventoryUI.stats |
Reference to UI text that displays each Stat.
◆ trust
| TextMeshProUGUI InventoryUI.trust |
Reference to UI text that displays the trust level.
The documentation for this class was generated from the following file:
- C:/Users/Shaki/Desktop/Final Year/Final Year Project/Withering/Withering/Assets/Scripts/Inventory/InventoryUI.cs


AT90USB USB register definitions. More...
Go to the source code of this file.
Defines | |
AT90USB USB hardware control register | |
| #define | AT90USB_UHWCON_UVREGE (1 << 0) |
| USB pad regulator enable. | |
| #define | AT90USB_UHWCON_UVCONE (1 << 4) |
| UVCON pin enable. | |
| #define | AT90USB_UHWCON_UIDE (1 << 6) |
| UID pin enable. | |
| #define | AT90USB_UHWCON_UIMOD (1 << 7) |
| USB mode. | |
AT90USB USB control register | |
| #define | AT90USB_USBCON_VBUSTE (1 << 0) |
| VBUS transition interrupt enable. | |
| #define | AT90USB_USBCON_IDTE (1 << 1) |
| ID transition interrupt enable. | |
| #define | AT90USB_USBCON_OTGPADE (1 << 4) |
| OTG pad enable. | |
| #define | AT90USB_USBCON_FRZCLK (1 << 5) |
| Freeze USB clock. | |
| #define | AT90USB_USBCON_HOST (1 << 6) |
| HOST enable. | |
| #define | AT90USB_USBCON_USBE (1 << 7) |
| USB macro enable. | |
AT90USB USB status register | |
| #define | AT90USB_USBSTA_VBUS (1 << 0) |
| VBus flag. | |
| #define | AT90USB_USBSTA_ID (1 << 1) |
| IUD pin flag. | |
| #define | AT90USB_USBSTA_SPEED (1 << 3) |
| Speed status flag. | |
AT90USB USB interrupt register | |
| #define | AT90USB_USBINT_VBUSTI (1 << 0) |
| IVBUS transition interrupt flag. | |
| #define | AT90USB_USBINT_IDTI (1 << 1) |
| D transition interrupt flag. | |
AT90USB USB OTG control register | |
| #define | AT90USB_USBOTG_VBUSRQC (1 << 0) |
| VBUS request clear. | |
| #define | AT90USB_USBOTG_VBUSREQ (1 << 1) |
| VBUS request. | |
| #define | AT90USB_USBOTG_VBUSHWC (1 << 2) |
| VBus hardware control. | |
| #define | AT90USB_USBOTG_SRPSEL (1 << 3) |
| SRP selection. | |
| #define | AT90USB_USBOTG_SRPREQ (1 << 4) |
| SRP request. | |
| #define | AT90USB_USBOTG_HNPREQ (1 << 5) |
| HNP request. | |
AT90USB USB OTG timer control register | |
| #define | AT90USB_OTGTCON_VALUE (1 << 0) |
| Value of the timer. | |
| #define | AT90USB_OTGTCON_PAGE (1 << 1) |
| Timer page access. | |
AT90USB USB OTG interrupt enable register | |
| #define | AT90USB_OTGIEN_SRPE (1 << 0) |
| SRP interrupt enable. | |
| #define | AT90USB_OTGIEN_VBERRE (1 << 1) |
| VBus error interrupt enable. | |
| #define | AT90USB_OTGIEN_BCERRE (1 << 2) |
| B-Connection error interrupt enable. | |
| #define | AT90USB_OTGIEN_ROLEEXE (1 << 3) |
| Role exchange interrupt enable. | |
| #define | AT90USB_OTGIEN_HNPERRE (1 << 4) |
| HNP error interrupt enable. | |
| #define | AT90USB_OTGIEN_STOE (1 << 5) |
| Suspend time out error interrupt enable. | |
AT90USB USB OTG interrupt register | |
| #define | AT90USB_OTGINT_SRPI (1 << 0) |
| SRP interrupt flag. | |
| #define | AT90USB_OTGINT_VBERRI (1 << 1) |
| VBus error interrupt flag. | |
| #define | AT90USB_OTGINT_BCERRI (1 << 2) |
| B-Connection error interrupt flag. | |
| #define | AT90USB_OTGINT_ROLEEXI (1 << 3) |
| Role exchange interrupt flag. | |
| #define | AT90USB_OTGINT_HNPERRI (1 << 4) |
| HNP error interrupt flag. | |
| #define | AT90USB_OTGINT_STOI (1 << 5) |
| Suspend time out error interrupt flag. | |
AT90USB USB device control register | |
| #define | AT90USB_UDCON_DETACH (1 << 0) |
| Detatch the device. | |
| #define | AT90USB_UDCON_RMWKUP (1 << 1) |
| Remote wake up. | |
| #define | AT90USB_UDCON_LSM (1 << 2) |
| USB device low-speed mode selection. | |
AT90USB USB device interrupt register | |
| #define | AT90USB_UDINT_SUSPI (1 << 0) |
| Suspend interrupt flag. | |
| #define | AT90USB_UDINT_SOFI (1 << 2) |
| Start of frame interrupt flag. | |
| #define | AT90USB_UDINT_EORSTI (1 << 3) |
| End of reset interrupt flag. | |
| #define | AT90USB_UDINT_WAKEUPI (1 << 4) |
| Wake-up CPU interrupt flag. | |
| #define | AT90USB_UDINT_EORSMI (1 << 5) |
| End of resume interrupt flag. | |
| #define | AT90USB_UDINT_UPRSMI (1 << 6) |
| Upstream resume interrupt flag. | |
AT90USB USB device interrupt enable register | |
| #define | AT90USB_UDIEN_SUSPE (1 << 0) |
| Suspend interrupt enable. | |
| #define | AT90USB_UDIEN_SOFE (1 << 2) |
| Start of frame interrupt enable. | |
| #define | AT90USB_UDIEN_EORSTE (1 << 3) |
| End of reset interrupt enable. | |
| #define | AT90USB_UDIEN_WAKEUPE (1 << 4) |
| Wake-up CPU interrupt enable. | |
| #define | AT90USB_UDIEN_EORSME (1 << 5) |
| End of resume interrupt enable. | |
| #define | AT90USB_UDIEN_UPRSME (1 << 6) |
| Upstream resume interrupt enable. | |
AT90USB USB address register | |
| #define | AT90USB_UDADDR_UADD (1 << 0) |
| USB address bit field. | |
| #define | AT90USB_UDADDR_UADD_MASK ((1 << 8) - 1) |
| USB address bit mask. | |
| #define | AT90USB_UDADDR_ADDEN (1 << 7) |
| Address enable. | |
AT90USB USB frame number upper register | |
| #define | AT90USB_UDFNUMH_FNUM (1 << 0) |
| Frame number upper value. | |
AT90USB USB frame number lower register | |
| #define | AT90USB_UDFNUML_FNUM (1 << 0) |
| Frame number lower value. | |
AT90USB USB frame number register | |
| #define | AT90USB_UDMFN_FNCERR (1 << 4) |
| Frame number CRC error flag. | |
AT90USB USB endpoint number register | |
| #define | AT90USB_UENUM_EPNUM(x) ((x) << 0) |
| Endpoint number. | |
AT90USB USB endpoint FIFO reset register | |
| #define | AT90USB_UERST_EPRST(x) (1 << (x)) |
| Endpoint x reset. | |
AT90USB USB endpoint X control register | |
| #define | AT90USB_UECONX_EPEN (1 << 0) |
| Endpoint enable. | |
| #define | AT90USB_UECONX_RSTDT (1 << 3) |
| Reset data toggle. | |
| #define | AT90USB_UECONX_STALLRQC (1 << 4) |
| STALL request disable. | |
| #define | AT90USB_UECONX_STALLRQ (1 << 5) |
| STALL request enable. | |
AT90USB USB endpoint X config 0 register | |
| #define | AT90USB_UECFG0X_EPDIR (1 << 0) |
| Endpoint direction. | |
| #define | AT90USB_UECFG0X_EPDIR_IN (1 << 0) |
| IN endpoint. | |
| #define | AT90USB_UECFG0X_EPDIR_OUT (0 << 0) |
| OUT endpoint. | |
| #define | AT90USB_UECFG0X_EPTYPE(x) ((x) << 6) |
| Endpoint type. | |
| #define | AT90USB_UECFG0X_EPTYPE_CONTROL (0 << 6) |
| Control endpoint. | |
| #define | AT90USB_UECFG0X_EPTYPE_ISO (1 << 6) |
| Isochronous endpoint. | |
| #define | AT90USB_UECFG0X_EPTYPE_BULK (2 << 6) |
| Bulk endpoint. | |
| #define | AT90USB_UECFG0X_EPTYPE_INT (3 << 6) |
| Interrupt endpoint. | |
AT90USB USB endpoint X config 1 register | |
| #define | AT90USB_UECFG1X_ALLOC (1 << 1) |
| Endpoint allocate. | |
| #define | AT90USB_UECFG1X_EPBK(x) ((x) << 2) |
| Endpoint bank. | |
| #define | AT90USB_UECFG1X_GET_EPBK(x) ((x & 3) >> 2) |
| # banks | |
| #define | AT90USB_UECFG1X_EPSIZE(x) ((x) << 4) |
| Endpoint size. | |
| #define | AT90USB_UECFG1X_EPSIZE_8 (0 << 4) |
| 8 byte endpoint size | |
| #define | AT90USB_UECFG1X_EPSIZE_16 (1 << 4) |
| 16 byte endpoint size | |
| #define | AT90USB_UECFG1X_EPSIZE_32 (2 << 4) |
| 32 byte endpoint size | |
| #define | AT90USB_UECFG1X_EPSIZE_64 (3 << 4) |
| 64 byte endpoint size | |
| #define | AT90USB_UECFG1X_EPSIZE_128 (4 << 4) |
| 128 byte endpoint size | |
| #define | AT90USB_UECFG1X_EPSIZE_256 (5 << 4) |
| 256 byte endpoint size | |
AT90USB USB endpoint X status 0 register | |
| #define | AT90USB_UESTA0X_NBUSYBK (1 << 0) |
| Busy bank flag. | |
| #define | AT90USB_UESTA0X_GET_NBUSYBK(x) ((x) & 3) |
| # busy banks | |
| #define | AT90USB_UESTA0X_DTSEQ (1 << 2) |
| Data toggle sequencing flag. | |
| #define | AT90USB_UESTA0X_UDERFI (1 << 5) |
| Underflow error interrupt. | |
| #define | AT90USB_UESTA0X_OVERFI (1 << 6) |
| Overflow error interrupt. | |
| #define | AT90USB_UESTA0X_CFGOK (1 << 7) |
| Configuration status. | |
AT90USB USB endpoint X status 1 register | |
| #define | AT90USB_UESTA1X_CURRBK (1 << 0) |
| Current bank flag. | |
| #define | AT90USB_UESTA1X_CTRLDIR (1 << 2) |
| Control direction flag. | |
AT90USB USB endpoint X interrupt register | |
| #define | AT90USB_UEINTX_TXINI (1 << 0) |
| Transmitter ready interrupt flag. | |
| #define | AT90USB_UEINTX_STALLEDI (1 << 1) |
| STALL interrupt flag. | |
| #define | AT90USB_UEINTX_RXOUTI (1 << 2) |
| Received OUT data interrupt flag. | |
| #define | AT90USB_UEINTX_KILLBK (1 << 2) |
| Kill last written bank. | |
| #define | AT90USB_UEINTX_RXSTPI (1 << 3) |
| Received SETUP interrupt flag. | |
| #define | AT90USB_UEINTX_NAKOUTI (1 << 4) |
| NAK OUT received interrupt flag. | |
| #define | AT90USB_UEINTX_RWAL (1 << 5) |
| Read/write allowed flag. | |
| #define | AT90USB_UEINTX_NAKINI (1 << 6) |
| NAK IN received interrupt flag. | |
| #define | AT90USB_UEINTX_FIFOCON (1 << 7) |
| FIFO control. | |
AT90USB USB endpoint X interrupt enable register | |
| #define | AT90USB_UEIENX_TXINE (1 << 0) |
| Transmitter ready interrupt enable. | |
| #define | AT90USB_UEIENX_STALLEDE (1 << 1) |
| STALL interrupt enable. | |
| #define | AT90USB_UEIENX_RXOUTE (1 << 2) |
| Received OUT data interrupt enable. | |
| #define | AT90USB_UEIENX_RXSTPE (1 << 3) |
| Received SETUP interrupt enable. | |
| #define | AT90USB_UEIENX_NAKOUTE (1 << 4) |
| NAK OUT received interrupt enable. | |
| #define | AT90USB_UEIENX_NAKINE (1 << 6) |
| NAK IN received interrupt enable. | |
| #define | AT90USB_UEIENX_FLERRE (1 << 7) |
| Flow error interrupt enable. | |
AT90USB USB endpoint X data register | |
| #define | AT90USB_UEDATX_DAT (1 << 0) |
| Data. | |
AT90USB USB endpoint X byte count high register | |
| #define | AT90USB_UEBCHX_BYCT (1 << 0) |
| Byte count MSB. | |
AT90USB USB endpoint X byte count low register | |
| #define | AT90USB_UEBCLX_BYCT (1 << 0) |
| Byte count LSB. | |
AT90USB USB endpoint interrupts register | |
| #define | AT90USB_UEINT_EP(x) (1 << (x)) |
| Endpoint interrupts. | |
AT90USB USB host control register | |
| #define | AT90USB_UHCON_SOFEN (1 << 0) |
| Start of frame generation enable. | |
| #define | AT90USB_UHCON_RESET (1 << 1) |
| Send USB reset. | |
| #define | AT90USB_UHCON_RESUME (1 << 2) |
| Send USB resume. | |
AT90USB USB host interrupt register | |
| #define | AT90USB_UHINT_DCONNI (1 << 0) |
| Device connection interrupt. | |
| #define | AT90USB_UHINT_DDISCI (1 << 1) |
| Device disconnection interrupt. | |
| #define | AT90USB_UHINT_RSTI (1 << 2) |
| USB reset sent interrupt. | |
| #define | AT90USB_UHINT_RSMEDI (1 << 3) |
| Downstream resume sent interrupt. | |
| #define | AT90USB_UHINT_RXRSMI (1 << 4) |
| Upstream resume received interrupt. | |
| #define | AT90USB_UHINT_HSOFI (1 << 5) |
| Host start of frame interrupt. | |
| #define | AT90USB_UHINT_HWUPI (1 << 6) |
| Host wake-up interrupt. | |
AT90USB USB host interrupt enable register | |
| #define | AT90USB_UHIEN_DCONNE (1 << 0) |
| Device connection interrupt enable. | |
| #define | AT90USB_UHIEN_DDISCE (1 << 1) |
| Device disconnection interrupt enable. | |
| #define | AT90USB_UHIEN_RSTE (1 << 2) |
| USB reset sent interrupt enable. | |
| #define | AT90USB_UHIEN_RSMEDE (1 << 3) |
| Downstream resume sent interrupt enable. | |
| #define | AT90USB_UHIEN_RXRSME (1 << 4) |
| Upstream resume received interrupt enable. | |
| #define | AT90USB_UHIEN_HSOFE (1 << 5) |
| Host start of frame interrupt enable. | |
| #define | AT90USB_UHIEN_HWUPE (1 << 6) |
| Host wake-up interrupt enable. | |
AT90USB USB host address register | |
| #define | AT90USB_UHADDR_HADDR (1 << 0) |
| USB host address. | |
AT90USB USB host frame number high register | |
| #define | AT90USB_UHFNUMH_FNUM (1 << 0) |
| MSB frame number. | |
AT90USB USB host frame number low register | |
| #define | AT90USB_UHFNUML_FNUM (1 << 0) |
| LSB frame number. | |
AT90USB USB host frame length register | |
| #define | AT90USB_UHFLEN_FLEN (1 << 0) |
| Frame length. | |
AT90USB USB pipe number register | |
| #define | AT90USB_UPNUM_PNUM(x) ((x) << 0) |
| Pipe number. | |
AT90USB USB pipe reset register | |
| #define | AT90USB_UPRST_PRST(x) (1 << (x)) |
| Reset pipe at bit posistion N. | |
AT90USB USB pipe control register | |
| #define | AT90USB_UPCONX_PEN (1 << 0) |
| Pipe enable. | |
| #define | AT90USB_UPCONX_RSTDT (1 << 3) |
| Reset data toggle. | |
| #define | AT90USB_UPCONX_INMODE (1 << 5) |
| IN request mode. | |
| #define | AT90USB_UPCONX_PFREEZE (1 << 6) |
| Pipe freeze. | |
AT90USB USB pipe config 0 register | |
| #define | AT90USB_UPCFG0X_PEPNUM(x) ((x) << 0) |
| Pipe endpoint number. | |
| #define | AT90USB_UPCFG0X_PTOKEN(x) ((x) << 4) |
| Pipe token. | |
| #define | AT90USB_UPCFG0X_PTOKEN_SETUP (0 << 4) |
| Setup pipe token. | |
| #define | AT90USB_UPCFG0X_PTOKEN_IN (1 << 4) |
| In pipe token. | |
| #define | AT90USB_UPCFG0X_PTOKEN_OUT (2 << 4) |
| Out pipe token. | |
| #define | AT90USB_UPCFG0X_PTYPE(x) ((x) << 6) |
| Pipe type. | |
| #define | AT90USB_UPCFG0X_PTYPE_CONTROL (0 << 6) |
| Control pipe. | |
| #define | AT90USB_UPCFG0X_PTYPE_ISO (1 << 6) |
| Isochronous pipe. | |
| #define | AT90USB_UPCFG0X_PTYPE_BULK (2 << 6) |
| Bulk pipe. | |
| #define | AT90USB_UPCFG0X_PTYPE_INT (3 << 6) |
| Interrupt pipe. | |
AT90USB USB pipe config 1 register | |
| #define | AT90USB_UPCFG1X_ALLOC (1 << 1) |
| Configure pipe memory. | |
| #define | AT90USB_UPCFG1X_PBK(x) ((x) << 2) |
| Pipe bank. | |
| #define | AT90USB_UPCFG1X_PSIZE ((x) << 4) |
| Pipe size. | |
| #define | AT90USB_UPCFG1X_PSIZE_8 (0 << 4) |
| 8 byte pipe size | |
| #define | AT90USB_UPCFG1X_PSIZE_16 (1 << 4) |
| 16 byte pipe size | |
| #define | AT90USB_UPCFG1X_PSIZE_32 (2 << 4) |
| 32 byte pipe size | |
| #define | AT90USB_UPCFG1X_PSIZE_64 (3 << 4) |
| 64 byte pipe size | |
| #define | AT90USB_UPCFG1X_PSIZE_128 (4 << 4) |
| 128 byte pipe size | |
| #define | AT90USB_UPCFG1X_PSIZE_256 (5 << 4) |
| 256 byte pipe size | |
AT90USB USB pipe config 2 register | |
| #define | AT90USB_UPCFG2X_INTFRQ(x) ((x) << 0) |
| Interrupt pipe request frequency. | |
AT90USB USB pipe status register | |
| #define | AT90USB_UPSTAX_NBUSYBK (1 << 0) |
| Busy bank flag. | |
| #define | AT90USB_UPSTAX_GET_NBUSYBK(x) ((x) & 3) |
| # busy banks | |
| #define | AT90USB_UPSTAX_DTSEQ (1 << 2) |
| Toggle sequencing flag. | |
| #define | AT90USB_UPSTAX_UNDERFI (1 << 5) |
| Underflow flag. | |
| #define | AT90USB_UPSTAX_OVERFI (1 << 6) |
| Overflow flag. | |
| #define | AT90USB_UPSTAX_CFGOK (1 << 7) |
| Configure pipe memory ok. | |
AT90USB USB pipe IN reuqest number before freeze register | |
| #define | AT90USB_UPINRQX_INRQ(x) ((x) << 0) |
| IN request number before freeze. | |
AT90USB USB pipe error register | |
| #define | AT90USB_UPERRX_DATATGL (1 << 0) |
| Bad data toggle error. | |
| #define | AT90USB_UPERRX_DATAPID (1 << 1) |
| Data PID error. | |
| #define | AT90USB_UPERRX_PID (1 << 3) |
| PID error. | |
| #define | AT90USB_UPERRX_TIMEOUT (1 << 4) |
| Time out error. | |
| #define | AT90USB_UPERRX_CRC16 (1 << 5) |
| CRC16 error. | |
| #define | AT90USB_UPERRX_COUNTER (1 << 6) |
| Error counter. | |
| #define | AT90USB_UPERRX_GET_COUNTER(x) (((x) & 0xc0) >> 6) |
| # errors | |
AT90USB USB pipe interrupt register | |
| #define | AT90USB_UPINTX_RXINI (1 << 0) |
| IN data received. | |
| #define | AT90USB_UPINTX_RXSTALLI (1 << 1) |
| STALL received / ISO CRC error. | |
| #define | AT90USB_UPINTX_TXOUTI (1 << 2) |
| OUT bank ready. | |
| #define | AT90USB_UPINTX_TXSTPI (1 << 3) |
| SETUP bank ready. | |
| #define | AT90USB_UPINTX_PERRI (1 << 4) |
| Pipe error. | |
| #define | AT90USB_UPINTX_RWAL (1 << 5) |
| Read/write allowed. | |
| #define | AT90USB_UPINTX_NAKEDI (1 << 6) |
| NAK handshake received. | |
| #define | AT90USB_UPINTX_FIFOCON (1 << 7) |
| FIFO control. | |
AT90USB USB pipe interrupt enable register | |
| #define | AT90USB_UPINTX_RXINE (1 << 0) |
| IN data received enable. | |
| #define | AT90USB_UPINTX_RXSTALLE (1 << 1) |
| STALL received enable. | |
| #define | AT90USB_UPINTX_TXOUTE (1 << 2) |
| OUT bank ready enable. | |
| #define | AT90USB_UPINTX_TXSTPE (1 << 3) |
| SETUP bank ready enable. | |
| #define | AT90USB_UPINTX_PERRE (1 << 4) |
| Pipe error enable. | |
| #define | AT90USB_UPINTX_NAKEDE (1 << 6) |
| NAK handshake received enable. | |
| #define | AT90USB_UPINTX_FLERRE (1 << 7) |
| Flow error enable. | |
AT90USB USB pipe data bits register | |
| #define | AT90USB_UPDATX_PDAT (1 << 0) |
| Pipe data bits. | |
AT90USB USB pipe byte count high register | |
| #define | AT90USB_UPBCHX_PBYCT (1 << 0) |
| Byte count MSB bits. | |
AT90USB USB pipe byte count low register | |
| #define | AT90USB_UPBCLX_PBYCT (1 << 0) |
| Byte count LSB bits. | |
AT90USB USB pipe interrupts register | |
| #define | AT90USB_UPINT_PINT(x) (1 << (x)) |
| Pipe interrupts. |
AT90USB USB register definitions.
Copyright (C) 2009 Atmel Corporation. All rights reserved.
Definition in file at90usb_regs.h.
| #define AT90USB_OTGIEN_BCERRE (1 << 2) |
B-Connection error interrupt enable.
Definition at line 96 of file at90usb_regs.h.
| #define AT90USB_OTGIEN_HNPERRE (1 << 4) |
HNP error interrupt enable.
Definition at line 98 of file at90usb_regs.h.
| #define AT90USB_OTGIEN_ROLEEXE (1 << 3) |
Role exchange interrupt enable.
Definition at line 97 of file at90usb_regs.h.
| #define AT90USB_OTGIEN_SRPE (1 << 0) |
SRP interrupt enable.
Definition at line 94 of file at90usb_regs.h.
| #define AT90USB_OTGIEN_STOE (1 << 5) |
Suspend time out error interrupt enable.
Definition at line 99 of file at90usb_regs.h.
| #define AT90USB_OTGIEN_VBERRE (1 << 1) |
VBus error interrupt enable.
Definition at line 95 of file at90usb_regs.h.
| #define AT90USB_OTGINT_BCERRI (1 << 2) |
B-Connection error interrupt flag.
Definition at line 106 of file at90usb_regs.h.
| #define AT90USB_OTGINT_HNPERRI (1 << 4) |
HNP error interrupt flag.
Definition at line 108 of file at90usb_regs.h.
| #define AT90USB_OTGINT_ROLEEXI (1 << 3) |
Role exchange interrupt flag.
Definition at line 107 of file at90usb_regs.h.
| #define AT90USB_OTGINT_SRPI (1 << 0) |
SRP interrupt flag.
Definition at line 104 of file at90usb_regs.h.
| #define AT90USB_OTGINT_STOI (1 << 5) |
Suspend time out error interrupt flag.
Definition at line 109 of file at90usb_regs.h.
| #define AT90USB_OTGINT_VBERRI (1 << 1) |
VBus error interrupt flag.
Definition at line 105 of file at90usb_regs.h.
| #define AT90USB_OTGTCON_PAGE (1 << 1) |
Timer page access.
Definition at line 89 of file at90usb_regs.h.
| #define AT90USB_OTGTCON_VALUE (1 << 0) |
Value of the timer.
Definition at line 88 of file at90usb_regs.h.
| #define AT90USB_UDADDR_ADDEN (1 << 7) |
Address enable.
Definition at line 143 of file at90usb_regs.h.
Referenced by at90usb_udc_ep0_worker().
| #define AT90USB_UDADDR_UADD (1 << 0) |
USB address bit field.
Definition at line 141 of file at90usb_regs.h.
| #define AT90USB_UDADDR_UADD_MASK ((1 << 8) - 1) |
USB address bit mask.
Definition at line 142 of file at90usb_regs.h.
Referenced by at90usb_udc_ep0_worker().
| #define AT90USB_UDCON_DETACH (1 << 0) |
Detatch the device.
Definition at line 114 of file at90usb_regs.h.
Referenced by at90usb_udc_detach(), and at90usb_udc_maybe_attach().
| #define AT90USB_UDCON_LSM (1 << 2) |
USB device low-speed mode selection.
Definition at line 116 of file at90usb_regs.h.
Referenced by at90usb_udc_init().
| #define AT90USB_UDCON_RMWKUP (1 << 1) |
Remote wake up.
Definition at line 115 of file at90usb_regs.h.
| #define AT90USB_UDFNUMH_FNUM (1 << 0) |
Frame number upper value.
Definition at line 148 of file at90usb_regs.h.
| #define AT90USB_UDFNUML_FNUM (1 << 0) |
Frame number lower value.
Definition at line 153 of file at90usb_regs.h.
| #define AT90USB_UDIEN_EORSME (1 << 5) |
End of resume interrupt enable.
Definition at line 135 of file at90usb_regs.h.
| #define AT90USB_UDIEN_EORSTE (1 << 3) |
End of reset interrupt enable.
Definition at line 133 of file at90usb_regs.h.
Referenced by at90usb_udc_device_worker(), and at90usb_udc_maybe_attach().
| #define AT90USB_UDIEN_SOFE (1 << 2) |
Start of frame interrupt enable.
Definition at line 132 of file at90usb_regs.h.
| #define AT90USB_UDIEN_SUSPE (1 << 0) |
Suspend interrupt enable.
Definition at line 131 of file at90usb_regs.h.
| #define AT90USB_UDIEN_UPRSME (1 << 6) |
Upstream resume interrupt enable.
Definition at line 136 of file at90usb_regs.h.
| #define AT90USB_UDIEN_WAKEUPE (1 << 4) |
Wake-up CPU interrupt enable.
Definition at line 134 of file at90usb_regs.h.
| #define AT90USB_UDINT_EORSMI (1 << 5) |
End of resume interrupt flag.
Definition at line 125 of file at90usb_regs.h.
| #define AT90USB_UDINT_EORSTI (1 << 3) |
End of reset interrupt flag.
Definition at line 123 of file at90usb_regs.h.
Referenced by at90usb_udc_device_worker().
| #define AT90USB_UDINT_SOFI (1 << 2) |
Start of frame interrupt flag.
Definition at line 122 of file at90usb_regs.h.
| #define AT90USB_UDINT_SUSPI (1 << 0) |
Suspend interrupt flag.
Definition at line 121 of file at90usb_regs.h.
| #define AT90USB_UDINT_UPRSMI (1 << 6) |
Upstream resume interrupt flag.
Definition at line 126 of file at90usb_regs.h.
| #define AT90USB_UDINT_WAKEUPI (1 << 4) |
Wake-up CPU interrupt flag.
Definition at line 124 of file at90usb_regs.h.
| #define AT90USB_UDMFN_FNCERR (1 << 4) |
Frame number CRC error flag.
Definition at line 158 of file at90usb_regs.h.
| #define AT90USB_UEBCHX_BYCT (1 << 0) |
Byte count MSB.
Definition at line 256 of file at90usb_regs.h.
| #define AT90USB_UEBCLX_BYCT (1 << 0) |
Byte count LSB.
Definition at line 261 of file at90usb_regs.h.
| #define AT90USB_UECFG0X_EPDIR (1 << 0) |
Endpoint direction.
Definition at line 185 of file at90usb_regs.h.
| #define AT90USB_UECFG0X_EPDIR_IN (1 << 0) |
IN endpoint.
Definition at line 186 of file at90usb_regs.h.
Referenced by at90usb_udc_kill_all_banks().
| #define AT90USB_UECFG0X_EPDIR_OUT (0 << 0) |
OUT endpoint.
Definition at line 187 of file at90usb_regs.h.
| #define AT90USB_UECFG0X_EPTYPE | ( | x | ) | ((x) << 6) |
Endpoint type.
Definition at line 188 of file at90usb_regs.h.
Referenced by at90usb_udc_configure_ep().
| #define AT90USB_UECFG0X_EPTYPE_BULK (2 << 6) |
Bulk endpoint.
Definition at line 191 of file at90usb_regs.h.
| #define AT90USB_UECFG0X_EPTYPE_CONTROL (0 << 6) |
Control endpoint.
Definition at line 189 of file at90usb_regs.h.
| #define AT90USB_UECFG0X_EPTYPE_INT (3 << 6) |
Interrupt endpoint.
Definition at line 192 of file at90usb_regs.h.
| #define AT90USB_UECFG0X_EPTYPE_ISO (1 << 6) |
Isochronous endpoint.
Definition at line 190 of file at90usb_regs.h.
| #define AT90USB_UECFG1X_ALLOC (1 << 1) |
Endpoint allocate.
Definition at line 197 of file at90usb_regs.h.
Referenced by at90usb_udc_configure_ep().
| #define AT90USB_UECFG1X_EPBK | ( | x | ) | ((x) << 2) |
Endpoint bank.
Definition at line 198 of file at90usb_regs.h.
Referenced by at90usb_udc_configure_ep().
| #define AT90USB_UECFG1X_EPSIZE | ( | x | ) | ((x) << 4) |
Endpoint size.
Definition at line 200 of file at90usb_regs.h.
| #define AT90USB_UECFG1X_EPSIZE_128 (4 << 4) |
128 byte endpoint size
Definition at line 205 of file at90usb_regs.h.
Referenced by at90usb_udc_configure_ep().
| #define AT90USB_UECFG1X_EPSIZE_16 (1 << 4) |
16 byte endpoint size
Definition at line 202 of file at90usb_regs.h.
Referenced by at90usb_udc_configure_ep().
| #define AT90USB_UECFG1X_EPSIZE_256 (5 << 4) |
256 byte endpoint size
Definition at line 206 of file at90usb_regs.h.
Referenced by at90usb_udc_configure_ep().
| #define AT90USB_UECFG1X_EPSIZE_32 (2 << 4) |
32 byte endpoint size
Definition at line 203 of file at90usb_regs.h.
Referenced by at90usb_udc_configure_ep().
| #define AT90USB_UECFG1X_EPSIZE_64 (3 << 4) |
64 byte endpoint size
Definition at line 204 of file at90usb_regs.h.
Referenced by at90usb_udc_configure_ep().
| #define AT90USB_UECFG1X_EPSIZE_8 (0 << 4) |
8 byte endpoint size
Definition at line 201 of file at90usb_regs.h.
Referenced by at90usb_udc_configure_ep().
| #define AT90USB_UECFG1X_GET_EPBK | ( | x | ) | ((x & 3) >> 2) |
# banks
Definition at line 199 of file at90usb_regs.h.
| #define AT90USB_UECONX_EPEN (1 << 0) |
Endpoint enable.
Definition at line 177 of file at90usb_regs.h.
Referenced by at90usb_udc_configure_ep().
| #define AT90USB_UECONX_RSTDT (1 << 3) |
Reset data toggle.
Definition at line 178 of file at90usb_regs.h.
| #define AT90USB_UECONX_STALLRQ (1 << 5) |
STALL request enable.
Definition at line 180 of file at90usb_regs.h.
| #define AT90USB_UECONX_STALLRQC (1 << 4) |
STALL request disable.
Definition at line 179 of file at90usb_regs.h.
| #define AT90USB_UEDATX_DAT (1 << 0) |
Data.
Definition at line 251 of file at90usb_regs.h.
| #define AT90USB_UEIENX_FLERRE (1 << 7) |
Flow error interrupt enable.
Definition at line 246 of file at90usb_regs.h.
| #define AT90USB_UEIENX_NAKINE (1 << 6) |
NAK IN received interrupt enable.
Definition at line 245 of file at90usb_regs.h.
| #define AT90USB_UEIENX_NAKOUTE (1 << 4) |
NAK OUT received interrupt enable.
Definition at line 244 of file at90usb_regs.h.
| #define AT90USB_UEIENX_RXOUTE (1 << 2) |
Received OUT data interrupt enable.
Definition at line 242 of file at90usb_regs.h.
Referenced by at90usb_udc_ep0_worker(), and at90usb_udc_submit_out_queue().
| #define AT90USB_UEIENX_RXSTPE (1 << 3) |
Received SETUP interrupt enable.
Definition at line 243 of file at90usb_regs.h.
Referenced by at90usb_udc_device_worker().
| #define AT90USB_UEIENX_STALLEDE (1 << 1) |
STALL interrupt enable.
Definition at line 241 of file at90usb_regs.h.
| #define AT90USB_UEIENX_TXINE (1 << 0) |
Transmitter ready interrupt enable.
Definition at line 240 of file at90usb_regs.h.
Referenced by at90usb_udc_ep0_worker().
| #define AT90USB_UEINT_EP | ( | x | ) | (1 << (x)) |
Endpoint interrupts.
Definition at line 266 of file at90usb_regs.h.
Referenced by at90usb_ep_interrupt().
| #define AT90USB_UEINTX_FIFOCON (1 << 7) |
FIFO control.
Definition at line 235 of file at90usb_regs.h.
Referenced by at90usb_udc_kill_first_out_bank(), at90usb_udc_submit_in_queue(), and at90usb_udc_submit_out_queue().
| #define AT90USB_UEINTX_KILLBK (1 << 2) |
Kill last written bank.
Definition at line 230 of file at90usb_regs.h.
Referenced by at90usb_udc_kill_last_in_bank().
| #define AT90USB_UEINTX_NAKINI (1 << 6) |
NAK IN received interrupt flag.
Definition at line 234 of file at90usb_regs.h.
| #define AT90USB_UEINTX_NAKOUTI (1 << 4) |
NAK OUT received interrupt flag.
Definition at line 232 of file at90usb_regs.h.
| #define AT90USB_UEINTX_RWAL (1 << 5) |
Read/write allowed flag.
Definition at line 233 of file at90usb_regs.h.
| #define AT90USB_UEINTX_RXOUTI (1 << 2) |
Received OUT data interrupt flag.
Definition at line 229 of file at90usb_regs.h.
Referenced by at90usb_udc_ep0_worker(), at90usb_udc_kill_first_out_bank(), and at90usb_udc_submit_out_queue().
| #define AT90USB_UEINTX_RXSTPI (1 << 3) |
Received SETUP interrupt flag.
Definition at line 231 of file at90usb_regs.h.
Referenced by at90usb_udc_ep0_worker().
| #define AT90USB_UEINTX_STALLEDI (1 << 1) |
STALL interrupt flag.
Definition at line 228 of file at90usb_regs.h.
| #define AT90USB_UEINTX_TXINI (1 << 0) |
Transmitter ready interrupt flag.
Definition at line 227 of file at90usb_regs.h.
Referenced by at90usb_udc_ep0_worker(), and at90usb_udc_submit_in_queue().
| #define AT90USB_UENUM_EPNUM | ( | x | ) | ((x) << 0) |
Endpoint number.
Definition at line 167 of file at90usb_regs.h.
| #define AT90USB_UERST_EPRST | ( | x | ) | (1 << (x)) |
Endpoint x reset.
Definition at line 172 of file at90usb_regs.h.
Referenced by at90usb_udc_configure_ep().
| #define AT90USB_UESTA0X_CFGOK (1 << 7) |
Configuration status.
Definition at line 216 of file at90usb_regs.h.
Referenced by at90usb_udc_configure_ep().
| #define AT90USB_UESTA0X_DTSEQ (1 << 2) |
Data toggle sequencing flag.
Definition at line 213 of file at90usb_regs.h.
| #define AT90USB_UESTA0X_GET_NBUSYBK | ( | x | ) | ((x) & 3) |
# busy banks
Definition at line 212 of file at90usb_regs.h.
Referenced by at90usb_udc_kill_all_banks().
| #define AT90USB_UESTA0X_NBUSYBK (1 << 0) |
Busy bank flag.
Definition at line 211 of file at90usb_regs.h.
| #define AT90USB_UESTA0X_OVERFI (1 << 6) |
Overflow error interrupt.
Definition at line 215 of file at90usb_regs.h.
| #define AT90USB_UESTA0X_UDERFI (1 << 5) |
Underflow error interrupt.
Definition at line 214 of file at90usb_regs.h.
| #define AT90USB_UESTA1X_CTRLDIR (1 << 2) |
Control direction flag.
Definition at line 222 of file at90usb_regs.h.
| #define AT90USB_UESTA1X_CURRBK (1 << 0) |
Current bank flag.
Definition at line 221 of file at90usb_regs.h.
| #define AT90USB_UHADDR_HADDR (1 << 0) |
USB host address.
Definition at line 304 of file at90usb_regs.h.
| #define AT90USB_UHCON_RESET (1 << 1) |
Send USB reset.
Definition at line 276 of file at90usb_regs.h.
| #define AT90USB_UHCON_RESUME (1 << 2) |
Send USB resume.
Definition at line 277 of file at90usb_regs.h.
| #define AT90USB_UHCON_SOFEN (1 << 0) |
Start of frame generation enable.
Definition at line 275 of file at90usb_regs.h.
| #define AT90USB_UHFLEN_FLEN (1 << 0) |
Frame length.
Definition at line 319 of file at90usb_regs.h.
| #define AT90USB_UHFNUMH_FNUM (1 << 0) |
MSB frame number.
Definition at line 309 of file at90usb_regs.h.
| #define AT90USB_UHFNUML_FNUM (1 << 0) |
LSB frame number.
Definition at line 314 of file at90usb_regs.h.
| #define AT90USB_UHIEN_DCONNE (1 << 0) |
Device connection interrupt enable.
Definition at line 293 of file at90usb_regs.h.
| #define AT90USB_UHIEN_DDISCE (1 << 1) |
Device disconnection interrupt enable.
Definition at line 294 of file at90usb_regs.h.
| #define AT90USB_UHIEN_HSOFE (1 << 5) |
Host start of frame interrupt enable.
Definition at line 298 of file at90usb_regs.h.
| #define AT90USB_UHIEN_HWUPE (1 << 6) |
Host wake-up interrupt enable.
Definition at line 299 of file at90usb_regs.h.
| #define AT90USB_UHIEN_RSMEDE (1 << 3) |
Downstream resume sent interrupt enable.
Definition at line 296 of file at90usb_regs.h.
| #define AT90USB_UHIEN_RSTE (1 << 2) |
USB reset sent interrupt enable.
Definition at line 295 of file at90usb_regs.h.
| #define AT90USB_UHIEN_RXRSME (1 << 4) |
Upstream resume received interrupt enable.
Definition at line 297 of file at90usb_regs.h.
| #define AT90USB_UHINT_DCONNI (1 << 0) |
Device connection interrupt.
Definition at line 282 of file at90usb_regs.h.
| #define AT90USB_UHINT_DDISCI (1 << 1) |
Device disconnection interrupt.
Definition at line 283 of file at90usb_regs.h.
| #define AT90USB_UHINT_HSOFI (1 << 5) |
Host start of frame interrupt.
Definition at line 287 of file at90usb_regs.h.
| #define AT90USB_UHINT_HWUPI (1 << 6) |
Host wake-up interrupt.
Definition at line 288 of file at90usb_regs.h.
| #define AT90USB_UHINT_RSMEDI (1 << 3) |
Downstream resume sent interrupt.
Definition at line 285 of file at90usb_regs.h.
| #define AT90USB_UHINT_RSTI (1 << 2) |
USB reset sent interrupt.
Definition at line 284 of file at90usb_regs.h.
| #define AT90USB_UHINT_RXRSMI (1 << 4) |
Upstream resume received interrupt.
Definition at line 286 of file at90usb_regs.h.
| #define AT90USB_UHWCON_UIDE (1 << 6) |
| #define AT90USB_UHWCON_UIMOD (1 << 7) |
| #define AT90USB_UHWCON_UVCONE (1 << 4) |
UVCON pin enable.
Definition at line 48 of file at90usb_regs.h.
| #define AT90USB_UHWCON_UVREGE (1 << 0) |
USB pad regulator enable.
Definition at line 47 of file at90usb_regs.h.
Referenced by at90usb_init(), and at90usb_udc_maybe_attach().
| #define AT90USB_UPBCHX_PBYCT (1 << 0) |
Byte count MSB bits.
Definition at line 432 of file at90usb_regs.h.
| #define AT90USB_UPBCLX_PBYCT (1 << 0) |
Byte count LSB bits.
Definition at line 437 of file at90usb_regs.h.
| #define AT90USB_UPCFG0X_PEPNUM | ( | x | ) | ((x) << 0) |
Pipe endpoint number.
Definition at line 346 of file at90usb_regs.h.
| #define AT90USB_UPCFG0X_PTOKEN | ( | x | ) | ((x) << 4) |
Pipe token.
Definition at line 347 of file at90usb_regs.h.
| #define AT90USB_UPCFG0X_PTOKEN_IN (1 << 4) |
In pipe token.
Definition at line 349 of file at90usb_regs.h.
| #define AT90USB_UPCFG0X_PTOKEN_OUT (2 << 4) |
Out pipe token.
Definition at line 350 of file at90usb_regs.h.
| #define AT90USB_UPCFG0X_PTOKEN_SETUP (0 << 4) |
Setup pipe token.
Definition at line 348 of file at90usb_regs.h.
| #define AT90USB_UPCFG0X_PTYPE | ( | x | ) | ((x) << 6) |
Pipe type.
Definition at line 351 of file at90usb_regs.h.
| #define AT90USB_UPCFG0X_PTYPE_BULK (2 << 6) |
Bulk pipe.
Definition at line 354 of file at90usb_regs.h.
| #define AT90USB_UPCFG0X_PTYPE_CONTROL (0 << 6) |
Control pipe.
Definition at line 352 of file at90usb_regs.h.
| #define AT90USB_UPCFG0X_PTYPE_INT (3 << 6) |
Interrupt pipe.
Definition at line 355 of file at90usb_regs.h.
| #define AT90USB_UPCFG0X_PTYPE_ISO (1 << 6) |
Isochronous pipe.
Definition at line 353 of file at90usb_regs.h.
| #define AT90USB_UPCFG1X_ALLOC (1 << 1) |
Configure pipe memory.
Definition at line 360 of file at90usb_regs.h.
| #define AT90USB_UPCFG1X_PBK | ( | x | ) | ((x) << 2) |
Pipe bank.
Definition at line 361 of file at90usb_regs.h.
| #define AT90USB_UPCFG1X_PSIZE ((x) << 4) |
Pipe size.
Definition at line 362 of file at90usb_regs.h.
| #define AT90USB_UPCFG1X_PSIZE_128 (4 << 4) |
128 byte pipe size
Definition at line 367 of file at90usb_regs.h.
| #define AT90USB_UPCFG1X_PSIZE_16 (1 << 4) |
16 byte pipe size
Definition at line 364 of file at90usb_regs.h.
| #define AT90USB_UPCFG1X_PSIZE_256 (5 << 4) |
256 byte pipe size
Definition at line 368 of file at90usb_regs.h.
| #define AT90USB_UPCFG1X_PSIZE_32 (2 << 4) |
32 byte pipe size
Definition at line 365 of file at90usb_regs.h.
| #define AT90USB_UPCFG1X_PSIZE_64 (3 << 4) |
64 byte pipe size
Definition at line 366 of file at90usb_regs.h.
| #define AT90USB_UPCFG1X_PSIZE_8 (0 << 4) |
8 byte pipe size
Definition at line 363 of file at90usb_regs.h.
| #define AT90USB_UPCFG2X_INTFRQ | ( | x | ) | ((x) << 0) |
Interrupt pipe request frequency.
Definition at line 373 of file at90usb_regs.h.
| #define AT90USB_UPCONX_INMODE (1 << 5) |
IN request mode.
Definition at line 340 of file at90usb_regs.h.
| #define AT90USB_UPCONX_PEN (1 << 0) |
Pipe enable.
Definition at line 338 of file at90usb_regs.h.
| #define AT90USB_UPCONX_PFREEZE (1 << 6) |
Pipe freeze.
Definition at line 341 of file at90usb_regs.h.
| #define AT90USB_UPCONX_RSTDT (1 << 3) |
Reset data toggle.
Definition at line 339 of file at90usb_regs.h.
| #define AT90USB_UPDATX_PDAT (1 << 0) |
Pipe data bits.
Definition at line 427 of file at90usb_regs.h.
| #define AT90USB_UPERRX_COUNTER (1 << 6) |
Error counter.
Definition at line 398 of file at90usb_regs.h.
| #define AT90USB_UPERRX_CRC16 (1 << 5) |
CRC16 error.
Definition at line 397 of file at90usb_regs.h.
| #define AT90USB_UPERRX_DATAPID (1 << 1) |
Data PID error.
Definition at line 394 of file at90usb_regs.h.
| #define AT90USB_UPERRX_DATATGL (1 << 0) |
Bad data toggle error.
Definition at line 393 of file at90usb_regs.h.
| #define AT90USB_UPERRX_GET_COUNTER | ( | x | ) | (((x) & 0xc0) >> 6) |
# errors
Definition at line 399 of file at90usb_regs.h.
| #define AT90USB_UPERRX_PID (1 << 3) |
PID error.
Definition at line 395 of file at90usb_regs.h.
| #define AT90USB_UPERRX_TIMEOUT (1 << 4) |
Time out error.
Definition at line 396 of file at90usb_regs.h.
| #define AT90USB_UPINRQX_INRQ | ( | x | ) | ((x) << 0) |
IN request number before freeze.
Definition at line 388 of file at90usb_regs.h.
| #define AT90USB_UPINT_PINT | ( | x | ) | (1 << (x)) |
Pipe interrupts.
Definition at line 442 of file at90usb_regs.h.
| #define AT90USB_UPINTX_FIFOCON (1 << 7) |
FIFO control.
Definition at line 411 of file at90usb_regs.h.
| #define AT90USB_UPINTX_FLERRE (1 << 7) |
Flow error enable.
Definition at line 422 of file at90usb_regs.h.
| #define AT90USB_UPINTX_NAKEDE (1 << 6) |
NAK handshake received enable.
Definition at line 421 of file at90usb_regs.h.
| #define AT90USB_UPINTX_NAKEDI (1 << 6) |
NAK handshake received.
Definition at line 410 of file at90usb_regs.h.
| #define AT90USB_UPINTX_PERRE (1 << 4) |
Pipe error enable.
Definition at line 420 of file at90usb_regs.h.
| #define AT90USB_UPINTX_PERRI (1 << 4) |
Pipe error.
Definition at line 408 of file at90usb_regs.h.
| #define AT90USB_UPINTX_RWAL (1 << 5) |
Read/write allowed.
Definition at line 409 of file at90usb_regs.h.
| #define AT90USB_UPINTX_RXINE (1 << 0) |
IN data received enable.
Definition at line 416 of file at90usb_regs.h.
| #define AT90USB_UPINTX_RXINI (1 << 0) |
IN data received.
Definition at line 404 of file at90usb_regs.h.
| #define AT90USB_UPINTX_RXSTALLE (1 << 1) |
STALL received enable.
Definition at line 417 of file at90usb_regs.h.
| #define AT90USB_UPINTX_RXSTALLI (1 << 1) |
STALL received / ISO CRC error.
Definition at line 405 of file at90usb_regs.h.
| #define AT90USB_UPINTX_TXOUTE (1 << 2) |
OUT bank ready enable.
Definition at line 418 of file at90usb_regs.h.
| #define AT90USB_UPINTX_TXOUTI (1 << 2) |
OUT bank ready.
Definition at line 406 of file at90usb_regs.h.
| #define AT90USB_UPINTX_TXSTPE (1 << 3) |
SETUP bank ready enable.
Definition at line 419 of file at90usb_regs.h.
| #define AT90USB_UPINTX_TXSTPI (1 << 3) |
SETUP bank ready.
Definition at line 407 of file at90usb_regs.h.
| #define AT90USB_UPNUM_PNUM | ( | x | ) | ((x) << 0) |
Pipe number.
Definition at line 328 of file at90usb_regs.h.
| #define AT90USB_UPRST_PRST | ( | x | ) | (1 << (x)) |
Reset pipe at bit posistion N.
Definition at line 333 of file at90usb_regs.h.
| #define AT90USB_UPSTAX_CFGOK (1 << 7) |
Configure pipe memory ok.
Definition at line 383 of file at90usb_regs.h.
| #define AT90USB_UPSTAX_DTSEQ (1 << 2) |
Toggle sequencing flag.
Definition at line 380 of file at90usb_regs.h.
| #define AT90USB_UPSTAX_GET_NBUSYBK | ( | x | ) | ((x) & 3) |
# busy banks
Definition at line 379 of file at90usb_regs.h.
| #define AT90USB_UPSTAX_NBUSYBK (1 << 0) |
Busy bank flag.
Definition at line 378 of file at90usb_regs.h.
| #define AT90USB_UPSTAX_OVERFI (1 << 6) |
Overflow flag.
Definition at line 382 of file at90usb_regs.h.
| #define AT90USB_UPSTAX_UNDERFI (1 << 5) |
Underflow flag.
Definition at line 381 of file at90usb_regs.h.
| #define AT90USB_USBCON_FRZCLK (1 << 5) |
| #define AT90USB_USBCON_HOST (1 << 6) |
HOST enable.
Definition at line 59 of file at90usb_regs.h.
| #define AT90USB_USBCON_IDTE (1 << 1) |
ID transition interrupt enable.
Definition at line 56 of file at90usb_regs.h.
Referenced by at90usb_init().
| #define AT90USB_USBCON_OTGPADE (1 << 4) |
| #define AT90USB_USBCON_USBE (1 << 7) |
| #define AT90USB_USBCON_VBUSTE (1 << 0) |
VBUS transition interrupt enable.
Definition at line 55 of file at90usb_regs.h.
Referenced by at90usb_enter_device_mode().
| #define AT90USB_USBINT_IDTI (1 << 1) |
D transition interrupt flag.
Definition at line 73 of file at90usb_regs.h.
Referenced by at90usb_generic_interrupt(), and at90usb_init().
| #define AT90USB_USBINT_VBUSTI (1 << 0) |
IVBUS transition interrupt flag.
Definition at line 72 of file at90usb_regs.h.
Referenced by at90usb_enter_device_mode(), and at90usb_generic_interrupt().
| #define AT90USB_USBOTG_HNPREQ (1 << 5) |
HNP request.
Definition at line 83 of file at90usb_regs.h.
| #define AT90USB_USBOTG_SRPREQ (1 << 4) |
SRP request.
Definition at line 82 of file at90usb_regs.h.
| #define AT90USB_USBOTG_SRPSEL (1 << 3) |
SRP selection.
Definition at line 81 of file at90usb_regs.h.
| #define AT90USB_USBOTG_VBUSHWC (1 << 2) |
VBus hardware control.
Definition at line 80 of file at90usb_regs.h.
| #define AT90USB_USBOTG_VBUSREQ (1 << 1) |
VBUS request.
Definition at line 79 of file at90usb_regs.h.
| #define AT90USB_USBOTG_VBUSRQC (1 << 0) |
VBUS request clear.
Definition at line 78 of file at90usb_regs.h.
| #define AT90USB_USBSTA_ID (1 << 1) |
| #define AT90USB_USBSTA_SPEED (1 << 3) |
Speed status flag.
Definition at line 67 of file at90usb_regs.h.
| #define AT90USB_USBSTA_VBUS (1 << 0) |