0
\$\begingroup\$

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 '#'.

\$\endgroup\$
  • 1
    \$\begingroup\$ Windows PCs and Python are not very time-efficient, that delay could simply be OS or language overhead. But why are you adding a 1ms delay? \$\endgroup\$ – Edgar Brown Nov 8 '18 at 22:28
  • 2
    \$\begingroup\$ That sounds like either (1) a coding issue on the MCU or (2) a VERY slow MCU. I nearly always use 115kbps with no issues. ~400µs between bits, >3.5ms between bytes is a glacial speed. \$\endgroup\$ – Edgar Brown Nov 8 '18 at 22:38
  • 2
    \$\begingroup\$ Use a serial terminal application? Connect Tx to Rx so you can see all transmissions? Get a bus pirate? Use a cheap logic analyzer? The oscilloscope? Without more information about what exactly do you want to "monitor" is hard to know what is the appropriate tool. \$\endgroup\$ – Edgar Brown Nov 8 '18 at 22:47
  • 3
    \$\begingroup\$ @shubhamsharma - Hi, Your comment states "how can I monitor live data rate on the PC side". What do you mean by "live data rate"? Do you mean that you have to find an unknown data rate? But no, you can't mean that, since you have already told us that it's 2400 bps. So perhaps you mean that you need to monitor the live data? But no, you can't mean that, because keep saying data rate. So please edit your question to clarify and add more details. Thanks. \$\endgroup\$ – SamGibson Nov 8 '18 at 23:33
  • 1
    \$\begingroup\$ Why do you need to monitor the "live data rate" whatever that is? I think if you modify your question to explain more stuff, maybe someone can help you. It seems like you can easily monitor the number of bytes sent or received in real time from either end. So I can't imagine what you are trying to do or why you need to do it. \$\endgroup\$ – mkeith Nov 9 '18 at 5:17
1
\$\begingroup\$

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?

\$\endgroup\$
  • 1
    \$\begingroup\$ It's not python that can't sleep for a short period of time, it's that the host OS won't typically honor such short delays - you'll get your delay, but you won't run again until the scheduler gets back to you. And then there's typically USB latency to add as well. \$\endgroup\$ – Chris Stratton Nov 9 '18 at 4:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.