text:
Talk:Embedded Systems

I've been working on the layout to this book for a while now, and have finally moved it on to the engineering bookshelf to begin writing and "filling in" the book. I have also prepared a number of templates to be used in this book:

 * Template:Embedded Systems/Page
 * Template:Embedded Systems/Stub
 * :
 * /Stubs

--Whiteknight T C E 16:58, 1 November 2005 (UTC)

Merge
Apparently there is another embedded systems book out there that i wasnt aware of when i created this book. I've seen the other book, and agree wholeheartedly that the two books should merge in one way or another. The current request is that the other book be merged into this book, and I agree with that because the Embedded Systems book has a shorter name (which is easier for writing links), and already has a much more extensive table of contents that will eventually be filled in. --Whiteknight T C E 15:23, 2 November 2005 (UTC)

I would be happy to link here from the Software Engineers Handbook instead of having a separate chapter there. What do I need to do to have it happen? Christine Frayda 00:36, 13 June 2006 (UTC)

Embedded Systems: Theory, Implementation and Design
Here is the discussion from the previous book, preserved for future reference. We might move all these old discussions to an archive eventually. --Whiteknight T C E 16:24, 11 November 2005 (UTC)

C++
Why C and not C++?

you can get a 32 bit embedded processor for $3-4 nowadays. There's no reason to not use a programming language suitable for complex embedded projects.

C++ for embedded systems could be its own chapter, as there are a few tricks to getting the footprint small.

''That sounds wonderful. Would you mind clueing the rest of us in on the name of this wonderful processor? I'm astonished that Digikey sells the Texas Instruments TMS320 floating-point DSP for $20 in ones. But a 32 bit processor for under $5 ? --DavidCary 11:46, 15 January 2006 (UTC)''

An example of such cheap 32-bit processor is the LPC2103 from Philips. Cost is $4.7 in Qty of one and $2.92 in Qty of 100. Priced April 9, 2006. 24.200.103.110 03:32, 10 April 2006 (UTC) Jean-Samuel

 * Wow, that is great. Thank you so much, Jean-Samuel, for informing me that I *can* get a 32 bit embedded processor, which are much easier to program, for about the same price as a 8 bit processor. --DavidCary 20:57, 1 October 2007 (UTC)

Well, C is more "controllable" than C++ (not only the footprint) but the perfect examples would be in ASM not C.

PS: You can also get an SUV but can you afford the gasoline :)

Networking:Peer-to-Peer (P2P) - Programming:C_-/-_-/- --Panic 05:34, 11 August 2005 (UTC)

Well, Its definitely a good idea to include the "C++ for Embedded Systems" Chapter towards the end. I suggested C because I have been working in C :o) And yes, the examples will mostly be in ASM and C, as appropriate. Later on we can add examples in C++ in the seperate chapter.

I also plan to add a chapter on UML for Real-time Systems Design. Ill prepare notes on it as I myself learn the techniques.

--Siddord 10:58, 11 August 2005 (UTC)

 * When I set up the original outline for this book, I wanted very strongly to keep it language-neutral. However, C and Assembly are simply more popular choices for use in embedded systems. You have to keep in mind that C is a very simple language (much simpler then C++), and this is a benefit to small companies with small microprocessors that need to write their own compiler. Also, a number of companies have produced systems using C derivatives, such as "Dynamic C" for use in the Z-World RabbitCores. C++, because of it's built-in need for dynamic memory allocation, and the complexities of function overloading, operator overloading, and templates is generally not a common choice for use in embedded systems, nor is it considered when a company needs to write it's own, proprietary compiler for a specific microcontroller. Another popular language that is used in embedded systems is BASIC, so if people want to talk about that, i think that would be a good idea. --Whiteknight (talk) (current) 21:44, 27 April 2006 (UTC)

 * In my expierience C++ is used for complex GUIs (e.g. in navigation systems) or for control engineering purposes. All low level drivers (Communication Stack, OS, perpherals) are written in C. I never saw someone writing a flash or eeprom driver in C++. Direct hardware access is generally written in C. --Hudsontng 22:59, 14 August 2007 (UTC)

Discussion
can someone please tell me how to create the link to a new Introduction page????? when i added a page... it refers to an old page of some medical book!!!

--Siddord 07:55, 12 August 2005 (UTC)

Humm, I don't understand the question (try looking on the discussion areas of the C++ book I have posted there some examples...

About the HOC, is it really needed why not just use the page history to get the same info ?

--Panic 03:26, 15 August 2005 (UTC)

I'd like to lend a hand
Hello everyone;

I'm involved in embedded systems too and would like to lend a hand.

I first came across Wikipedia some time ago when I was looking for some mathematics definitions. I was very impressed by the professionalism of what I found.

Maybe its premature to ask, as I will be digging into the documention, but I saw a comment suggesting that its desirable to register as a writer. How might I do that, please?

Jonathan

Logged in, will have to delete my anonymous comment

Hello there Jonathan,

Well the reference to "get registered to become a writer" is about creating a login on Wikibooks, nothing more, just to be easier to talk to you and trace your edits (also, you will get your own "page" and sandbox to test stuff out, etc...)

As for Wikipedia take notice that this is not Wikipedia but Wikibooks almost the same but not quite :), here we create books not encyclopedic articles...

--Panic 04:55, 18 August 2005 (UTC)

Wikibooks:Naming policy
Some one posted a warning on the Talk:Programming in C -/- -/- about the naming policies on Wikibooks:

''Prehaps you should read the Wikibooks:Naming policy. The current name is running under WB:NP#Historical_conventions. So if at all a new name should be somthing like:''

* Cpp Programming * How-To programm in C plus plus * Programming in C -/- -/-

Ohterwise you end up being not a book but only chapter in a very very big Programming book.

This book seems also to be in need of a new name... and the "chapters" seem to be lose (with no book name) --Panic 04:04, 9 September 2005 (UTC)

(embeddable) Databases information chapter/content
I have had to do some researching on (embeddable) Databases, some content on that topic would be a great contribution to the overall book.

example: References to [SQLite] and other solutions, some content could be used from wikipedia. --Panic 01:02, 18 October 2005 (UTC)

Development stages
I suggest that TOC uses stage short. It's a bit confusing now, because there's no red links, but some chapters are blank. --Derbeth talk 11:24, 21 November 2005 (UTC)

 * Yeah, i was going to get around to doing that eventually. maybe the time is now (especially if this book is garnering CoM attention). --Whiteknight T C E 12:39, 21 November 2005 (UTC)

PIC Projects
I have a number of PIC projects planned for the next few months, and once i get them rolling, I'm going to introduce a number of pages in an "Examples" chapter or something. I am going to order a number of 8051 also, and i will post projects involving them. -- 21:39, 1 December 2005 (UTC)

I am looking forward to it. --DavidCary 03:08, 3 December 2005 (UTC)

chapter names
The Naming_policy recommends the "flat" naming convention for new books.

Does anyone have any objections to flattening this book? If not, I'm going to move (Feel free to suggest better names).
 * Embedded Systems/Embedded System Basics/Fixed-Point Arithmetic to Embedded Systems/Fixed-Point Arithmetic
 * Embedded Systems/PIC Microcontroller/PIC Programming to Embedded Systems/PIC Programming
 * Embedded Systems/Assembly Language/Mixed C and Assembly Programming/Inline Assembly to Embedded Systems/Inline Assembly
 * Embedded Systems/Assembly Language/Mixed C and Assembly Programming/Calling Conventions to Embedded Systems/Calling Conventions
 * etc.

Also, as Panic suggests, I'll try to rename any "loose" chapters as I find them, so they begin with "Embedded Systems/". (Although User:Whiteknight keeps beating me to it). Then there are exactly 2 levels of hierarchy, seperated by a single slash: book name, slash, chapter name.

However, feel free to organize the table of contents on the Embedded Systems page with as many levels of heirarchy as anyone wants. --DavidCary 03:08, 3 December 2005 (UTC)

 * I guess i have no problem with flattening it out, although I don't see a huge need to. If you are willing to burn the elbow grease, then by all means. I didnt realize that it was official policy to prefer the flat scheme over the hierarchical scheme (so maybe i should pay more attention to naming policy). -- 17:08, 3 December 2005 (UTC)

 * I started flattening out most of the chapter names. I've merged some stub pages together also. --Whiteknight (talk) (projects) 15:37, 14 June 2006 (UTC)

New to Embededd need help
Hello to all the great people there, I'm very new to this field but as i was intrested in C and C++ i decided to move here. So i need your help.

I have been working on AVR-Atmega16 microcontroller with C. When i read the datasheet(350 pages) of this micro-c,i was confused. There was to much stuff. kindly tell me what i have to choose from that.

As i am in this arena i want u to kindly tell me what exactly happens in a live embedded project. It will very kind of you if you explain me every step.

Thanks, Vivek

 * Well, this book is designed to discuss all the issues of embedded systems, but this talk page is hardly the place to give a complete run-through. If you have an account here let me know your user name, and I can work to get you going in the right direction. -- 14:39, 5 December 2005 (UTC)

references to paper books
moved to Embedded Systems/Resources

FPGA Programming Section
This entire section was poorly laid out, and is in need of repairs. I am planning an outline for a new book called "Programmable Logic Design", that I hope to implement within the next couple weeks (depending on my work schedule), and I think that would be a better place for this material. If anybody wants to work to clean up the FPGA section, feel free, but if it doesn't get fixed, I think we should move all that material into the new book. --Whiteknight (talk) (current) 21:48, 27 April 2006 (UTC)

 * Moved. I've posted a link to the other book. --Whiteknight (talk) (projects) 15:39, 14 June 2006 (UTC)

 * Is that other book Programmable Logic ? --DavidCary (discuss • contribs) 03:26, 17 April 2021 (UTC)

rename from "RTOS" to "embedded OS"
I am surprised that none of the OSes listed in the "Common RTOS" section (Palm OS, Windows CE, MS-DOS or DOS Clones) qualify as a RTOS, at least according to my understanding of the term RTOS.

I think we should we rename that section something more accurate. What would be a good name? "embedded OS"? --DavidCary 09:20, 10 September 2007 (UTC)

 * I agree with you, although I tend to come to the opposite conclusion. Instead of renaming the section, I would prefer deleting it entirely. We could replace it instead with information about true Real-Time OS's, and not just small blurbs about common commercial embedded OSs. Barring that, I might like to create a separate book about RTOS entirely, in which case we could certainly rename the section here as you propose and leave a real discussion about RTOS for a more focused book. --Whiteknight (Page) (Talk) 14:55, 10 September 2007 (UTC)

title: Talk:Embedded Systems


text:
Template:Embedded Systems/Stub

''This page of the Embedded Systems book is a stub. You can help by expanding this section.'' :This template adds page to /Stubs.

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/

title: Template:Embedded Systems/Stub


text:
Embedded Systems/Embedded Systems Introduction

Embedded Technology is now in its prime and the wealth of knowledge available is mindblowing. However, most embedded systems engineers have a common complaint. There are no comprehensive resources available over the internet which deal with the various design and implementation issues of this technology. Intellectual property regulations of many corporations are partly to blame for this and also the tendency to keep technical know-how within a restricted group of researchers.

Before embarking on the rest of this book, it is important first to cover exactly what embedded systems are, and how they are used. This wikibook will attempt to cover a large number of topics, some of which apply only to embedded systems, but some of which will apply to nearly all computers (embedded or otherwise). As such, there is a chance that some of the material from this book will overlap with material from other wikibooks that are focused on topics such as low-level computing, assembly language, computer architecture, etc. But we will first start with the basics, and attempt to answer some questions before the book actually begins.

What is an Embedded Computer?
The first question that needs to be asked, is "What exactly is an embedded computer?" An embedded computer is frequently a computer that is implemented for a particular purpose. In contrast, an average PC computer usually serves a number of purposes: checking email, surfing the internet, listening to music, word processing, etc... However, embedded systems usually only have a single task, or a very small number of related tasks that they are programmed to perform.

Every home has several examples of embedded computers. Any appliance that has a digital clock, for instance, has a small embedded micro-controller that performs no other task than to display the clock. Modern cars have embedded computers onboard that control such things as ignition timing and anti-lock brakes using input from a number of different sensors.

Embedded computers rarely have a generic interface, however. Even if embedded systems have a keypad and an LCD display, they are rarely capable of using many different types of input or output. An example of an embedded system with I/O capability is a security alarm with an LCD status display, and a keypad for entering a password.

In general, an Embedded System: It is a combination of hardware and software that performs a specific task.

 * Is a system built to perform its duty, completely or partially independent of human intervention.
 * Is specially designed to perform a few tasks in the most efficient way.
 * Interacts with physical elements in our environment, e.g. controlling and driving a motor, sensing temperature, etc.

An embedded system can be defined as a control system or computer system designed to perform a specific task. Common examples of embedded systems include MP3 players, navigation systems on aircraft and intruder alarm systems. An embedded system can also be defined as a single purpose computer.

Most embedded systems are time critical applications meaning that the embedded system is working in an environment where timing is very important: the results of an operation are only relevant if they take place in a specific time frame. An autopilot in an aircraft is a time critical embedded system. If the autopilot detects that the plane for some reason is going into a stall then it should take steps to correct this within milliseconds or there would be catastrophic results.

What are Embedded Systems Used For?
Embedded systems are considered when the cost of implementing a product designed in software on a microprocessor and some small amount of hardware, is cheaper, more reliable, or better for some other reason than a discrete hardware design. It is possible for one small and relatively cheap microprocessor to replace dozens or even hundreds of hardware logic gates, timing circuits, input buffers, output drivers, etc. It also happens that one generic embedded system with a standard input and output configuration can be made to perform in a completely different manner simply by changing the software.

The uses of embedded systems are virtually limitless, because every day new products are introduced to the market that utilize embedded computers in novel ways. In recent years, hardware such as microprocessors, microcontrollers, and FPGA chips have become much cheaper. So when implementing a new form of control, it's wiser to just buy the generic chip and write your own custom software for it. Producing a custom-made chip to handle a particular task or set of tasks costs far more time and money. Many embedded computers even come with extensive libraries, so that "writing your own software" becomes a very trivial task indeed.

From an implementation viewpoint, there is a major difference between a computer and an embedded system. Embedded systems are often required to provide Real-Time response. A Real-Time system is defined as a system whose correctness depends on the timeliness of its response. Examples of such systems are flight control systems of an aircraft, sensor systems in nuclear reactors and power plants. For these systems, delay in response is a fatal error. A more relaxed version of Real-Time Systems, is the one where timely response with small delays is acceptable. Example of such a system would be the Scheduling Display System on the railway platforms. In technical terminology, Real-Time Systems can be classified as:

 * Hard Real-Time Systems - systems with severe constraints on the timeliness of the response.
 * Soft Real-Time Systems - systems which tolerate small variations in response times.
 * Hybrid Real-Time Systems - systems which exhibit both hard and soft constraints on its performance.

What are Some Downfalls of Embedded Computers?
Embedded computers may be economical, but they are often prone to some very specific problems. A PC computer may ship with a glitch in the software, and once discovered, a software patch can often be shipped out to fix the problem. An embedded system, however, is frequently programmed once, and the software cannot be patched. Even if it is possible to patch faulty software on an embedded system, the process is frequently far too complicated for the user.

Another problem with embedded computers is that they are often installed in systems for which unreliability is not an option. For instance, the computer controlling the brakes in your car cannot be allowed to fail under any condition. The targeting computer in a missile is not allowed to fail and accidentally target friendly units. As such, many of the programming techniques used when throwing together production software cannot be used in embedded systems. Reliability must be guaranteed before the chip leaves the factory. This means that every embedded system needs to be tested and analyzed extensively.

An embedded system will have very few resources when compared to full blown computing systems like a desktop computer. The memory capacity and processing power in an embedded system is limited. It is more challenging to develop an embedded system when compared to developing an application for a desktop system as we are developing a program for a very constricted environment. Some embedded systems run a scaled down version of operating system called an RTOS (real time operating system).

Why Study Embedded Systems?
Embedded systems are playing important roles in our lives every day, even though they might not necessarily be visible. Some of the embedded systems we use every day control the menu system on television, the timer in a microwave oven, a cellphone, an MP3 player or any other device with some amount of intelligence built-in. In fact, recent poll data shows that embedded computer systems currently outnumber humans in the USA. Embedded systems is a rapidly growing industry where growth opportunities are numerous.

Who is This Book For?
This book is designed to accompany a course of study in computer engineering. However, this book will also be useful to any reader who is interested in computers, because this book can form the starting point for a "bottom up" learning initiative on computers. It is fundamentally easier to study small, limited, simple computers than it is to start studying the big PC behemoths that we use on a daily basis. Many topics covered in this book will be software topics as well, so this book will be the most helpful to people with at least some background in programming (especially C and Assembly languages). Having a prior knowledge of semiconductors and electric circuits will be beneficial, but will not be required.

What Will This Book Cover?
This book will focus primarily on embedded systems, but the reader needs to understand 2 simple facts:

 * 1) This book cannot proceed far without a general discussion of microprocessor architecture
 * 2) Many of the concepts discussed in this book apply equally well, if not better, to Desktop computers than to embedded computers.

In the general interests of completeness, this book will cover a number of topics that have general relevance to all computers in general. Many of the lessons in this book will even be better applied by a desktop computer programmer than by an embedded systems engineer. It might be more fair to say that this book is more about "Low Level Computing" than "Embedded Systems".

This book will, of course, cover many embedded systems topics that are irrelevant when programming desktop computers, such as cross-compilers, Real-Time Operating Systems, EEPROM storage, code compression, bit-banging serial ports, umbilical development, etc.

Where to Go From Here
After reading this book, there are a number of potential fields of study to continue learning.

 * For people interested in operating systems, and hardware-software interfacing, read the Operating System Design wikibook.
 * For people interested in C programming or Assembly Programming, see the Programming:C and X86 Assembly wikibooks, respectively.
 * For people interested in digital control systems, there will eventually be a book on that topic here ( Programmable Logic )
 * For people interested in digital signal processing, there will eventually be a book on that subject.
 * For people interested in a further study of more advanced computer systems, there will eventually be books on computer hardware and microprocessors here. ( Microprocessor Design )
 * For people interested in an even lower-level understanding of electronics, see Digital Circuits.
 * School of Very Small Information Systems is a course that includes using Java running on a FPGA.
 * For people interested in designing motion control systems, that is, computer-controlled machines such as robots, machine tools, cars, buses, airplanes, ships, satellites, telescopes, etc., see Embedded Control Systems Design.

Which Programming Languages Will This Book Use?
We try to make this wikibook language neutral. It is not fair to focus on one language, when all embedded computers can't be programmed in that language.

However, it is nice to have functional example code in some real language. Also, it is useful to point out some features of popular programming languages that are especially important for embedded systems.

 * ANSI C programming language: Many microprocessors and microcontrollers can be programmed in C, and a number of C cross-compilers exist for that purpose. C is perhaps the most frequently used language for new embedded system development. The "volatile" keyword, rarely used in desktop app programming, becomes very important in Embedded Systems/C Programming.
 * Originally developed by the department of defense for real-time operating systems and embedded systems, Ada was designed with multiprocessor support and strong compile-time checks to ensure the quality and integrity of developed systems—Many microcontrollers can be programmed with Ada as the GNAT Ada compiler it is part of the often ported GNU Compiler Collection, though documentation is often not as available as other more popular languages such as C.
 * Assembly language: There are many different microcontroller families, each with their own assembly language with its own unique quirks. This book will cover some basics of assembly language common to most microcontrollers. Unlike desktop app programming, embedded system programs generally must set up an "interrupt vector table".
 * This book will discuss (at least briefly) some techniques for multi-language programming (specifically C and assembly).
 * There are some instances where microcontrollers are better programmed in a different language (BASIC and Forth come to mind)
 * Some controllers are even programmed in their own proprietary languages (PIC Basic, and Dynamic C for instance).
 * Some extremely well-known languages, such as C++ and Java, are rarely used in embedded systems, because C++ and Java compilers are simply unavailable for popular microcontrollers. However, this book may occasionally describe how to implement C++ and Java features in an environment that doesn't natively support them.
 * Python compilers are available for some popular microcontrollers. Pyastra compiles for all Microchip PIC12, PIC14 and PIC16 microcontrollers. PyMite  compiles for "any device in the AVR family that has at least 64 KiB program memory and 4 KiB RAM". PyMite also targets (some) ARM microcontrollers. Notice that these embedded Python compilers typically can only compile a subset of the Python language for these devices.

Further reading:
 * Robotics: Design Basics: Design software
 * Embedded Systems/PIC Programming

嵌入式系统/简介


text:
Embedded Systems/Microprocessor Introduction

Effectively programming an embedded system, and implementing it reliably requires the engineer to know many of the details of the system architecture. Section 1 of the Embedded Systems book will cover some of the basics of microprocessor architecture. This information might not apply to all embedded computers, and much of it may apply to computers in general. This book can only cover some basic concepts, because the actual embedded computers available on the market are changing every day, and it is the engineer's responsibility to find out what capabilities and limitations their particular systems have.

As manufacturers continue to pack more and more transistors onto a single chip, more and more of the stuff that was once "peripheral logic" has been integrated on the same chip as the CPU. A microcontroller includes most or all the electronics needed in an embedded system in a single integrated circuit ("chip").
 * CPU
 * I/O ports
 * RAM - contains temporary data
 * ROM - contains program and constant data—the firmware. Starting in 1993, many microcontrollers use Flash memory instead of true ROM to hold the firmware, but many engineers still refer to the Flash memory that holds the firmware as "ROM" to differentiate it from "RAM".
 * Timers—we discuss these later at Timers.
 * Serial interface—often a USART—we discuss these later at IO
 * EEPROM - contains "permanent" data
 * Analog-to-digital converter
 * Specialized functions

This list is roughly in order of integration. The earliest microcontrollers contained only the CPU and I/O ports; modern microprocessors typically contain the CPU, some I/O ports, and cache RAM; the cost of a microcontroller dropped dramatically once the CPU, I/O, RAM, and ROM could all be squeezed onto the same chip, because such a microcontroller no longer needs "address pins"; etc. The most highly integrated microcontrollers include all these parts on one chip.


text:
Embedded Systems/Embedded System Basics

Embedded systems programming is not like normal PC programming. In many ways, programming for an embedded system is like programming a PC 25 years ago. The hardware for the system is usually chosen to make the device as cheap as possible. Spending an extra dollar a unit in order to make things easier to program can cost millions. Hiring a programmer for an extra month is cheap in comparison. This means the programmer must make do with slow processors and low memory, while at the same time battling a need for efficiency not seen in most PC applications. Below is a list of issues specific to the embedded field.

Tools
Embedded development makes up a small fraction of total programming. There's also a large number of embedded architectures, unlike the PC world where 1 instruction set rules, and the Unix world where there's only 3 or 4 major ones. This means that the tools are more expensive. It also means that they're lower featured, and less developed. On a major embedded project, at some point you will almost always find a compiler bug of some sort.

Debugging tools are another issue. Since you can't always run general programs on your embedded processor, you can't always run a debugger on it. This makes fixing your program difficult. Special hardware such as JTAG ports can overcome this issue in part. However, if you stop on a breakpoint when your system is controlling real world hardware (such as a motor), permanent equipment damage can occur. As a result, people doing embedded programming quickly become masters at using serial IO channels and error message style debugging.

Resources
To save costs, embedded systems frequently have the cheapest processors that can do the job. This means your programs need to be written as efficiently as possible. When dealing with large data sets, issues like memory cache misses that never matter in PC programming can hurt you. Luckily, this won't happen too often- use reasonably efficient algorithms to start, and optimize only when necessary. Of course, normal profilers won't work well, due to the same reason debuggers don't work well. So more intuition and an understanding of your software and hardware architecture is necessary to optimize effectively.

Memory is also an issue. For the same cost savings reasons, embedded systems usually have the least memory they can get away with. That means their algorithms must be memory efficient (unlike in PC programs, you will frequently sacrifice processor time for memory, rather than the reverse). It also means you can't afford to leak memory. Embedded applications generally use deterministic memory techniques and avoid the default "new" and "malloc" functions, so that leaks can be found and eliminated more easily.

Other resources programmers expect may not even exist. For example, most embedded processors do not have hardware FPUs (Floating-Point Processing Unit). These resources either need to be emulated in software, or avoided altogether.

Real Time Issues
Embedded systems frequently control hardware, and must be able to respond to them in real time. Failure to do so could cause inaccuracy in measurements, or even damage hardware such as motors. This is made even more difficult by the lack of resources available. Almost all embedded systems need to be able to prioritize some tasks over others, and to be able to put off/skip low priority tasks such as UI in favor of high priority tasks like hardware control.

Fixed-Point Arithmetic
Many embedded projects enforce a no floating point rule on their programmers.

Fixed-point arithmetic and other alternatives are often better than floating point arithmetic.

We discuss those advantages and go into more detail on fixed-point and floating-point numbers in a later chapter.

title: Embedded Systems/Embedded System Basics


text:
Embedded Systems/Microprocessor Architectures

The chapters in this section will discuss some of the basics in microprocessor architecture. They will discuss how many features of a microprocessor are implemented, and will attempt to point out some of the pitfalls (speed decreases and bottlenecks, specifically) that each feature represents to the system.

Memory Bus
In a computer, a processor is connected to the RAM by a data bus. The data bus is a series of wires running in parallel to each other that can send data to the memory, and read data back from the memory. In addition, the processor must send the address of the memory to be accessed to the RAM module, so that the correct information can be manipulated.

Multiplexed Address/Data Bus
In old microprocessors, and in some low-end versions today, the memory bus is a single bus that will carry both the address of the data to be accessed, and then will carry the value of the data. Putting both signals on the same bus, at different times is a technique known as "time division multiplexing", or just multiplexing for short. The effect of a multiplexed memory bus is that reading or writing to memory actually takes twice as long: half the time to send the address to the RAM module, and half the time to access the data at that address. This means that on a multiplexed bus, moving data to and from the memory is a very expensive (in terms of time) process, and therefore memory read/write operations should be minimized. It also makes it important to ensure algorithms which work on large datasets are cache efficient.

Demultiplexed Bus
The opposite of a multiplexed bus is a demultiplexed bus. A demultiplexed bus has the address on one set of wires, and the data on another set. This scheme is twice as fast as a multiplexed system, and therefore memory read/write operations can occur much faster.

Bus Speed
In modern high speed microprocessors, the internal CPU clock may move much faster than the clock that synchronizes the rest of the microprocessor system. This means that operations that need to access resources outside the processor (the RAM for instance) are restricted to the speed of the bus, and cannot go as fast as possible. In these situations, microprocessors have 2 options: They can wait for the memory access to complete (slow), or they can perform other tasks while they are waiting for the memory access to complete (faster). Old microprocessors and low-end microprocessors will always take the first option (so again, limit the number of memory access operations), while newer, and high-end microprocessors will often take the second option.

I/O Bus
Any computer, be it a large PC or a small embedded computer, is useless if it has no means to interact with the outside world. I/O communications for an embedded computer frequently happen over a bus called the I/O Bus. Like the memory bus, the I/O bus frequently multiplexes the input and output signals over the same bus. Also, the I/O bus is moving at a slower speed than the processor is, so a large numbers of I/O operations can cause a severe performance bottleneck.

It is not uncommon for different IO methods to have separate buses. Unfortunately, it is also not uncommon for the electrical engineers designing the hardware to cheat and use a bus for more than 1 purpose. Doing so can save the need for extra transistors in the layout, and save cost. For example, a project may use the USB bus to talk to some LEDs that are physically close by. These different devices may have very different speeds of communication. When programming IO bus control, make sure to take this into account.

In some systems, memory mapped IO is used. In this scheme, the hardware reads its IO from predefined memory addresses instead of over a special bus. This means you'll have simpler software, but it also means main memory will get more access requests.

In a later section of this book, ../IO Programming/, we discuss programming the IO bus.


text:
Emergency Medicine/CBC

cbc: hb/ hct/ wbc count/ rbc count/ plt count/

title: Emergency Medicine/CBC


text:
Cookbook talk:Moussaka (Bulgarian)

moussaka is a Greek dish

title: Cookbook talk:Moussaka (Bulgarian)


text: User talk:80.61.191.146

title: User talk:80.61.191.146


text:
User talk:199.43.172.254

-- Herby talk thyme 14:55, 22 January 2008 (UTC)

title: User talk:199.43.172.254


text:
User talk:Ehsansalmani

Copyright problem with Image:Dental x-ray.gif
--Derbeth 20:55, 1 November 2005 (UTC)

title: User talk:Ehsansalmani


text:
User talk:Colin Edinburgh

Come introduce yourself at the new users page. If you have any questions, you can ask there or contact me personally.

title: User talk:Colin Edinburgh


text:
Embedded Systems/Programmable Controllers

The original 8086 processor shipped with a number of peripheral chips that each performed different tasks. Among these chips were programmable Interrupt controllers, programmable timers, and programmable I/O chips that could handle many of the tasks of the original computer, to take some of the computational strain off the 8086. In new versions of Intel chips (486, Pentium, etc.) many of the peripheral chips have been integrated into the processor, in an attempt to speed up the entire computer. However, much of the functionality remains, even in today's high-end computer systems.

Timers
Timers are incredibly useful for performing a number of different operations. For instance, many multi-threaded operating systems operate by setting a timer, and then switching to a different thread every time the timer is triggered. Programmable timer chips can often be programmed to provide a variety of different timing functions, to take the burden off the microprocessor.

Another common application of a timer is to keep track of the time in human units of hours and minutes, and often years, months, and days. Often this real-time clock (RTC) has a battery to keep it running even in systems that are usually plugged into line power. Such a timer can save power in two ways:
 * When we want to know what time it is—for example, when a digital camera time-stamps a picture it just took—the system can read it from the real-time clock. Other ways of figuring out the time require more energy.
 * When a system needs to do something periodically—for example, measure the outside temperature every 10 seconds, and transmit it wirelessly to an indoor display—the system can turn off power to everything except the real-time clock, and then wait for the clock to wake it up.

You can see some of the 8086 compatible timer chips like 8253/54 also they are the same have three independent timers internally but 8254 can work with higher frequencies and is used to generate interrupt like Memory refresh interrupt ,Time of day TOD interrupt and the last one is used to generate the speaker frequencies.

Practically all microcontrollers sold today include integrated timer "peripherals" on the same chip. Most embedded systems either (a) have no external timer chip at all, using only the internal timers, (b) an external real-time clock, or (c) attempt to be PC compatible with a "southbridge" chip that emulates both the 8253-compatible timers and the real-time clock.

Interrupt Controllers
The original 8086 processor had only a single pin used for signaling an interrupt, so a programmable interrupt controller would handle most of the messy details of calling the interrupt. Also, a programmable interrupt controller could be used to monitor an input port for instance, and triggering an interrupt routine when input is received.

Direct Memory Access
Since memory read/write operations take longer than other operations for the microprocessor, one should avoid moving large blocks of memory. Luckily, the original 8086 came with a programmable direct memory access controller (DMA) for use in automatically copying and moving segments of memory. DMAs could also be used for implementing memory-mapped I/O, by being programmed to automatically move memory data to and from an output port.

DMA memory copies can also greatly enhance system performance by allowing the CPU to execute code in parallel with a DMA controller automatically performing the memory copy.

Peripheral Interface Controllers
Peripheral interface controllers take a number of different forms. Each different type of port has a different controller that the microprocessor will interface with to send the output on that port. For instance there are controllers for parallel ports and more modern USB ports. These controllers are used for controlling settings on output such as timing, and setting different modes on the output/input port.


text:
Embedded Systems/Floating Point Unit

Floating point numbers are ....

Like all information, floating point numbers are represented by bits.

Early computers used a variety of floating-point number formats. Each one required slightly different subroutines to add, subtract, and do other operations on them.

Because some computer applications use floating point numbers a lot, Intel standardized on one particular format, and designed floating-point hardware that calculated much more quickly than the software subroutines. The 80186 shipped with a floating-point co-processor dubbed the 80187. The 80187 was a floating point math unit that handled the floating point arithmetic functions. In newer processors, the floating point unit (FPU) has been integrated directly into the microprocessor.

Many small embedded systems, however, do not have an FPU (internal or external). Therefore, they manipulate floating-point numbers, when necessary, the old way. They use software subroutines, often called a "floating point emulation library".

However, floating-point numbers are not necessary in many embedded systems. Many embedded system programmers try to eliminate floating point numbers from their programs, instead using fixed-point arithmetic. Such programs use less space (fixed-point subroutine libraries are far smaller than floating-point libraries, especially when just one or two routines are put into the system). On microprocessors without a floating-point unit, the fixed-point version of a program usually runs faster than floating-point version. However, these embedded system programmers must figure out exactly how much accuracy a particular application needs, and make sure their fixed-point routines maintain at least that much accuracy.

Math Routines
(Is there a better place in this wikibook for this discussion? It doesn't even mention floating point.)

Low-end embedded microcontrollers typically don't even have integer multiply in their instruction set. So on low-end CPUs, you must use routines that synthesize basic math operators (multiply, divide, square root, etc.) from even simpler steps. Practically all microprocessors have such routines, posted on the internet by their manufacturer or other users ("Multiplication and Division Made Easy" by Robert Ashby, "Novel Methods of Integer Multiplication and Division", "efficient bit twiddling methods", etc.).

Following the advice known as "Make It Work Make It Right Make It Fast" and "Make It Work Make It Small Make It Fast", many people pick one or two number resolutions that are adequate for the largest and most precise kind of data handled in a program, and use that resolution for everything. For desktop machines, often 32-bit integers and 64 bit "double precision floating point" numbers are more than adequate. For embedded systems, often 24-bit integers and 24-bit "fixed point" numbers are more than adequate. If the software fits in the microcontroller, and is plenty fast enough, it is a waste of valuable human time to try to "optimize" it further.

Alas, sometimes the software does not fit in the microcontroller.
 * If you run out of RAM, sometimes you only need 2 bytes or 1 byte or 4 bits or 1 bit to store a particular variable.
 * If you run out of time, sometimes you can add lower-precision math routines that quickly calculate the results needed for that inner loop, even though other parts of the code may need higher-precision math routines.
 * If you run out of ROM, sometimes you can trade time for ROM space. Rather than a collection of sets of math routines, each one customized to a slightly different width, you can use a single set of math routines that can handle the maximum possible width. If you have some variables less than that width (to save RAM), then you typically sign-extend variables into a full-size register or global buffer, do full-width calculations there, and then truncate and store the result to the small size.

Fixed-Point Arithmetic
Some embedded microprocessors may have an external unit for performing floating point arithmetic(FPU), but most low-end embedded systems have no FPU. Most C compilers will provide software floating point support, but this is significantly slower than a hardware FPU. As a result, many embedded projects enforce a no floating point rule on their programmers. This is in strong contrast to PCs, where the FPU has been integrated into all the major microprocessors, and programmers take fast floating point number calculations for granted. Many DSPs also do not have an FPU and require fixed-point arithmetic to obtain acceptable performance.

A common technique used to avoid the need for floating point numbers is to change the magnitude of data stored in your variables so you can utilize fixed point mathematics. For example, if you are adding inches and only need to be accurate to the hundredth of an inch, you could store the data as hundredths rather than inches. This allows you to use normal fixed point arithmetic. This technique works so long as you know the magnitude of data you are adding ahead of time, and know the accuracy to which you need to store your data.

FFT
People use many tricks and techniques to speed up Fourier transform calculation. The fast Fourier transform (FFT) is the biggest speedup, but there are several other tricks on top of that that each can give another factor of two improvement.

Many people do FFT using fixed-point arithmetic.

The Fast Hartley Transform is an alternative that requires less resources than the FFT.

DTMF decoders often use the Goertzel algorithm because, when only a few frequencies need to be analyzed, it is much faster than the FFT algorithm.

... more tips and hints here ...

title: Embedded Systems/Floating Point Unit


text:
ZynAddSubFX/PADsynth/CPP Implementation

This page contains a C++ class that implements PADsynth Synthesis Algorithm. Please note that you must implement the IFFT routine.

PADsynth.h
/*   PADsynth implementation as ready-to-use C++ class. By: Nasca O. Paul, Tg. Mures, Romania This implementation and the algorithm are released under Public Domain Feel free to use it into your projects or your products ;-)

This implementation is tested under GCC/Linux, but it's    very easy to port to other compiler/OS.

Please notice that you have to implement the virtual method IFFT with your IFFT routine.

 * 1) ifndef PADSYNTH_H
 * 2) define PADSYNTH_H

 * 1) ifndef REALTYPE
 * 2) define REALTYPE float
 * 3) endif

class PADsynth{ public: /* PADsynth: N               - is the samplesize (eg: 262144) samplerate 	 - samplerate (eg. 44100) number_harmonics - the number of harmonics that are computed */ PADsynth(int N_,int samplerate_,int number_harmonics_);

~PADsynth;

/* set the amplitude of the n'th harmonic */ void setharmonic(int n,REALTYPE value);

/* get the amplitude of the n'th harmonic */ REALTYPE getharmonic(int n);

/* synth generates the wavetable f		- the fundamental frequency (eg. 440 Hz) bw		- bandwidth in cents of the fundamental frequency (eg. 25 cents) bwscale	- how the bandwidth increase on the higher harmonics (recomanded value: 1.0) *smp	- a pointer to allocated memory that can hold N samples */ void synth(REALTYPE f,REALTYPE bw,	   REALTYPE bwscale,REALTYPE *smp); protected: int N;			//Size of the sample

/* IFFT - inverse fast fourier transform YOU MUST IMPLEMENT THIS METHOD! *freq_real and *freq_imaginary represents the real and the imaginary part of the spectrum, The result should be in *smp array. The size of the *smp array is N and the size of the freq_real and freq_imaginary is N/2 */ virtual void IFFT(REALTYPE *freq_real,REALTYPE *freq_imaginary,REALTYPE *smp)=0;

/* relF: This method returns the N'th overtone's position relative to the fundamental frequency. By default it returns N.	   You may override it to make metallic sounds or other instruments where the overtones are not harmonic. */	virtual REALTYPE relF(int N);

/* profile: This is the profile of one harmonic In this case is a Gaussian distribution (e^(-x^2)) The amplitude is divided by the bandwidth to ensure that the harmonic keeps the same amplitude regardless of the bandwidth */ virtual REALTYPE profile(REALTYPE fi, REALTYPE bwi);

/* RND - a random number generator that returns values between 0 and 1 */	virtual REALTYPE RND;

private: REALTYPE *A;		//Amplitude of the harmonics REALTYPE *freq_amp;	//Amplitude spectrum int samplerate; int number_harmonics; };

 * 1) endif

PADsynth.cpp
/*   PADsynth implementation as ready-to-use C++ class. By: Nasca O. Paul, Tg. Mures, Romania This implementation and the algorithm are released under Public Domain Feel free to use it into your projects or your products ;-)

This implementation is tested under GCC/Linux, but it's    very easy to port to other compiler/OS. */

 * 1) include
 * 2) include
 * 3) include
 * 4) include "PADsynth.h"

PADsynth::PADsynth(int N_, int samplerate_, int number_harmonics_){ N=N_; samplerate=samplerate_; number_harmonics=number_harmonics_; A=new REALTYPE [number_harmonics]; for (int i=0;i=number_harmonics)) return; A[n]=value; };

REALTYPE PADsynth::getharmonic(int n){ if ((n<1)||(n>=number_harmonics)) return 0.0; return A[n]; };

REALTYPE PADsynth::profile(REALTYPE fi, REALTYPE bwi){ REALTYPE x=fi/bwi; x*=x; if (x>14.71280603) return 0.0;//this avoids computing the e^(-x^2) where it's results are very close to zero return exp(-x)/bwi; };

void PADsynth::synth(REALTYPE f,REALTYPE bw,REALTYPE bwscale,REALTYPE *smp){ int i,nh; for (i=0;i<N/2;i++) freq_amp[i]=0.0;//default, all the frequency amplitudes are zero

for (nh=1;nh<number_harmonics;nh++){//for each harmonic REALTYPE bw_Hz;//bandwidth of the current harmonic measured in Hz       REALTYPE bwi; REALTYPE fi; REALTYPE rF=f*relF(nh); bw_Hz=(pow(2.0,bw/1200.0)-1.0)*f*pow(relF(nh),bwscale); bwi=bw_Hz/(2.0*samplerate); fi=rF/samplerate; for (i=0;i<N/2;i++){//here you can optimize, by avoiding to compute the profile for the full frequency (usually it's zero or very close to zero) REALTYPE hprofile; hprofile=profile((i/(REALTYPE)N)-fi,bwi); freq_amp[i]+=hprofile*A[nh]; };   };

REALTYPE *freq_real=new REALTYPE[N/2]; REALTYPE *freq_imaginary=new REALTYPE[N/2];

//Convert the freq_amp array to complex array (real/imaginary) by making the phases random for (i=0;imax) max=fabs(smp[i]); if (max<1e-5) max=1e-5; for (i=0;i<N;i++) smp[i]/=max*1.4142; };

REALTYPE PADsynth::RND{ return (rand/(RAND_MAX+1.0)); };

title: ZynAddSubFX/PADsynth/CPP Implementation


text:
Embedded Systems/Parity

In many instances, especially in transmission, it is important to include some amount of error-checking information, so that incorrect information can be determined and discarded. One of the most simple methods of error-checking is called parity. Parity can be broken up into Even Parity, and Odd Parity schemes. A parity check consists of a single bit that is set, depending on a certain condition.

Even Parity
In an even parity scheme, the parity bit is set if an odd number of bits in the data are set to 1 (to make the total number of 1 bits even). For instance, 01001100 would generate an even parity bit, while 11001100 would not generate one.

Odd Parity
The opposite of Even parity, odd parity generates a parity bit if there are an even number of high-bits in the data (to create an odd number of 1's).

Limitations of Parity
Simple 1-bit parity is only able to detect a single bit error, or an error in an odd number of bits. If an even number of bits (2, 4, 6, 8) are transmitted in error, the parity check will not catch the mistake

However, chances of getting 2 errors in 1 transmission is much much smaller than getting only 1 error in 1 transmission. so parity checks serve as a cheap and easy way to check for errors.

More advanced error detection
ECC codes are often used for the same reasons as parity bits. These codes use more bits, however they allow multi bit error detection, and also correction of single bit errors.

CRC checks are usually used at the end of data blocks. These are carefully designed to give a very high probability of detecting corruption of the data block, no matter how many bit errors are in the block.

title: Embedded Systems/Parity


text:
Embedded Systems/Assembly Language

This book will demonstrate techniques for programming embedded systems in assembly language.

x86 Assembly Review
The x86 microprocessor has (at least):

 * 4 general purpose registers : AX, BX, CX, and DX. AX is the fast accumulator.
 * 4 segment registers : CS (code section), DS (data section), ES (extra section), SS (stack section).
 * 5 pointer registers : SI (source index), DI (destination index), IP (instruction pointer), SP (stack pointer), BP (base pointer).
 * 1 flag register : Flags ('7' flags like Zero flag, Carry flag)

Unlike "memory-mapped" processors, the x86 has special "I/O" instructions (inp, outp) intended to talk to I/O hardware.

ARM assembly review
At any one time, 17 registers can be accessed: R0 to R14 (which have identical hardware), R15, and the status register CPSR.

(To reduce latency on interrupt handling, these registers and the SPSR "saved program status register" are "shadowed" during interrupts. Including those shadows, the typical ARM processor has a total of 37 registers).

The standard C calling convention for ARM is:

 * R15: PC: program counter
 * R14: LR: link register (holds return address for most recent subroutine call)
 * R13: SP: stack pointer (for nested subroutine calls)
 * R12-R4: long-term variables: used by a subroutine only if it restores the original values before it returns
 * R3-R0: scratch-pad variables and subroutine-call parameters and subroutine-return results.

I/O hardware is typically "memory mapped".

Motorola/Freescale HCS12 (Star 12) Review

 * 16-bit accumulator register: D, accessible as two 8-bit registers: A (high) and B (low)
 * 2 16-bit index registers: X, Y
 * 16-bit stack pointer register: SP
 * 16-bit program counter: PC
 * 8-bit condition code register: CC

The HCS12 is based on the older 68HC11 and the instruction sets are very similar. The HCS12 is a "Big Endian" processor: multi-byte values are stored from most significant byte to least significant byte in increasing memory addresses.

Word Length
Modern desktop PCs are almost all 32 bit machines, and the next generation of processors is going to be fully 64 bit. This is all well and good for the average programmer, but what do you do when you are in an embedded situation with a microcontroller the size of your finger nail that is capable of only 4 bit arithmetic? 32 bits may be the norm in the desktop market, but there is no gold standard in embedded chips: more bits take up more space and costs more money. In essence, it is the job of a good embedded systems engineer to find the smallest, cheapest microcontroller that does the job that needs to get done. Consider the following table:

 * {| border=1 cellpadding=3px

|- | bits || biggest unsigned number || biggest signed number || smallest signed number* |- | 4 || 15 || 7 || -8 |- | 8 || 255 || 127 || -128 |- | 16 || 65,535 || 32,767 || -37,768 |}
 * * 2's complement format

Even the 16 bit processor is a far cry from the 4 billion integer range of a standard 32 bit processor. Let's say that we have a 4 bit microcontroller with 4 available internal registers (4 bit each), and 256 bytes of onboard programmable memory. This processor cannot handle anything but the most simple tasks! What if we need to manipulate an 8-bit number on this little microprocessor? for instance, what if we want to make a digital clock with it? the 4 bit microprocessor is going to need to handle numbers up to and including 59 (the number of minutes displayed before the next hour). This is going to require more than the 4 bits alotted, in fact it is going to require at least 6 bits of space. What we need to do then, is come up with a way to treat 2 separate small registers as if they are a single large register. This chapter will talk about that subject a little bit.

For further reading

 * Assembly Language
 * AVR Assembler

title: Embedded Systems/Assembly Language


text: Template:Visual Basic .NET/styleCleanup

title: Template:Visual Basic .NET/styleCleanup


text:
User talk:Mri~enwikibooks

All about Mri
Hello, My name is Mri. In case you do not know, a Mri is an alien speicies created and portrayed in the book: "The Faded Sun", by C.J. Cherryh. I did not create the mri, so I don't take any credit, I do really like the mri though. They are my favorite species.

I am american of Mexican Descent and live in Texas. I am Liberal Catholic(Gasp!), and like to question everything that I am told. @w@ I also, believe that Mexican food is God's gift to gringos everywhere. Viva el Gringo!

My hobbies include tinkering with my computer, which is SlackWare Linux distro, Writing my own novels to read, video games, reading manga, and cooking! I like cooking. I don't have any kids, but I hope to someday... just not know. I don't think I could handle kids now. ;)

Yeah...so... Thank You for reading.

Signed: -Mri

On the subject of philosophy
Wikibooks has opened a discussion about whether to keep this book. The book is empty except for a section "Reasons for the making of this book". If you want, you can post to the current discussion at Votes for deletion.

After reading the "Reasons", it seems to me that Wikibooks is not the best place for this book. If you still want to write it, I or other Wikibookians might be able to find a better wiki for you. --Kernigh 22:54, 3 February 2006 (UTC)

 * You did not respond. Four users (including myself) voted to delete On the subject of philosophy, and zero users voted to keep it, so I will now delete it. --Kernigh 23:42, 6 March 2006 (UTC)

Your account will be renamed
Hello,

The developer team at Wikimedia is making some changes to how accounts work, as part of our on-going efforts to provide new and better tools for our users like cross-wiki notifications. These changes will mean you have the same account name everywhere. This will let us give you new features that will help you edit and discuss better, and allow more flexible user permissions for tools. One of the side-effects of this is that user accounts will now have to be unique across all 900 Wikimedia wikis. See the announcement for more information.

Unfortunately, your account clashes with another account also called Mri. To make sure that both of you can use all Wikimedia projects in future, we have reserved the name Mri~enwikibooks that only you will have. If you like it, you don't have to do anything. If you do not like it, you can pick out a different name.

Your account will still work as before, and you will be credited for all your edits made so far, but you will have to use the new account name when you log in.

Sorry for the inconvenience.

Yours, Keegan Peterzell Community Liaison, Wikimedia Foundation 23:31, 17 March 2015 (UTC)

Renamed
 This account has been renamed as part of single-user login finalisation. If you own this account you can |log in using your previous username and password for more information. If you do not like this account's new name, you can choose your own using this form after logging in: . -- Keegan (WMF) (talk) 05:16, 19 April 2015 (UTC)

title: User talk:Mri~enwikibooks


text:
XML - Managing Data Exchange/XLink

Introduction
Through the use of Uniform Resource Identifiers (URI's), an XLink allows elements to be inserted into XML documents that create links between resources such as documents, images, files and other pages. An XLink is similar in concept to an HTML hyperlink, but is more powerful and flexible.

This chapter will be a general overview of the XLink syntax. It will also provide exposure to some of XLink's basic concepts. For the full XLink specification, see the latest version of the standard at:

http://www.w3.org/TR/xlink

XLink
XLinks create a linking relationship between two or more resources. They allow for any XML element, image, text or markup files to be specified in the link.

By using a method similar to the centralized formatting of XSL stylesheets, XLinks allow a document's hyperlinks to be isolated and centralized in a separate document. As a linked document's addresses changes, the XLink remains functional.

The use of XLink requires the declaration of the XLink namespace. This namespace provides the global attributes for type, href, role, arcrole, title, show, actuate, label, from and to. The following example would make the prefix xlink available within the tourGuide element.

XLink global attributes
The following table outlines the attributes that can be used with the xlink namespace. The global attributes are type, href, role, arcrole, title, show, actuate, label, from, and to. The table also includes descriptions of how the attributes can be used.

Exhibit 1: Table of global attributes

XML schema
The following XML schema defines a tour guide that contains at least one city. Each city contains one or more attractions. The name of each attraction is an XLink.

Exhibit 2: XML schema for TourGuide

XML document
The following XML document shows how the XLink, attractionName, defined in the XML schema, is used in an XML document. Note that it is necessary to include xlink:href="" within the attribute tags in order to define the linked website.

Exhibit 3: XML document for TourGuide.xsd (using XLink)

XML stylesheet
The following XML stylesheet displays the contents of the XML document.

Exhibit 4: XML stylesheet TourGuide

title: XML - Managing Data Exchange/XLink


text:
Evolution of Operating Systems Designs

This book is about operating systems concepts as they have evolved through the history of operating systems implementations. Politics and implementation details are irrelevant. Emphasis is given to technically successful designs, aesthetic operating systems, and not on commercial success. In fact, mere commercial success isn't sufficient to make an operating system noteworthy. It also emphasizes working implementations over mere projects.

Table of Contents

 * 1) /What is an Operating System?/
 * 2) /Historiography/
 * 3) /Languages as Operating Systems/
 * 4) /Storage: Mechanisms/
 * 5) /Storage: Addressing Schemes/
 * 6) /Properties of Namespaces/
 * 7) /Security: capabilities/
 * 8) /Networking: Security/
 * 9) /Internetworking and Distribution/
 * 10) /HCI: beyond WIMP/
 * 11) /Uniformity and Reflection/
 * 12) /State of current research/

title: Evolution of Operating Systems Designs


text:
Puzzles/Two-player games/Picking game/Solution

The puzzle as stated doesn't quite state how a "tie" is possible, unless you can refuse to draw. If we assume you -must- draw 1 or 2 matches on your turn, then:

 * 1 match  left - Draw 1 and win (winning state)
 * 2 matches left - Draw 2 and win (winning state)
 * 3 matches left - Drawing 1 or 2 matches puts your opponent in such a state that (s)he will win (losing state)
 * 4 matches left - Drawing 1 puts your opponent into state 3, where no matter what (s)he draws (s)he loses (winning state)
 * 5 matches left - Drawing 2 puts your opponent into state 3, where no matter what (s)he draws (s)he loses (winning state)
 * 6 matches left - Drawing 1 or 2 matches puts your opponent in a winning state (losing state)
 * 7 matches left - Drawing 1 puts your opponent into state 3, where no matter what (s)he draws (s)he loses (winning state)
 * 8 matches left - Drawing 2 puts your opponent into state 3, where no matter what (s)he draws (s)he loses (winning state)
 * 9 matches left - Drawing 1 or 2 matches puts your opponent in a winning state (losing state)

Basically, if there are 3n matches, you're in a losing state, because no matter what you choose, your opponent can leave you in a state 3(n-1) by choosing the opposite (IE 1 + 2 == 3 or 2 + 1 == 3). When n = 1, this 3(n-1) = 3(0) = 0 and your opponent wins because (s)he has drawn the last match. If there are 3n+1 or 3n+2 matches, you choose 1 or 2 respectively, and always leave your opponent 3m matches and you will win, and by the same logic you will win.

So basically, if you both play perfectly, the first player can only win if n Matches mod 3 is nonzero.

Alternatively, if you can refuse to draw a match (possibly intended by the question) you would always draw n mod 3 matches - if it's a multiple of 3 you refuse to draw, otherwise you draw leave a multiple of 3 matches.


text: User talk:Johann Wolfgang

title: User talk:Johann Wolfgang


text:
Ancient History/Greece/Greek Dark Ages

The Ancient Greeks divided themselves into three tribes; the Aeolians, Ionians, and Dorians. The Mycenaeans (referred to as Argives, Achaeans, and Danaans by Homer in the Iliad) were Aeolians and Ionians. Sometime around 1100 BCE, the Dorians, who lived north of the other two tribes, began to raid the Mycenaeans. Entire cities were destroyed, and Mycenae itself fell and was plundered by the invaders. Not only were the citadels of Mycenaean Greece destroyed, but civilization itself would collapse in the region.

Economics
Many theories exist about the cause of the Mycenaeans' collapse. Ecological disasters may have undermined the economy of the agrarian-based Mycenaeans, allowing the Dorians to supplant their society. The Dorians quickly developed trade relations throughout the Mediterranean to replace the old economy. The region of Attica (which included Athens) would rise to dominate the region due to its prominence as a trade center. The change was not immediate, however, as Athens, like the rest of Greece, would need a long recovery from the Mycenaean collapse. These new contacts with outside civilizations would have drastic consequences for the future of Greece.

Language
The most significant immediate change for Greece during this time period was the end of writing. No written records exist for this time period, and writings from subsequent time periods are completely different from those of the Mycenaeans, leading historians to believe that writing was completely forgotten during the Dark Ages. The Dorians spoke a dialect different from that of the Mycenaeans, and due to the absence of a writing system, very few records remain of their language. All modern Greek dialects are descended from Attic Greek ("Classical" Greek), with one exception: the endangered Tsakonian dialect, which is a descendant of Doric, and therefore of considerable interest to linguists.

The Dorians would undoubtedly come into contact with the Phoenicians, a powerful seafaring people from the nearby Levant. The Greeks adopted the Phoenecian concept of an alphabet, and through trade would spread this throughout the Mediterranean. This alphabet was the first to include vowels, replacing the syllabic script of Mycenaean Linear B. The word alphabet itself comes from the names of the first two letters of this new writing system: alpha (Αα) and beta (Ββ).

Due to the lack of a writing system, poets (also known as bards) would have recited the long stories orally and passed them down over the years. Homer's epics could very well be versions of stories first composed, but not written, during the Dark Ages.

Weaponry
The Dorians were a warlike people, and thrust Greece into the Iron Age. Weapons were no longer made of bronze but instead, iron. Weapons became cheaper to make, more durable, and more effective in combat. This functionality replaced the ornate beauty of the craftsmanship of the old Mycenaean weapons. The hoplite was an Ancient Greek infantryman who fought in phalanxes. Cavalry was the preserve of the Greek aristocracy due to the status attached to horse ownership. The cuirass, greaves and crested helmet not only offered protection but also presented a formidable display of height and strength to the enemy.

Politics
During the Dark Ages, the polis (plural poleis), or city-state, would begin to develop. Cities dominated the surrounding landscape, and became independent units. The Dorians did not "conquer" the area in the sense of adding the territory to their domain, as the mountains of the region prevented the continuous contact necessary for a single nation to exist. Each city-state was naturally defended by the surrounding mountains, and each constantly expanded at the expense of its neighbors.

Soon after the invasions, monarchies were established in most, if not all, of the poleis. While the monarch held religious as well as political authority, he did not, however, wield complete control of his government. Many city states came to be dominated by the aristocracy. Tyrants first appeared during this time period. A tyrant was an aristocrat who gained enough power and influence to control the polis. They were backed by a personal hoplite army independent of the city-state, and set up autocratic (though not necessarily "tyrannical", in the modern sense) governments.

Hellenic identity
Despite the mountains separating Greece from unification, the independent poleis did develop commonalities in culture, language, religion, and government. It was during this time period that Greeks began to identify themselves and each other as Hellenes. In spite of the rivalries among the poleis, they shared the same language, the same style of dress, and the same décor, and these traits served to unite them as one and the same: they were all Hellenes.

Contributing to this sense of loose unity were the Olympic Games, begun in 776 BCE. These featured athletes from the various poleis who competed against one another as a religious ritual. Athletes may have competed for personal glory and fame, but the games were first and foremost in honor of Zeus, king of the gods. Olympia featured a temple which contained a 12-meter high statue of Zeus made of ivory and gold. This massive sculpture, created by the famous Phidias, was one of the Seven Wonders of the Ancient World. These games would cease in 393 CE, when they were banned under Roman Emperor Theodosius I in an effort to stamp out paganism.

title: Ancient History/Greece/Greek Dark Ages


text:
Evolution of Operating Systems Designs/Historiography

CP derivatives

 * CP
 * 1) CP-VM
 * 2) CP/M
 * 3) CP/M-86
 * 4) DOS
 * 5) DRDOS
 * 6) FreeDOS
 * 7) Microsoft Windows
 * 8) Windows 3.x
 * 9) Windows 95/98/Me
 * 10) See NT-based versions below

MULTICS derivatives

 * 1) UNIX
 * 2) Unix V5 (SCO Unix)
 * 3) Modern Unix (Solaris / BSD)
 * 4) FreeBSD
 * 5) OpenBSD
 * 6) Xenix
 * 7) Linux
 * 8) Plan 9
 * 9) Inferno
 * 10) QNX
 * 11) VSTa
 * 12) Mac OSX
 * 13) MIPS RISC/os
 * 14) RISC iX

VMS derivatives

 * 1) VMS
 * 2) OpenVMS
 * 3) OS/2
 * 4) eComStation
 * 5) Microsoft Windows NT-based
 * 6) Windows NT
 * 7) Windows 2000
 * 8) Windows XP
 * 9) Windows Vista
 * 10) Windows 7
 * 11) Windows 8 (and 8.1)
 * 12) Windows 10
 * 13) ReactOS (clone of Windows NT-based, not from Microsoft)

MacOS derivatives

 * 1) Mac OS
 * 2) Mac OS 9

Cambridge CAP Computer derivatives

 * 1) KeyKOS
 * 2) EROS
 * 3) Coyotos
 * 4) CapROS

IBSYS derivatives

 * 1) OS/360
 * 2) OS/400

AmigaOS derivatives

 * 1) AmigaOS
 * 2) AROS
 * 3) AmigaOS 4.x
 * 4) MorphOS

Misc. operating systems

 * 1) Grasshopper
 * 2) ITS
 * 3) BeOS
 * 4) RISC OS


text:
Principles of Sociology/Sickness and Wealth

Sickness and Wealth

''The strangest thing about human beings is their shortsightedness. In terms of health, many would contend that if people understood the kind of pain, discomfort, and loss of life their daily behaviors were likely to eventually cause them, they would stop. The beauty of social epidemiology (the study of social distribution and social determinants of disease) is that we are increasingly able to offer the population good information about behavior and disease correlates. However, even with our expanded knowledge and information distribution systems through mass media, people in both the richest and poorest countries continue to die prematurely from completely preventable diseases. The first question is of course WHY??? but the main question (and perhaps the big money question) is what individuals and policy makers can do to alter these trends.''

Wealth Difference – There is a difference in the severity of health problems on a global scale. People in the world's poorest nations die on average a full two decades earlier than the US and other rich nations. In Haiti, before the recent coup, the government's health budget only allotted $1.75 per person per year. Why so low? The main reason is that Haiti is the poorest country in the hemisphere. The other key reason though, is that their state health programs were scaled back in the 1990s to qualify the nation for development loans from the World Bank and International Monetary Fund. These Structural Adjustment Programs (SAPs) seek to scale back state social programs of all sorts in order to allow more free market competition that they believe will generate wealth and a healthy and independent national economy that won't need more loans in the future.

Human Rights? – Is proper medical treatment a human right? The United Nations has said so… but the slippery point is how much medical treatment. There was a time when there was only one form of accepted treatment for a particular disease. Now, there are many approaches with varying success rates and more importantly, varying costs. So how would a human rights stance on health reconcile this growing inequality in treatment methods? Does everyone have a right to the best care available, or just some basic level? Despite the advances in AIDS treatments over the last 15 years, 95% of those infected with the disease don't have access to even the cheapest antiretrovirals because they can't afford them. Even in emergencies, many people in poor places must pay before receiving treatment. Many are “held hostage” till their family can scrape together the money. How can it be that in the "Third World", publicly available drinking water is usually unsafe for human consumption, but that Coca Cola is universally available at affordable prices? Well, because the potential profits demand the market supply it... but that seems sick to most of us.

Diseases of Leisure and Anxiety – In the developing world, but in the United States especially, one need only look at the leading causes of death to see that much of our modern health problems stem from poor lifestyle habits. Smoking, overeating poor foods, and alcoholism pretty much top off the list. These coupled an overall lack of exercise produce very high levels of disease for older Americans. For the younger crowd, mental disorders are much more common. While the exact reasons behind our very high rate of mental disturbance are not really known, they are normally associated with the advent of modern societies and their busy, detached citizens. We believe that all these diseases are easily preventable, but as of yet have not found consistent avenues to get prevention methods adopted on a broad scale. One reason may be that an ounce of prevention may be very worthwhile, but the pound of cure is much more profitable.

Insurance Problems – In the United States, 1 in 6 people don't have health insurance. Many more are under insured. We are the only industrialized nation without a universal health care program. However, our privatized system offers some of the best treatments available in the entire world. Unluckily, many of those who need these advanced treatments most won't be able to afford them. Instead, they will get what Medicaid or Medicare agrees to cover. While our socialized medicine programs are smaller than most rich nations, they still cover about a third of medical expenditures in the country.

Socialized Medicine Elsewhere – Historically, in most places, steep economic downturn has meant a steep drop in life expectancy – Russia (the former USSR ) is perhaps the best example. However, an interesting example of a poor country with great healthcare is Cuba. Despite crushing poverty and a lack of advanced medical tools due to the continued US embargo, Cuba has a life expectancy matching the US and many other rich nations at 78 years ( Japan is at 82). Nearby Haiti has a life expectancy of 53 years, a quarter century less. How can this be? It should make us wonder why other poor countries cannot organize a similar national medical program. If the problem is not wealth, but organization, perhaps there is something to be learned here. Instead of trying to teach poor nations economic discipline through SAPs dismantling their socialized health programs, perhaps they could be remodeled like Cuba – this doesn't require communism or global isolation.

The Medical Industry – Companies develop treatments primarily to make money, although helping sick people feel better is a nice bonus. The problem lies in how companies go about marketing their product in such a way that the maximum number of patients think they need the treatment. The aggressive promotion of prescription drugs on television over the last decade is a wonderful example. Drug companies want patients to think of themselves as consumers and doctors as customer service representatives. Thus, patients are encouraged to seek out particular treatments although they likely do not understand the risks involved or the alternatives available. It is up to doctors to provide complete product information to the best of their ability. Unluckily, much of that information has been produced by the companies themselves or by groups with ties to the companies. This conflict of interest pits science against business. Furthermore, elective procedures have basically become the norm in American medicine.


text:
Talk:Rhetoric and Composition/Description

In wonder if "Why Write a Descriptive Essay?" could be rewritten to better approach the subject from a student's perspective. It also might serve the article better by narrowing the focus to descriptive essays, rather than discuss description generally. Perhaps there could be an emphasis on how concrete descriptions increase an essay's persuasive ability.

In the subject, "Abstract Descriptions Versus Concrete Descriptions", better examples might be created that demonstrate how specificity and vivacity are gained through concrete descriptions. Perhaps this could be done by pairing each of the abstract descriptions with a better description of the same object that uses concrete language.

And the sensory descriptions might be rewritten to be better examples of their sense. Some, such as "flowers in spring" (smell), "sandpaper" (touch), "falling off water skis" (touch), or "lutefisk or lefsa during the holidays" (taste), may not be the clearest examples of using a specific sense to provide a description.

Shawn Blank (discuss • contribs) 18:54, 11 October 2012 (UTC)Shawn_Blank

A section about using/avoiding cliches may also be useful to students.

-- Mindy (November 18, 2008) This section jumps right into genre. This should either be changed or explained better.

--JonathanP 22:45, 10 October 2006 (UTC) I'm trying to figure out what to change on this Description page. The suggestion below is from almost a year ago and seems outdated. The TODO list states, "We need a sample descriptive essay here to really make this chapter complete. I'd also like to get those questions in a better format (maybe using the built-in list features." Should I still make a sample essay even though the page basically has one (the Minnesota environment piece)?  Also, what questions is the TODO list referring to?  The ones under "Genre Analysis, Genre and Composition" seem fine to me.  I can still change them, though.

--Mattbarton.exe 00:43, 2 November 2005 (UTC) We need to format the images on this page a bit better. See example in the oral presentations section.