There is a 128 byte buffer. It is a circular buffer, so when you remove a byte with Serial.read(), that opens up a place for another incoming byte. Data that arrives when the buffer is full is lost.
The 128 byte buffer is for receive only; there is no buffer for transmit (and as a result, a call to Serial.print() takes about N milliseconds for N characters at 9600bps...)
There is at least one person who extended the buffer to 1024 bytes. Would that be enough for you? See http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1255815785/10#10 for details and warnings if you want to increase your buffer to that size or even beyond that.
If you are just waiting in a delay() line of code, you can take a look at the Blink Without Delay example, which will let you collect the serial input while you would otherwise just be waiting around for the next loop.
Other than that, if you are able to control the software that sends the serial data, you could set up a handshaking protocol whereby the sending software waits for a signal from the Arduino. When the Arduino sends a control signal to the PC, then the PC can begin to send the large amount of data to the Arduino.
Here is an outline for a small handshake protocol. There is no error checking in this example, so be careful.
PC side:
Start your application, but do not send any serial data yet.
Wait to receive the letter 'A' from the Arduino.
Send about 120 bytes over serial.
Send the letter 'B' to the Arduino to show that you are waiting to receive the "go ahead" signal (the letter 'A') from the Arduino. If there is no more data to send in this batch, send the letter 'C' instead of 'B'.
Go back to step 2 and wait for the Arduino to tell you it is Ok to start sending the next part of this batch.
Arduino side:
Send the letter 'A' to the PC. This is the "go ahead" signal that says the Arduino is ready to receive data.
Use Serial.available() and Serial.read() to read data until you receive the letter 'B'. That is the signal that the PC is now waiting. If you received the letter 'C', all data has been sent, so continue at step 5.
Put the data received so far in EEPROM, variables, etc. as you do now.
Go back to step 1.
All data has now been received, so continue with the code that does your LEDs etc.
The letters 'A', 'B', and 'C' are just suggestions. If your data already contains those letters, you will have to choose some other bytes for signals.
This outline can be extended, but you should understand this much at least before you go any farther.
there is no buffer for transmit (and as a result, a call to Serial.print() takes about N milliseconds for N characters at 9600bps
There's a 1-byte hardware buffer. So, if you use write() to send data one byte at a time, instead of print(), your code can go off and do other things while the buffer is emptying. This is not the case for the "software serial" library, though: the CPU is intimately involved in sending every bit, so people occasionally get surprised when something that was working okay on the hardware serial port fails using the software serial library.
I believe someone has come up with an improved hardware serial library that does transmit buffering. I'm certain that someone posted here that they were going to try, and I'm pretty sure that there was a follow-up later announcing success.
i want to send about 10kbytes to atmega, and atmega to store them to an eeprom.
Good luck with that, my experiments with writing to external I2C EEPROMS (the internal is only 1 K), using the ubiquitous Wire library, suggested it wouldn't write more than a few hundred bytes a minute. Reading was a lot faster.......
