For all the video stuff please visit the facebook page Saty Endra
I dont want to distract the attention of readers :-)))
But videos are not updated still yet
Monday, March 19, 2012
First Thing to Know
Embedded System is directly related to the microcontroller. So you should have at least knowledge on one microcontroller (8/16/32 Bit). Presently most of the embedded professionals are prefer to write the code in C language. So you should have a good knowledge on C. Instead of C if you know the some other languages like: - C++, Embedded C, Assembly and ADA, it will put very good impression on Interviewer.
Books to Read>
1. 8051 controller by Mazidi
Practice all the exercises not leaving a single example
Some more questions on Interview
1. Write the syntax of function pointer. Then write a function how to use declare, define and use the function pointer.
2. Take 2 string and contactinate with out using the library functions
copy one string to another string.
3. Difference between structure and union. gave a structure decalration and union declaration and asked to say the difference. how to assign the values or initialize a structure members and union members. what is the size of the structure of the given structure and the given union.
4. What is static? what happens if a variable is declared with the storage class static and what happens if the function is declared as static and what happens if the a function pointer is declared as static.
5. How to know the size of the 'int' of a particular micro controller whose int size is not known(1bit or 32bit) without using the sizeof operator.
6. if extern declaration is made in a .h file do we need to include this .h in the .c file?
7. If a static variable is declared both globally and locally in a function. then when we are using that varible in the function which variable will be considered whether the local variable or global variable?
8. How a volatile variable is used give one usecase how to use?
9. What is an inline function? what is the differnce between inline and macro? which will be better?
10. AUTOSAR archetecture where our modules lye and what are upper layers to that?
11. Write a macro to in generic way to set and bit and reset a bit.
12. write a function to mask nth bit of the number(set and reset).
13. questions regarding typecasting
14. CAN - how to gain the bus. and how to know which node had gained the bus.
Describe the field of the CAN frame
15. how to add two numbers using bitwise operators
16. Where the global, static, local variables are allocated in the RAM. What heap ares contais?
17. fibonic series program logic
strcpy(p, q)
strcpy(char *src, char *dst)
{
while(*src++ =! '\0')
{
*dst++ = *src++;
}
}
strcpy(p, q)
strcpy(char *src, char *dst)
{
while(*dst++ =! '\0')
{
*src++ = *dst++;
}
}
main()
{
int f1, f2, f3;
f1 = 0;
f2 = 1;
while(i != 8)
{
f3 = f2 + f1;
f1 = f2;
f2 = f3;
}
}
Set(int n)
{
return((data) || (01 << n));
}
Reset(int n)
{
return((data) && ~(01 << n));
}
Qualifiers in C
JB Enterprises Type Qualifiers In C 2005.06.28
Johan Bezem
tqinc.doc – rev. 1.1 Page 1 of 4
Type qualifiers in C
Abstract
Type qualifiers are part of the C language since 1989 (const and volatile) respectively 1999
(restrict). They are used to qualify types, modifying the properties of variables in certain ways.
Since qualifiers are one of the lesser-understood features of the language, this article aims at
experienced C programmers, and explains the reasoning behind these qualifiers.
Introduction
Since 'Standard C' (C89), all variables are considered "unqualified" if none of the available qualifiers is
used in the definition of the variable. Additionally, since all three qualifiers are completely independent
from one another, for each unqualified simple type, we may have seven (23 – 1) forms of qualified
types.
Beware that qualifiers change the properties of their variables only for the scope and context in which
they are used. A variable declared 'const' is a constant only as far as the current scope and context is
concerned. If we widen the scope (and regard, for instance, the callers of the function) or the context
(for instance, other threads or tasks, interrupt service routines, or different autonomous systems), the
variable may very well be not constant at all. For 'volatile' and 'restrict', similar arguments exist.
Consider calling 'memcpy', prototyped
void *memcpy(void *dest, const void *src, size_t len);
with a source pointer pointing to a regular (non-read-only) part of your memory.
Const
The qualifier 'const' is most often used in modern programs, and probably best understood. The
addition of a 'const' qualifier indicates that the (relevant part of the) program may not modify the
variable. Such variables may even be placed in read-only storage (cf. section ""). It also allows certain
kinds of optimizations, based on the premise that the variable’s value cannot change. Please note,
however, that "const-ness" may be cast away explicitly.
Since 'const' variables cannot change their value during runtime (at least not within the scope and
context considered), they must be initialized at their point of definition.
Example:
const int i = 5;
An alternate form is also acceptable, since the order of type specifiers and qualifiers does not matter:
int const i = 5;
Order becomes important when composite types with pointers are used:
int * const cp = &i; /* const pointer to int */
const int * ptci; /* pointer to const int */
int const * ptci; /* pointer to const int */
The pointer cp is itself const, i.e. the pointer cannot be modified; the integer variable it points to can.
The pointer ptci can be modified, however, the variable it points to cannot.
Using typedef complicates the placement issue even more:
typedef int * ip_t;
const ip_t cp1 = &i; /* const pointer to int */
ip_t const cp2 = &i; /* const pointer to int!! */
Casting away 'const-ness' is possible, but considered dangerous. Modifying a const-qualified variable
in that way is not only dangerous, but may even lead to run-time errors, if the values are placed in
read-only storage:
const int * ptci;
int *pti, i;
const int ci;
ptci = pti = &i;
JB Enterprises Type Qualifiers In C 2005.06.28
Johan Bezem
tqinc.doc – rev. 1.1 Page 2 of 4
ptci = &ci;
*ptci = 5; /* Compiler error */
pti = &ci; /* Compiler error */
pti = ptci; /* Compiler error */
pti = (int *)&ci; /* OK, but dangerous */
*pti = 5; /* OK, dangerous and potential runtime error */
PC-Lint and similar tools, as well as some compilers, will warn you about such dangerous situations, if
you will let them.
Placement
Placement of variables in actual memory is hardly standardized, because of the many requirements of
specific compilers, processor architectures and requirements. But especially for const-qualified
variables, it is a very interesting topic, and needs some discussion.
First of all, placement is compiler-specific. This means, that a compiler may specify how a programmer
or system architect may direct the linker an loader as to where to place which variables or categories
of variables. This may be done using extra configuration files, or using #pragma's, or some other way.
Refer to your compiler manual, especially when writing code for embedded systems.
If you revert to the compiler defaults, the compiler/linker/loader1 may put const-qualified variables (not
such combinations like 'pointer-to-const', since here the variable is a 'pointer' and non-const!) into readonly
storage. If the compiler has no other indication, and can oversee the full scope of the variable (for
instance, a static const int const_int = 5; at the global level in some C source file), it may
even optimize in such a way, that the variable effectively disappears (replacing each occurrence with
an immediate value), though not all compilers provide this kind of optimization.
If the compiler retains the variable as such (i.e. the variable is still present in the object-file), qualified
with the property 'const', the linker combines all corresponding references throughout all modules into
one, complaining if the qualifications do not match, and the loader gets to decide, where the variable is
placed in memory (dynamic linkers are even more complex, and disregarded here). If a memory area
with read-only storage is available, const-qualified variables may end up there, at the discretion of the
loader.
For details, consult your compiler manuals.
Volatile
The qualifier 'volatile' is normally avoided, understood only marginally, and quite often forgotten. It
indicates to the compiler, that a variable may be modified outside the scope of the program. Such
situations may occur for example in multitasking/-threading systems, when writing drivers with interrupt
service routines, or in embedded systems, where the peripheral registers may also be modified by
hardware alone.
The following fragment is a classical example of an endless loop:
int ready = 0;
while (!ready);
An aggressively optimizing compiler may very well create a simple endless loop (Microsoft Visual
Studio 6.0, Release build with full optimization):
$L837:
; 5 : int ready = 0;
; 6 : while (!ready);
00000 eb fe jmp SHORT $L837
If we now add 'volatile', indicating that the variable may be changed out of context, the compiler is
not allowed to eliminate the variable entirely:
1 In most compiler tool chains, the loader is an integrated part of the linker. For several embedded systems, however, the linker
only produces relocatable code segments, to be effectively placed in memory by the loader.
JB Enterprises Type Qualifiers In C 2005.06.28
Johan Bezem
tqinc.doc – rev. 1.1 Page 3 of 4
volatile int ready = 0;
while (!ready);
becomes (using the option "favor small code"):
; 5 : volatile int ready = 0;
00004 33 c0 xor eax, eax
00006 89 45 fc mov DWORD PTR _ready$[ebp], eax
$L845:
; 6 : while (!ready);
00009 39 45 fc cmp DWORD PTR _ready$[ebp], eax
0000c 74 fb je SHORT $L845
As you can see, even with aggressive, full optimization, the code still checks the variable every time
through the loop.
Most compilers do not optimize this aggressively by default, but it is good to know that it is possible.
The ordering issues as discussed in the section for the qualifier 'const' also apply for 'volatile'; if in
doubt, refer back to page 1.
When do you need to use 'volatile'?
The basic principle is simple: Every time when a variable is used in more than one context, qualify it
with 'volatile':
· Whenever you use a common variable in more than one task or thread;
· Whenever you use a variable both in a task and one or more interrupt service routines;
· Whenever a variable corresponds to processor-internal registers configured as input (consider
the processor or external hardware to be an extra context).
Does it hurt to use 'volatile' unnecessarily?
Well, yes and no. The functionality of your code will still be correct. However, the timing and memory
footprint of your application will change: Your program will run slower, because of the extra read
operations, and your program will be larger, since the compiler is not allowed to optimize as
thoroughly, although that would have been possible.
Why don’t we declare all variables 'volatile'?
Well, we partially do: On DEBUG-builds, all optimization is usually disabled. This is not quite the same,
since the read operations needed extra are not necessarily inserted, but for most practical purposes,
no optimizations involving the (missing) 'volatile' qualification are executed. This can be considered
at least partially equivalent.
We don’t, however, deliver DEBUG-builds to the customer: They usually are too big and too slow
(among a few other properties), just like if we declare all variables to be 'volatile'.
But, whenever in doubt, it is better to use 'volatile' unnecessarily, than to forget it when really
necessary.
Restrict
A discussion of the qualifier 'restrict' is postponed until later, for multiple reasons:
· It is a new addition for C99 (the standard from 1999), hardly available in older compilers;
· The optimizations enabled by using the 'restrict' qualification have been present in most
commercial compilers, however, only on a global basis (compiler options); the extra gain to be
expected is not quite as large, therefore, the necessity of using this qualifier can be considered
minimal;
· My personal experience with this qualifier is still minimal.
JB Enterprises Type Qualifiers In C 2005.06.28
Johan Bezem
tqinc.doc – rev. 1.1 Page 4 of 4
One hint: If your compiler doesn't implement 'restrict' (yet), and doesn't even reserve the keyword,
make sure to define a high-level macro, in order to prevent programmers using the name for a variable
or similar:
#define restrict /* Reserved word */
Combining qualifiers
In the introduction the existence of seven different qualified types for each (simple) unqualified one has
been stated. Using three qualifiers, this means that qualifiers can be combined.
In C89, each qualifier may only be used once, in C99, multiple occurrences of each single qualifier are
explicitly allowed and silently ignored.
But now, take 'volatile' and 'const': What does it mean to have a variable qualified with both:
const volatile unsigned int * const ptcvi = 0xFFFFFFCAUL;
OK, the initialization value is hexadecimal, unsigned long, and taken from an imaginary embedded
processor. The pointer is const, so I cannot change the pointer. And the value it points to is "const
volatile unsigned int": I cannot change the value (within my current scope and context), and
the value may be changed out of context.
So, imagine a free running counter, counting upwards from 0 to 65535 (hexadecimal 0xFFFF or 16 bit),
and rolling over again to 0. If this counter is automatically started by the hardware, or started by the
(assembly-coded) startup-routine (outside the cope of the C program), is never stopped, and only used
for relative time measurements, we have exactly this situation: The counter is read-only, so I want the
compiler to supervise all programmers, that they do not try to write the counter register.
At the same time, the value is constantly changed, so if I want to use the value, the compiler better
make sure to re-read the value in every single case.
You can also imagine a battery backed-up clock chip, running autonomously, with values for the
current date and time memory-mapped into the processors virtual memory space.
OK, such situations will not occur every day, and for many programmers they will never occur. But it is
not unimaginable. And now go out and ask the most experienced C programmer you know, whether it
is possible, allowed and/or useful. You’ll be amazed about the answers you’ll get (or maybe not).
Literature:
C A Reference Manual – (5th edition); Samuel P. Harbison III, Guy L. Steele Jr; Prentice hall, 2002;
ISBN 0-13-089592X.
Comments, remarks and criticism are welcome.
Johan Bezem
j.bezem@computer.org
http://www.bezem.de
Learn this and get job
Interview Questions:
1. What are static variables?
2. What are volatile variables?
3. What do you mean by const keyword ?
4. What is interrupt latency?
5. How you can optimize it?
6. What is size of character, integer, integer pointer, character pointer?
7. What is NULL pointer and what is its use?
8. What is void pointer and what is its use?
9. What is ISR?
10.What is return type of ISR?
11.Can we use any function inside ISR?
12.Can we use printf inside ISR?
13.Can we put breakpoint inside ISR?
14.How to decide whether given processor is using little endian format or big endian format ?
15.What is Top half & bottom half of a kernel?
16.Difference between RISC and CISC processor.
17.What is RTOS?
18.What is the difference between hard real-time and soft real-time OS?
19.What type of scheduling is there in RTOS?
20.What is priority inversion?
21.What is priority inheritance?
22.How many types of IPC mechanism you know?
23.What is semaphore?
24.What is spin lock?
25.What is difference between binary semaphore and mutex?
26.What is virtual memory?
27.What is kernel paging?
28.Can structures be passed to the functions by value?
29.Why cannot arrays be passed by values to functions?
30.Advantages and disadvantages of using macro and inline functions?
31.What happens when recursion functions are declared inline?
32.#define cat(x,y) x##y concatenates x to y. But cat(cat(1,2),3) does not expand but gives
preprocessor warning. Why?
33.Can you have constant volatile variable? Yes, you can have a volatile pointer?
34.++*ip increments what? it increments what ip points to
35.Operations involving unsigned and signed — unsigned will be converted to signed
36.malloc(sizeof(0)) will return — valid pointer
37.main() {fork();fork();fork();printf("hello world"); } — will print 8 times.
38.Array of pts to functions — void (*fptr[10])()
39.Which way of writing infinite loops is more efficient than others? there are 3ways.
40.Who to know whether system uses big endian or little endian format and how to convert
among them?
41.What is forward reference w.r.t. pointers in c?
42.How is generic list manipulation function written which accepts elements of any kind?
43.What is the difference between embedded systems and the system in which RTOS is running?
44.How can you define a structure with bit field members?
45.How do you write a function which takes 2 arguments - a byte and a field in the byte and
returns the value of the field in that byte?
46.Which parameters decide the size of data type for a processor ?
47.What is job of preprocessor, compiler, assembler and linker ?
48.What is the difference between static linking and dynamic linking ?
49.How to implement a WD timer in software ?
PDLC Diagram
Remember the above diagram and any company follows the above steps to develop a product
Start working on each step and google to know what are the activities are performed in each step of the above
Understand broad concept o product development
supplementary
Requirements for an efficient NPI process
- The phases of the NPI process
- Requirements and benefits of an efficient NPI process
- A requirements list for the NPI process
The phases of the NPI process
The New Product Introduction process consists of the all the work involved in developing, prototyping and manufacturing a product to be introduced as an organisation’s new product for a market-place. There are generally four phases: Concept design; Physical design; Prototype manufacture; Pre-production and volume ramp. After this, the product will be handed over to full production, and the organisation may also have some involvement in after-sales.Phase 1 – Concept design
A concept is a description of the features, form and function of a product and is usually accompanied by a set of specifications, analysis of competitive products and economic justification of the project.
Determination of customer requirements. This will be interlaced with the marketing functions that will establish whether the market exists, collect customer needs and identify lead users.
Product Design Specification. The development team will identify and benchmark competitive products and provide functional requirements and technical specifications. Plans for product options and extended product families will be developed.
Design analysis. Initially, concept development and technology assessment will take place considering product platform and architecture. Alternative concepts will be investigated and experimental prototypes built and tested. Selection of the best will take place.
Phase 2 – Physical design
Design realisation. Schematics and product layout drawings will be generated and simulations of the design will be carried out for product function, environment and any qualification to recommended regional or global safety or design standards.
Component procurement and supplier negotiations. Unit quantities would be known for bargaining power with component suppliers and designs would have to be assessed with contractors’ process capabilities.
Test strategy and process development. Manufacturing simulations would ensure the process compatibility of the manufacturing functions, both in-house and contract. Test engineers would ensure testability of the design during production.
Phase 3 – Prototype
Verification of design and process information. Prototypes should be built as close as possible to the full-scale assembly using the intended components and processes. Tooling and specialised process equipment would be designed and tested.
Conformance test and customer acceptance/demonstration products. Beta prototypes would be tested internally and used for demonstration purposes or for customer conformance and approval.
Phase 4 – Pre-production and volume ramp
Volume manufacturing qualification. Increasing product maturity levels is important for product quality and process refinement. Any final engineering changes should be actioned before large-scale manufacture. Also, the work force can be trained to use any new production processes, machines or tooling.
Evolution of manufacturing efficiencies and yields. The first process results are gathered for yield improvement studies etc.
Market and supply chain development. Market push can continue with products visible at trade fairs, customer visits etc. Regular order quantities can be placed and suppliers tested for delivery times and quantities.
Product use, product demise, disassembly and disposal
Issues to consider are:- distribution and field service
- spares and repair
- take-back, disassembly, recovery,
- re-use, refurbishment and disposal.
Requirements and benefits of an efficient NPI process
It is particularly useful to consider the electronics industry because it has been under considerable pressure recently. The sales life of electronic products has decreased, prices have fallen and expectations of quality and functionality have risen. Since the 1970s, Western manufacturing in general has seen aggressive competition from traditionally subdued Far Eastern based companies. Communication technology has improved, with email and the internet, to the point that competition that was once local is now global. Here, we will explore these pressures on the electronics industry and the effect on profits. Once we understand the reasons, we can address them.Most companies realise the importance of an efficient NPI process to develop products and get those products to the customer as quickly as possible. In the electronics industry it can mean the difference between success and failure or in extreme circumstances survival and closure. From a list of NPI efficiencies we can determine a requirements list for an NPI process to maximise profits.
The pressure on the electronics industry
The graph in Figure 1 shows the change in profit making period for various industries during the 1990s and the particular pressure on the electronics industry.Figure 1: The change in pay-off and product life span over the 1990s
Increasing profits during the NPI process
A reduction in potential profits gained requires solutions. Figure 2 is a typical product’s sales and profit cycles. The sales cycle shows no sales while the product is being developed, increase in sales on introduction to a market, steady growth of sales to a constant level during product maturity and the drop in sales during decline.Figure 2: Profit and sales cycles for a typical product’s introduction, maturity and decline
Product development: There are no sales therefore the profit is negative
Product introduction to the market and growth: profits increase sharply as sales rise
Maturity and decline: The sales steady and eventually decline and the profits steadily decline throughout
Increasing profits during the NPI process
Can you suggest why the profit curve is this shape and how these profits can be maximised?Compare your answer with the discussion that follows.
Increasing profits in the electronics industry
There are three issues to consider here:Issue 1
The first issue is the initial loss during the developmental or NPI stage (including product design, prototype manufacturing and ramp to volume production).Figure 3: The profit and sales cycles for a typical product’s introduction, maturity and decline, highlighting the development phase
- Reduce the costs during the development stage (the depth of the dip). Smaller development costs will mean a faster return on investment (ROI); once the product’s sales pay off the ROI, then the product will make real profit.
- Reduce the development time. The shorter the development time, the sooner the product is introduced and the sooner it starts to generate returns.
Figure 4: The benefits of early introduction of a product to market
- Extension in product sales life. Products introduced earlier seldom become obsolete later. Consequently each month saved from the development cycle implies an extension to the sales period.
- Increased market share. The first product to the market has a 100% market share until competition catches up and releases its own. In some markets such as software and machine tools, once a system is purchased the buyer is virtually locked into the product type due to the high premium required to change.
- Higher profit margins. With no other competitor, a company can enjoy pricing freedom and higher margins. The price may decrease later as competitor’s products enter the market.
Development time and cost reduction can be achieved by using tools like concurrent engineering, DfM, Value Analysis during the design phases, and Lean Manufacture and TQM during prototype manufacturing.
Issue 2
The second issue is the huge swing to a high profit on introduction of the product. The company would like to make this as high as possible and as steep as possible.Figure 5: The profit and sales cycles for a typical product’s introduction, maturity and decline, highlighting the introduction and growth phases
- Early or, if possible, first entry into the market. Again a fast development process is required – this aspect is described above.
- Good promotional activity of the right product. An awareness of the market and its customers is required to highlight potential market sectors for product launching. This information would be provided by marketing functions, but the development team is responsible for:
- Ensuring the product only satisfies the requirements of the customer. Development time and cost can easily be wasted on adding unnecessary functions to a product.
- Ensuring the developed product is of the best quality. This is a powerful product differentiator that improves a company’s reputation, sales margins, price potential and product sales life. A poor quality product can have a disastrous effect.
Issue 3
The third is the slow decline in profit as the product matures and declines.Figure 6: The profit and sales cycles for a typical product’s introduction, maturity and decline, highlighting the maturity and decline phases
[back to top]
A requirements list for the NPI process
We can now derive a list of requirements for an organisation’s NPI process.Develop the right product. We must first make sure we understand the market we are introducing our products to. The marketing functions must make sure it is the right market and provide added value if we are competing with other similar products. The development team must provide correct functional specifications with any options offered to ensure the development energy is focused on the right product. They must benchmark against competitor’s products if available.For NPI to work cost-effectively, we need to use appropriate tools to increase the efficiency. What some of these tools are, and the areas where can be applied in relation to the flow chart given in Figure 7, is the subject of New Product Introduction tools.
Fast development process. Once we know what the product is supposed to do we must develop that product as quickly and cheaply as possible.
A cost effective manufacturing process. If the product is cheaper to manufacture than the competitors’ products, there will be greater profit margins, a faster ROI and more scope for sales functions to undercut competitors.
Provide quality products on time, every time. The aim is to provide ‘Total Customer Satisfaction’.
Figure 7: Flow chart of a typical product development process
MISRA C Rules
MISRA C Rules
The following is a summary of the MISRA C rules. This document is not a definitive list these rules,
which are only and completely defined in "MISRA Guidelines for the use of the C language in
vehicle based software".
Environment
1 (req): All code shall conform to ISO 9899 standard, with no extensions permitted.
2 (adv): Code written in languages other than C should only be used if there is a defined interface
standard for object code to which the compiler/assembler for both languages conform
3 (adv): Assembler language functions that are called from C should be written as C functions
containing only in-line assembly language, and in-line assembly language should not be
embedded in normal C code
4 (adv): Provision should be made for appropriate run-time checking
Character Sets
5 (req): Only those characters and escape sequences that are defined in the IOS C standard shall be
used
6 (req): Values of character types shall be restricted to a defined and documented subset of ISO
10646-1
7 (req): Tri-graphs shall not be used
8 (req): Multibyte characters and wide string literals shall not be used
Comments
9 (req): Comments shall not be nested
10 (adv): Sections of code should not be commented out
Identifiers
11 (req): Identifiers shall not rely on the significance of more than 31 characters.
Compiler/linker shall check to ensure that 31 char significance and case sensitivity are
supported for external identifiers
12 (adv): Identifiers in different namespace shall not have the same spelling.
Structure members are an exception
Types
13 (adv): The basic types char, int, short, long, double and float should not be used. Specific-length
equivalents should be typedef’d for the specific compiler, and these names used in the code
14 (req): The type char shall always be declared as unsigned char or signed char.
See rule 13
15 (adv): Floating point implementations should comply with a defined floating point standard
16 (req): The underlying bit representation of floating point numbers shall not be used in any way
by the programmer
17 (req): typedef names shall not be reused
Constants
18 (adv): Numeric constants should be suffixed to indicate type if possible
19 (req): Octal constants shall not be used
Zero is okay
Declarations and Definitions
20 (req): All object and function identifiers shall be declared before use
21 (req): Identifiers in an inner scope shall not use the same name as an identifier in an outer scope,
and therefore hide that identifier
22 (adv): Declaration of object should be at function scope unless a wider scope is necessary
23 (adv): All declarations at file scope should be static if possible
24 (req): Identifiers shall not simultaneously have both internal and external linkage in the same
translation unit
25 (req): An identifier with an external linkage shall have exactly one external definition
26 (req): If objects are declared more than once they shall have compatible declarations
27 (adv): External objects should not be declared in more than one file
28 (adv): The register storage class specifier should not be used
29 (req): The use of a tag shall agree with its declaration
Initialisation
30 (req): All automatic variables shall have a value assigned to them before use
31 (req): Braces shall be used to indicate and match the structure in the non-zero initialisation of
arrays and structures
32 (req): In an enumerator list the = construct shall not be used to explicitly initialise members other
than the fist unless it is used to initialise all items
Operators
33 (req): The right hand operand of a && or || shall not contain side effects
34 (req): The operands of a logical && or || shall be primary expressions
A single identifier, constant or parenthesised expression
35 (req): Assignment operators shall not be used in expressions that return Boolean values
36 (adv): Logical operators shall not be confused with bitwise operators
37 (req): Bitwise operations shall not be performed on signed integer types
38 (req): The right hand operand of a shift operator shall lie between zero and one less the width in
bits of the left hand operand
39 (req): The unary minus operator shall not be applied to an unsigned expression
40 (adv): The sizeof operator should not be used on expressions that contain side effects
41 (adv): The implementation of integer division in the chosen compiler should be determined,
documented and taken into account
42 (req): The comma operator shall not be used, except in the control expression of a for loop
Conversions
43 (req): Implicit conversions that might result in a loss of information shall not be used
44 (adv): Redundant explicit cast should not be used
45 (req): Type casting from any type to or from pointers shall not be used
Expressions
46 (req): The value of an expression shall be the same under any order of evaluation that the
standard permits
47 (adv): No dependence should be placed on C’s precedence rules
48 (adv): Mixed precision arithmetic should use explicit casting to generate the desired result
49 (adv): Tests of a value against zero should be explicit, unless the operant is effectively Boolean
50 (req): Floating point variables shall not be tested for exact inequality or inequality
51 (adv): Evaluation of constant unsigned integer expression should not lead to wrap-around
Control Flow
52 (req): There shall be no unreachable code
53 (req): All non-null statements shall have a side effect
54 (req): A null statement shall only appear on a line by its self, and shall not have any other text on
the same line
55 (adv): Label should not be used except in switch statements
56 (req): The goto statement shall not be used
57 (req): The continue statement shall not be used
58 (req): The break statement shall not be used, except to terminate the cases of a switch statement
59 (req): The statements forming the body of an if, else if, else, while, do … while or for statement
shall always be enclosed in braces
60 (adv): All if, else if constructs should contain a final else clause
61 (req): Every non-empty case clause in a switch statement shall be terminated with a break
statement
62 (req): All switch statements shall contain a final default clause
63 (adv): A switch expression should not represent a Boolean value
64 (req): Every switch statement should have at least one case
65 (req): Floating point variables shall not be used as loop counters
66 (adv): Only expression concerned with loop control should appear within a for statement
67 (adv): Numeric variables being used within a for loop for iteration counting should not be
modified in the body of the loop
Functions
68 (req): Functions shall always be declared at file scope
69 (req): Functions with a variable number of arguments shall not be used
70 (req): Functions shall not call themselves directly or indirectly
71 (req): Functions shall always have prototype declarations and the prototype shall be visible at
both the function definition and call
72 (req): For each function parameter the type given and definition shall be identical, and the return
type shall be identical
73 (req): Identifiers shall either be given for all parameters in a prototype declaration, or none
74 (req): If identifiers are given for any parameters, then the identifiers used in declaration and
definition shall be identical
75 (req): Every function shall have an explicit return type
76 (req): Functions with no parameter list shall be declared with parameter type void
77 (req): The unqualified type of parameters passed to a function shall be compatible with the
unqualified expected types defined in the function prototype
78 (req): The number of parameters passed to a function shall match the function prototype
79 (req): The value returned by void functions shall not be used
80 (req): Void expressions shall not be passed as function parameters
81 (adv): const qualification should be used on function parameters that are passed by reference,
where it is intended that the function will not modify the parameter
82 (adv): A function should have a single exit point
83 (req): For functions that do not have a void return type:
i) There shall be one return statement for every exit branch (including the end of the
program)
ii) Each return shall have an expression
iii) The return expression shall match the return type
84 (req): For functions with void return type, return statements shall not have an expression
85 (adv): Functions called with no parameters should have empty parentheses
86 (adv): If a function returns error information then that information should be tested
Pre-Processing Directives
87 (req): #include statements in a file shall only be preceded by other pre-processor directives or
comments
88 (req): Non-standard characters shall not occur in header file names in #include directives
89 (req): The #include directive shall be followed by either a of "filename" sequence
90 (req): C macros shall only be used for symbolic constants, function like macros, type qualifiers
and storage class specifiers
91 (req): Macros shall not be #define'd and #undef'd within a block
92 (adv): #undef should not be used
93 (adv): A function should be used in preference to a function-like macro
94 (req): A function-like macro shall not be 'called' without all of its arguments
95 (req): Arguments to a function-like macro shall not contain tokens that look like pre-processor
directives
96 (req): In the definition of a function-like macro the whole definition, and each instance of a
parameter, shall be enclosed in parenthesis
97 (adv): Identifiers in pre-processor directives should be defined before use
98 (req): There shall be at most one occurrence of the # or ## pre-processor operators in a single
macro definition
99 (req): All use of #pragma directive shall be documented and explained
100 (req): The defined pre-processor operator shall only be used in one of the two standard forms
Pointers and Arrays
101 (adv): Pointer arithmetic shall not be used
102 (adv): No more than 2 levels of pointer indirection should be used
103 (req): Relational operators shall not be applied to pointer types except where both operands are
of the same type and point to the same array, structure or union
104 (req): Non-constant pointers to functions shall not be used
105 (req): All functions pointed to by a single pointer to a function shall be identical in the number
and type of parameters and the return type
106 (req): The address of an object with automatic storage shall not be assigned to an object which
may persist after the object has ceased to exist
107 (req): The null pointer shall not be dereferenced
Structures and Unions
108 (req): In the specification of a structure or union type, all members of the structure or union shall
be fully specified
109 (req): Overlapping variable storage shall not be used
110 (req): Unions shall not be used to access the sub-parts of larger data types
111 (req): Bit fields shall only be defined to be one of type unsigned int or signed int
112 (req): Bit fields of type signed int shall be at least 2 bits long
113 (req): All members of a structure or union shall be named and shall only be access with their
name
Standard Libraries
114 (req): Reserved words and the standard library function names shall not be redefined or
undefined
115 (req): Standard library names shall not be reused
116 (req): All libraries used in production code shall be written to comply with the provisions of
"MISRA Guidelines for the use of the C language in vehicle based software", and shall
have been subject to appropriate validation
117 (req): The validity of values passed to library functions shall be checked
118 (req): Dynamic heap memory allocation shall not be used
119 (req): The error indicator errno shall not be used
120 (req): The macro offsetof, in library , shall not be used
121 (req): and the setlocale function shall not be used
122 (req): The setjmp macro and the longjmp function shall not be used
123 (req): The signal handling facilities of shall not be used
124 (req): The input/output library shall not be used in production code
125 (req): The library functions atof, atoi and atol from library shall not be used
126 (req): The library functions abort, exit, getenv and system from library shall not be
used
127 (req): The time handling functions of library shall not be used
Important questions
1. What is linker , input files to linker
2. What is interrupt
3. difference between interrupt and function
4. Can we define the variable storage location?
5. what is multiplexer speed
6. design an surviellance system
7. can multiplexer o/p can be i/p
8. SPI
9. Synchronous and asynchronous communication
10. what do you minimize runtime
11.do you use nested interrupts
12. How do u design stack
13. what is stored in stack
14. control the automobile headlights schematics
15. types of motors
16. types of dc motors
17. which sensors you used in project
18. what is PWM
19.do while syntax
20. While syntax
21. interrupt syntax
22. types of interrupts
23.compiler
24.can we control variable storage
25. what is negative and positive testing
26. different types of models waterfall/spiral/v&v
27.what is ram & rom size of lpc2148
28.close loop and open loop?
Subscribe to:
Posts (Atom)