Bit rate of uart communication

Question

I have a setup which communicates between PC(windows) and Atmega2560 using UART. On PC side I am using Pyserial. From the PC I am sending a paragraph of text byte-by-byte to Atmega2560. The UART configuration is : 2400 baud rate;8 bit data;1 stop bit; No parity; The pyserial code is as follows:

string = "some sample text" strobe = serial.Serial('com3',baudrate = 2400) for x in string: strobe.write(x) sleep(0.001)

I used an Oscilloscope to check the UART signal on the RX pin of the MCU, and observed that there was a gap of 15ms between two data frames. My questions are :

1. Are the data frames in UART, transmitted successively, i.e. after a stop bit , the start bit of next frame begins?
2. If the answer to the above question is yes, then is the data transmission speed same as the baud rate?
3. In the data transmission(from PC to MCU), without the 1ms delay, the data is getting corrupted. Why is this happening?How can I transmit successfully without any delay?

Also I am sending data back from MCU to PC. When I probed the TX pin of the MCU using the Oscilloscope, there was negligible delay between data frames. I beleive that this is because I am using interrupts for transmitting on the MCU.

I am adding Atmega2560 Code here:

volatile uint16_t address; volatile char incoming; uint8_t in_buffer[2000]; void eeprom_write(uint16_t add,uint8_t val){ while(((EECR)&(0x02)) != 0);//EEPE bit cli(); EEAR = add; EEDR = val; EECR |= 0x04;//EEMPE EECR |= 0x02;//EEPE sei(); } ISR(USART0_RX_vect){ incoming = UDR0; in_buffer[address]=incoming; address++; } int main(void){ /*initialization of uart*/ address = 0; incoming = 1; while(incoming!='#'){} for(uint16_t i = 0 ;i<address;i++) eeprom_write(i,in_buffer[i]); }

The termination of data is indicated by '#'.

Answer 1

2400 baud is 240 characters (octets) per second at 10 bits per frame (which is the standard "8N1" ). Sleeping for 1 millisecond isn't going to affect spacing much, certainly not in a predictable way, because each character takes 4ms to send.

It could be that the python sleep can't do sleeps as short as 1ms,

still, if you want to monitor the data you need an oscilloscope (or connect the data line through a resistor to a sound-card input an make a recording and view it in a sound file editor - the voltage will probably fluctuate a bit but you should see the edges of each bit clearly.)

Could there be something keeping your micro-controller busy such that it can't handle 240 characters per second?