what the function of command "delay", and why it important?

hello…

can i know why the command"delay" is very important and it is needed in the code of arduino?

exmaple

Serial.begin(9600)
delay(1000)

It is not.

In this case, it is just to let the serial port initialize and get prepared to send and receive data. If you send data right after the Serial.begin(), you might lose some bits. A delay of 1000 milliseconds (1 second!) seems excessive in this case. For an external serially controlled LCD, you often need to wait about 1/2 second for it to be ready to accept commands.

The delay function is just that, a delay. For example, if I wanted to flash an LED, I would write the code:

digitalWrite(ledPin, HIGH); delay(1000); // this would pause the arduino for 1 second digitalWrite(ledPin, LOW); dealy(500); // this would pause the arduino for 1/2 of a second

Happy Programming! - calm8809

if without delay, whether the arduino will stuck? or busy?

Try it.

As I said, the worst that will happen is that you will miss some data. Which could be very bad.

A couple of things to keep in mind with the delay() function.

It blocks so while it is delaying nothing else can happen.

If you have a delay(1000) or more you should probably rethink your code. It should only be used for very brief delays, even one second is a long time.

Jimmy60: A couple of things to keep in mind with the delay() function.

It blocks so while it is delaying nothing else can happen.

If you have a delay(1000) or more you should probably rethink your code. It should only be used for very brief delays, even one second is a long time.

A corner case where long delays like that are useful are intentionally trying to slow things down to demonstrate what is happening. The demo software for lidur's phi panels does this. One could also leverage slowing things down (as long as timing and/or counting millis/micros isn't important) for troubleshooting.

But generally, no. Delay isn't that important. One should attempt to avoid it even when trying to synchronize to asynchronous events (like waiting for external devices to be ready) and use some sort of bi-directional communication if possible. A busy loop doing nothing but watching for a pin to change state is less prone to faults than a delay with an estimated time.