how exactly are the interrupts get served in the real time embedded products like a washing machine,refrigirator?
is it like, we will write a program where we continuously check a particular status bit of the device has been set or not...or those interrupts will be hard wired to a interrupt pin (INT pin kind of)??
if it is hard wired how a variety of divices are connected to that particular pin and how exactly the interrupt by a particular device get serviced??
Different developers will use different strategies.
Modern microcontrollers have a very rich set of peripherals built in, and the trend is toward each peripheral having its own vectored interrupt, often with more than one general purpose IO pin sourcing unique interrupts also.
In operation, each one of these interrupt sources is serviced by its own interrupt service routine.
What makes you think a refrigerator or washing machine even uses any type of interrupt at all? What devices would NEED to be interrupt driven in such a usage? What do you think is happening in your fridge that is so transient/fast that a simple polling loop wouldn't suffice? What is going on in your fridge that would even require an MCU? Mine gets along just fine with a simple mechanical thermostat and a switch that (I think, I'm not really sure, it might stay on all the time.....) turns off the light when the door is closed. Same questions about your washer. These are things that need to be answered before I would go about asking particulars about hardware implementation. Running late on your homework? You must define the domain of the problem BEFORE you ask for an answer.
When the micro code has finished executing the previous instruction, the microcode checks if any interrupt requests are active.
If not, the operation code pointed by the program counter is fetched, decoded and executed.
However, if some interrupt is set, the micro code will save the context (typically the program counter and some registers) on the stack and then fetch an address from a known address (in the interrupt vector) and load it into the program counter. After that, the micro code will proceed normally.
Microprocessors are insinuating themselves even into wash machines and dishwashers. Soon all the old farts in the world will have to live in special homes with resident 13-year olds to program all their appliances, not just their VCRs.
Oh dear. Poor users. Does it have the operating system, too?
It loos more that the things are going into the opposite direction: only the old farts can fix gadgets and vigets of young suckers who haven't got a slightest clue.
Vladimir Vassilevsky DSP and Mixed Signal Design Consultant
A simple state machine, run some moderate number of times per second, can check all input and output levels and decide what to do. It may be run by a periodic interrupt, or it may just pace itself with a wait loop. Interrupts from hardware inputs, like pushbuttons maybe, are often more trouble than simple polling from within a state machine.
And proper periodic polling can give you debouncing for free.
That is for big appliance micro processors like 2K. Seriously the code I see is in two categories 1970's spaghetti and some very clever well though out tightly implemented application code.
Both are what ever ROM size the appliance has the latter very functional fault tolerant and reliable.
We are seeing increasing amounts of event driven code. Similar in design to state machines but very small event initiated execution fragments that always run to completion. These are a compromise in timing. The code can be shorter and require less RAM but the response time will be longer. As long as the response time meets the system requirements it is a big win.
Regards
-- Walter Banks Byte Craft Limited Tel. (519) 888-6911
For getting something done right away, I agree that polling is simpler to write, debug and assure it works. But I'm still old enough to remember when CPU cycles were "precious" and not to be wasted polling for things that mostly don't occur.
Deep down I prefer interrupts but they're trickier to handle properly due to possible concurrency among data structures. And interrupts allow for power saving techniques such as using slower clock rates, sleep or suspend modes.
stopping until there is required switch input.The microcontroller i am using is Atmega2560.
I did this using 2 timer/counter interrupts TIMER/COUNTER1 AND TIMER/COUNTER3.The LED is blinking continuously and the timer 3 interrupt is not getting called.
#include #include #include /* This putchar works with the M2560 UART0. It will work with other devices
if their UART registers use the same names. If the UART IO locations * are different from the M2560, then you will also have to change the * #include header file statement. * * For device with multiple UARTs and if you want to use a different UART,
change the IO register names as appropriate. */ extern int _textmode; int putchar(char c) { if (_textmode && c == '\n') putchar('\r'); /* Wait for empty transmit buffer */ while ( !(UCSR0A & (1 1) & 1) #define SW2() ((PIND >> 2) & 1) #define SW3() ((PIND >> 3) & 1) #define SW4() ((PIND >> 4) & 1) #define SW5() ((PIND >> 5) & 1) #define SW6() ((PIND >> 6) & 1) #define SW7() ((PIND >> 7) & 1)
//call this routine to initialize all peripherals void init_devices(void) { //stop errant interrupts until set up CLI(); //disable all interrupts XMCRA = 0x00; //external memory XMCRB = 0x00; //external memory port_init(); uart0_init();
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.