How does a MCU work when the program is executed on it.

[Dadu@]

I don't know but it seems to me that every common microcontroller has CPU/Processor, Memory and peripherals devices such as ADC, timers, UART, SPI, I2C. When the program is executed on the microcontroller, Processor sends instructions to the peripherals as written in the program.

Suppose we have device X which takes 50 us to turn ON when 5 volt signal is received from MCU. Let's say MCU takes 1us to send 'Turn On Instructions' to device X.
Suppose a program is written to turn on the device X. MCU only waste 1 us to turn on the  device X.

Does MCU wait for 49 us to turn on device X, or can it send other instructions to device Y if written in program within 49 us?

please feel free to ask me anything and sorry for not being specific.

[mariush]

The microcontroller doesn't send "Turn on instruction"  to device X ... it sends a series of bits or bytes through the connection protocol selected (i2c , spi, whatever).  Your program has an understanding of what those bits mean, not the microcontroller or the peripheral.

The microcontroller doesn't care what happens to those bits. As soon as the bits are transferred, the peripheral is ready to transmit other bits or receive bits and if your program wants to, it will send bits through the wires.

It's the job of your program4 to wait in some way until you send more commands to the device - some devices will have a pin that's high or low when device is busy, so you would know if the device is ready to accept new commands or not , other devices will simply ignore any command coming to the device until it's fully initialized, or will respond with a error reply or a default value until it's fully initialized or while the device is busy. Some devices will have a command "are you busy" that you could use before sending commands to it.

[Siwastaja]

It's up to you as a programmer to Do The Right Thing, and that depends on the application.

Let's say, "device" is an accelerometer that requires a reset signal, which you need to keep active for 50µs. So you can write code which activates the reset, taking 1µs, and then you can just wait for 49µs, consuming CPU cycles doing nothing useful, and after that, deactivate the reset, again taking 1µs.

Or, if you can't afford waiting 49µs just doing nothing, in other words, if you have some other important thing to do which can't wait, then you can activate the reset and program a timer to generate an interrupt after 49µs, and there, in the interrupt handler, deactivate the reset. Now rest of the program can go on during the wait.

Or, maybe the microcontroller comes with a timer peripheral which can automatically create a 50µs pulse once you program it to do so.

But, in the end, you need to be more specific. There is no one general way of doing things, it depends on what you are actually doing, and what kind of devices you are communicating with.

[Ian.M]

It may be worth looking at simple CPUs for a deeper understanding of what actually *MUST* happen 'under the hood' as the only significant difference with a MCU is the greater integration, with clock generator, memory and peripherals all on the same chip as the CPU core.

As good a place to start as any is Ben Eater's 8-bit Breadboard Computer project,  where he builds the CPU from scratch on solderless breadboards out of individual LSI and MSI logic chips.

Here's the youtube playlist: https://www.youtube.com/playlist?list=PLowKtXNTBypGqImE405J2565dvjafglHU

[westfw]

Does MCU wait for 49 us to turn on device X, or can it send other instructions to device Y if written in program within 49 us?

It can do either one, and both are relatively popular.
As an example, consider the analog to digital converter (ADC) peripheral, which is typically pretty slow.  You have to give it a "start conversion" command, and it will take quite some time before the conversion has completed (let's use your 50us time example.)

There are several common strategies to deal with this:

• Send the Start command, and then sit it a loop waiting for the ADC conversion to finish.
• Send the Start command, and configure the ADC to generate an interrupt when it's finished.  Go do something else until the interrupt occurs, and handle the newly arrived value in the Interrupt.
• Send the Start command, do something else, and come back "later" to see if the conversion has finished.  You might have done other things for longer than 50us, or you might have to still wait some time when you actually need the data, but that's OK - you've still wasted less time than you would have JUST waiting.
• Set up the ADC to automatically do conversions continuously.  That way, when you go to read it, you should be able to immediately access a value that is at more 50us old.  No waiting, but slightly stale data.

You have to make a judgement call; 50us is a pretty short time compared to most mechanical motion, and a very short time compared to human responses, so the "easiest" method (just waiting) may be perfectly fine.  Arduino's "AnalogRead()" function "just waits" on most boards, and people do a lot with it.   OTOH, 50us is probably at least 1000 instructions on most modern chips, and that will start to seem wasteful if you're trying to eek out the maximum performance.

[jpanhalt]

Does MCU wait for 49 us to turn on device X, or can it send other instructions to device Y if written in program within 49 us?

Let me try to rephrase what you seem to be asking.  "Can an MCU do multiple things at the same time?"  The direct answer to your question about "waiting" is yes and no. 

That is, the MCU can simply "wait" (e.g., perform a loop* that takes 49 us).  Alternatively, the programmer can write an interrupt based on a timer or other event.  (NB: The timers either always run or can be made to run while the MCU does other stuff.)  Thus, the MCU can do other stuff during that 59 us period, and when it is interrupted, it then does the next task you defined after that wait.

Not all MCU's have interrupts.  But clearly, they are quite useful and most modern MCU's have that capability. 

*The "loop" need not be 59 us, nor must it be useless activity.  The example is intended to show only how to avoid using interrupts.