500GB optical disc

This can make your movie library storage and backup woes history. The new technology of Micro-Holographic disc's promises to store upto 500GB of data on a single disc making it almost unbeatable in terms of storage capacity.

The disc unveiled by GE ( General Electric) concentrates on volume storage rather than surface storage ( I do not understand the former very well!!). Normal CD's and DVD's store the information on the surface of the disc via a set of 0's and 1's that get etched over its surface ( etched by use of a Lazer that changes the dye properties creating what are known as pits). Using the presence and absense of pits, which can be determined by a lens - lazer beam combination (based on the refected light into the lens) the CD-Rom drive is able to read the data on the disc.

GE believes that the technology will take a few years before it really can come as a off-the-shelf product. However, when it does i am sure it will change the way we store our data.


Wanna
add your point or provide more info ? Please leave your comment. You
can subscribe to this blog by using the links under "Subscribe" section.

Powered by ScribeFire.

Lets do a Ctrl Alt Del

I had written about interrupts in the post here. This post is specifically about a particular interrupt which in most cases in Non-Maskable. The word Non-Maskable tells us that come what may the µC software will not be able to avoid it. This special interrupt i am talking about is "Reset".
Is Reset an Interrupt?

It is technically an interrupt however, some people feel that it is a microcontroller state. This is because when the µC is in Reset it really cannot do anything useful because the code will not be executed. However, we state it is as an interrupt because of the following reasons perhaps

• There is a place for the Reset in the Interrupt Vector Table(IVR)
• There are different reasons for reset to occur and in some µC's all the reasons cause the code to branch to the above mentioned vector.

What are the different types of Interrupts?

The most commonly known is the Power-On-Reset (POR) as it is commonly known in the embedded world. Note that just by applying power it is really not gaurenteed that the micro controller is undergoing a RESET. This is a very common mis-understanding that if we just apply power for the first time the micro will be under going a POR. For a µC to really under a proper reset it is needed that RESET pin is correctly handled. This is done via a reset circuit which looks like this. Note that this is for a 8051 micro which for some reason is RST high, compared to the conventional micro controllers where this is active low.
The other type which happens very frequently if you are a bad programmer like me is the Running reset. A running reset can be caused by many different sources. These include Watchdog reset, Illegal opcode reset, Illegal memory access reset and finally software reset. Each of these will be discussed in greater detail in the coming posts. As of now it is sufficient to know that this occurs because of something bad that has been caused in our software or in some cases we intentionally did it ( because we feel the best way is that way!!). In both cases the CPU starts from the Reset vector and starts executing code ( Except for in higher end 32 bit micro's where Reset vector is not the only criteria!!). Of course it is also useful to note that some µC's provide various vectors for WDT reset, Illegal opcode reset (PowerPC from Freescale is an good example).
Reset handling is a tricky issue for the hardware designers and not so much for the software guys. In coming posts, I will talk about some of the issues i have observed.

Wanna add your point or provide more info ? Please leave your comment. You can subscribe to this blog by using the links under "Subscribe" section.

ISR - Interrupt Service Routine

When i was in college i always wondered how my mouse clicks where recorded by winamp while it was actually busy playing music.
Only later during my second year in Engineering did i come to know about interrupts. This post is basically a quick and short intro to ISR's.

Interrupts are hardware or software generated events that get registered with the µC/ µP. So when i click my on my mouse, the hardware event generates a signal that goes and gets registered with the processor.
( Note: Actually this process is far more complicated since the interrupt passes through a Interrupt controller etc)

Once it is registered / recognized by the CPU, it then depends on the CPU is configuration whether the interrupt will be processed immediately or will it be kept pending. Processing or servicing of in interrupt is done by saving the current state of the µC and then executing the ISR. The fuzzy word here is current state. It is fuzzy because current state can mean different things in different situations. However, at minimum we know that we would need to save the address of the instrucution which we are currently executing so that after the ISR servicing we can return back to this point.

In real world situations, there can be many events that occur concurrently.

E.g. -> You can right click on the mouse while pressing a key on the keyboard.

How does the CPU handle it all?

The CPU handles this by using an on-chip  or off-chip peripheral unit called the Interrupt Controller. The Interrupt controller is capable of providing priorities to various interrupt sources.

E.g. -> In a Heater control system, the overtemperature event takes higher priority when compared to the User input event.

Apart from Handling the priorities of various interrupt sources, it also ensures that some of the events are masked. E.g you dont want an interrupt to bother you when you are doing some highly critical computation.
In many µC's the interrupt controller is on-chip. Usually, the software during the intialization of the system configures the interrupt controller so that it can prioritize the interrupts etc. In some controller dynamic priority is not available.

E.g. -> A watchdog Interrupt will always take higher priority than a timer interrupt.

So where is the ISR here?

The ISR is a set of instructions that the CPU executes when i detects and acknowledges a said interrupt. The Key word is acknowledges, because in some cases even though the interrupt is detected it will not be acknowledged.

E.g  ->while windows is booting up it might not want to acknowledge any mouse clicks.

At the end of the ISR (i.e the code in the ISR), the CPU returns back to the point where it has broken off to execute the ISR. Note that based on micro-controller architectures this will have differing behaviours when more than one interrupts are in pending state.

The concept of interrupts is very essential and is widely used in almost all embedded applications. Hence, a sound understanding of this concept is essential for anyone who wants to do some kind of embedded programming.


Wanna add your point or provide more info ? Please leave your comment. You can subscribe to this blog by using the links under "Subscribe" section.

ILS - Intelligent Light System

MERCEDES Intelligent Light System

This is real technology. The Intelligent light system from Mercedes. The ILS has a lot of features which include

• Country mode driving
• High Intensity fog lamps
• AutoBahn mode for going on freeways
• Automatic adjustment and correction for the headlight so that even on bad road conditions best illumination is provided. 
• Cornering lights

From what i gather from various websites and people aware of this technology is what i am putting here. All of it might not be fully correct and complete.

Well so much for the disclaimer part :-).

The AutoBahn mode has a very important feature that increases the output of the Xenon Headlamps based on the speed. This means that you get better road visibility ( up to 120 m). Also the Light cone is designed in such a way that it doesn't blind the traffic coming from the opposite lane.

The cornering lights use the Steering angle and the indicators as in input, along with the direction in which the vehicle is moving to calculate the angle by which the headlamps need to be swivelled to ensure that the corners of the road are illuminated. Basically, in simple terms the light beam is kept parallel to the tyres of the vehicle rather than the body ( as in conventional systems).

This is done by having a clever set of actuators which control the light beam by moving the light bulb as well as lens in from of the xenon bulb to accurately reposition the beam. A horde of sensor inputs coming from the steering angle sensor, vehicle speed and the camera mounted on the windscreen help the control algorithm to readjust the light beam and position it accurately.

Of course, cool technologies come at a cool price and the same is true for this system which is available only on the high end Mercedes cars including the new E-classes.

Ref: articles here  [1]   [2]    

Simulate Emulate and Debug....

Here i try to talk about a widely misunderstood topic. It is about Emulators, Simulators and Debuggers.

For starters, these three are different things and have different ways of operation and capabilities but have a common intent. Helping the embedded developer, develop his software in a more robust way with lesser number of bugs.

Lets start with the most common one, Simulator. A simulator is a software that runs on the host pc ( Your personal computer), and is able to mimic some/all of the behavior of micro controller. I use the term µC because that is what we will be dealing more in the future posts. However, this is equally applicable to the µC too. Some/all is in bold because simulators often cannot mimic all the functionalities that can occur in the real hardware. Some of the very good simulators i have seen are the AVR simulators. This should be available to you if you download AVR studio which i discussed in my earlier post here.

Next is a Debugger. A debugger is a device ( Typically an external peice of hardware connected to your PC via a serial link like USB) which talks to your µC and provides information to the host PC which is displayed in some kind of a debugging environment. Often the external hardware debugger is accompanied with a PC envirnonment to debug it and people confuse this environment to be the debugger. Unfortunately, that is incorrect. E.g of Debuggers 

• Nec Mini Cube with IEQB850 as the debugging environment
• ATMEL -ICE with AVR studio as the debugging environment.

Technically speaking, if you are a great PC prorgammer, then it should be possible for you to create your own debugging environment which talks to the hardware debugger and displays relavent information on your screen.
It should be obvious that to really use a debugger u needed a µC to which you can talk to. Without having a µC ( often called Target), there is not much you can do with a debugger.


Finally we have the Emulator. This is where everyone gets confused. An Emulator emulates the functionality of the µC. This means that the real µC is not present in the system. This is in contrast with the Debugger which requires an external µC to really talk to. Since, the Emulator emulates the functionality of the µC, there is no need for an extra µC. The question now arises why do we need an Emulator at all if we have a debugger? Why take pains to emulate the functionality of the micro when we already have it available?

Answer

• Often the real micro controller will be in developmental stages, while companies still want to use them. So Micro vendors like NEC come up with Emulators.
• Emulators can have more debugging capabilities compared to the real µC.
• Since, the Emulator is emulating the µC, it can be reconfigured via different means ( we will discuss this else where) to emulate more than one type of µC ( of course, not at the same time!!).

Eg: Nec IE-CUBE is a emulator for NEC V850 micro controllers

Costwise, typically simulators are cheap, Debuggers are costly and Emulators are very costly. Also, for debuggers to exist the µC should provide some kind of debug interface ( remember the debugger needs to talk to the micro!!). We will talk about debug interfaces in one of the future posts.

I hope this post helps people to lose some myths about the three components.

Wanna add your point or provide additional info ? Please leave your comment. You can subscribe to this blog by using the links under "Subscribe" section.

ISR - Interrupt Service Routine

When i was in college i always wondered how my mouse clicks where recorded by winamp while it was actually busy playing music.
Only later during my second year in Engineering did i come to know about interrupts. This post is basically a quick and short intro to ISR's.

Interrupts are hardware or software generated events that get registered with the µC/ µP. So when i click my on my mouse, the hardware event generates a signal that goes and gets registered with the processor.
( Note: Actually this process is far more complicated since the interrupt passes through a Interrupt controller etc)

Once it is registered / recognized by the CPU, it then depends on the CPU is configuration whether the interrupt will be processed immediately or will it be kept pending. Processing or servicing of in interrupt is done by saving the current state of the µC and then executing the ISR. The fuzzy word here is current state. It is fuzzy because current state can mean different things in different situations. However, at minimum we know that we would need to save the address of the instrucution which we are currently executing so that after the ISR servicing we can return back to this point.

In real world situations, there can be many events that occur concurrently.

E.g. -> You can right click on the mouse while pressing a key on the keyboard.

How does the CPU handle it all?

The CPU handles this by using an on-chip  or off-chip peripheral unit called the Interrupt Controller. The Interrupt controller is capable of providing priorities to various interrupt sources.

E.g. -> In a Heater control system, the overtemperature event takes higher priority when compared to the User input event.

Apart from Handling the priorities of various interrupt sources, it also ensures that some of the events are masked. E.g you dont want an interrupt to bother you when you are doing some highly critical computation.
In many µC's the interrupt controller is on-chip. Usually, the software during the intialization of the system configures the interrupt controller so that it can prioritize the interrupts etc. In some controller dynamic priority is not available.

E.g. -> A watchdog Interrupt will always take higher priority than a timer interrupt.

So where is the ISR here?

The ISR is a set of instructions that the CPU executes when i detects and acknowledges a said interrupt. The Key word is acknowledges, because in some cases even though the interrupt is detected it will not be acknowledged.

E.g  ->while windows is booting up it might not want to acknowledge any mouse clicks.

At the end of the ISR (i.e the code in the ISR), the CPU returns back to the point where it has broken off to execute the ISR. Note that based on micro-controller architectures this will have differing behaviours when more than one interrupts are in pending state.

The concept of interrupts is very essential and is widely used in almost all embedded applications. Hence, a sound understanding of this concept is essential for anyone who wants to do some kind of embedded programming.



Wanna add your point or provide more info ? Please leave your comment. You can subscribe to this blog by using the links under "Subscribe" section.

µC and µP

Often i have been asked to by people what is a microcontroller (µC) and how it is different from a microprocessor. In this post i will try to put some facts and let the reader decide how he would like to distinguish between the two.

For starters, both the µC and the µP are computational machines which are capable of doing complicated computations. The fuzzy word here is complicated, because what is complicated in one scenario might not be valid for other.

E.g. Then AMD processor on my home computer has to do a lot of computations when i do video conversion operations or run some matlab simulations. This however can be handled fairly well with the AMD. Trying to do this with a 486  is a foolsish proposition.

So what are the differences ?

• A µP contains more features which are meant for providing very high number crunching capablility and the peripheral units inside the µP are aimed at providing high speed data access and interfacing with other "ON board" chips.
• A µC contains a core ( for computational purposes) and peripheral units which are meant to provide a lot of I/O capablilites. These include Analog to digital converters, Ports for PWM generation, Ports for discrete outputs and Inputs etc.
• µC's generally contain a lot of on chip RAM, EEPROM and FLASH. FLASH and EEPROM are generally not found on a µC. However, µC's contain things like Barrel shifters, MMU's and typically a lot of cache memory.
• Talking about sheer computational speeds again the µC and µP have different set of speeds based on the application's for which they are targetted. There are µP's that run at 8MHz and those which run at more than 250MHz.
  
• Based on their intended application µP and µC's have a lot of communication interfaces ( CAN, SPI etc are common for automotive micro's, while USB is common in micro's for consumer electronics. Ethernet is almost a must for all networking microcontrollers).

Also one thing which you might not hear so often is the term "Reflashing" when it comes to µP's. This is because most of the µP's load run their software from the cache memory, which in turn is loaded from RAM ( usually DDR RAM in case of PC's. Now you know why more RAM equates to a better PC).

µP or µC both have very similar underlying concepts. It is only the usage and the cost that really drives what we use to solve a given problem.

Wanna add your point or debate? Please leave your comment. You can subscribe to this blog by using the links under "Subscribe" section.

C for embedded systems

This is for those who are completely new to programming micro controllers. using C language Here i try to give a head start to such people.

1. First choose a platform to work on. I suggest going for the AVR. AVR microcontrollers are relatively cheap and a fairly powerful. The best part however, is that you can test a multitude of the microcontrollers'' features using just the simulator provided in the IDE. You can download it from here free of cost after a small registration.
2. Now you have to download a compiler. Please note that IDE is different from compiler. I have seen this misconception very strong among freshers who have used Turbo C compiler for a long time. A compiler is more often than not a command line utility. IDE ( Integrated Development Environment) help us by managing the files and abstracting from us complex commandline arguments that are needed to compile your code. Download WINAVR.
3. Please install WINAVR first and then AVRStudio. This will ensure that AVRStudio automatically picks up the WINAVR path.
4. Use the GUI to guide you and create a simple project. There are many samples available. However, the wizard is very helpful. You can choose any microcontroller to start with. 
5. create a simple file with just the following code

int main(void)
{
     int i =0;
     int j = 5;
     i = i + j + 100;
     return 0;
}

 
[ compile the code (F7) after saving the file as anyname.c]

There you are done with your first C program for an embedded microcontroller. You will have to set the target as AVR simulator for debugging and stepping through your code.

I will not put more stuff here since that will take away the fun part from you.

What can you do?

• Try to write a program to add two number and store the output in a global variable.
• Other simple C programs without any printf or scanf statments.
  

Just one note, It is not really true to say the printf is a part of "C". Technically speaking pure "C" is the one in which there is no # include statement. When we say #include what we are doing is adding in libraries. Note that Libraries are not a part of "C", these are what users write. I dont know if i make full sense here :-S

In later posts i will try to explain the significance of #include in embedded code.

Please leave your comment. You can subscribe to this blog by using the links under "Subscribe" section.
 

Wow Effect

Finally I got my bike, the brand new shiny XCD 135. I still am new to it so my riding is extremely shaky. However, When i turned the key i got a cool effect in the console or more commonly called the cluster. The effect is called "The Wow Effect". This effect is nothing but sweeping of the needle in the meters from their rest position to their max and back in Jiffy.

These days instument clusters in two wheelers also have become extremely clever and show a whole bunch information. For a very long time the IC ( Instument cluster), was a fully mechanical device ( in two wheelers) with speed and RPM info coming to the IC via a rotating wire. The current clusters show efficiency, DTE ( Distance to Empty), Average speed, Trip info , RPM and speed information; To do all this they use complex electronics and a bevy of sensors which get them all the info.

Though the IC seems to be a very simple device, it holds fairly complex embedded software and hardware concepts.

I hope to see more interesting clusters in two wheelers in coming days...with much more information and bigger LCD displays

Please leave your comment. You can subscribe to this blog by using the links under "Subscribe" section.

Automotive ECU

About a couple of decades back there where very few cars plying on the Indian roads which had ECU's in them. This post provides a brief insight on these small units which crunch a horde of signals to make our vehicle smoother, faster and more efficient.

The Term ECU stands for Electronic Control Unit. The key terms here are Electronic and Control.

Electronic - This means the device is an electronic component. Typically, a ECU contains a Control Unit and more often than not it is a micro-controller (µC). However, in some modern vehicles ASIC and FPGA based solutions are also available. Apart from the µC there are  tons of peripheral hardware blocks which constitute to make the ECU's electronic hardware components.

Control  - This word describes the functionality of the ECU. It is often meant to control something. However, this is not always the case, but the term still seems to hold because of legacy reasons. In the vehicle one can classify the EU ( Electronic Units as i would call them) broadly into two categories.

1. Control Units - These control some functionality of the vehicle. E.g. Control the fuel going into your cylinders based on how much you push the gas pedal.
2. Information & Entertainment Units - These units provide vehicle information to the driver and also entertain the drivers. E.g. Navigation units, Car radio and Driver information system ( You can find one on the Mahindra Xylo)

On a after thought, I think we have one more category and this is a fairly new category. These are systems that help to interface different ECU's. E.g MOST-CAN gateway which is very common in high end cars.

There are lot of terms in this article which maybe jargon's for all newbies. However, I shall try to cover most of these Jargon's in future articles.

Coming back to the ECU...These days vehicles have as many as 90-100 ECU's (high-end) and about 8-9 (in mid and low end). The Tata Nano for example has a EMS which control's fuel and spark and ensures that the engine runs smoothly even under varing load conditions.

In the coming days, there will be more posts under automotive electronics (which is my area) and general embedded systems ( which some of my friends may add in!!).

Please leave your comment if you have one. You can subscribe to this blog by using the links under "Subscribe" section.

Welcome

Hello,
This is going to be perhaps the only post that is going to be boring on Electronica. This blog is finally happening after i spent a lot of time here writing about a whole lot of things, and concluded that i needed another blog where i can write specifically about electronics and embedded systems.

When i was at school and then further at college I always liked to tinker around with things and try to figure out how they worked. Unfortunately, not many people liked my opening up torches, watches and almost everything that had some electronics in it. Neither was there anyone in my family qualified enough to distinguish a LED from a Bulb. It was only after i started going to the electronic-circuits lab at my college in Manipal did i get to have tete-a-tete with the world of electronics.

I am grateful to the organisations where i have spent time in the past few years for all the knowledge i have gained from there about embedded systems and a lot of other not so embedded things :-).

I would try to keep updating this blog as frequently as possible and would try to bridge the gaps that a student of electronics finds between theory and real practical world through the article here...For hard core techies, there might be something good or useful which might help in times of peril

Hope you have a nice time reading....

Please leave your comment if you have one. You can subscribe to this blog by using the links under "Subscribe to Electronica" section.