2

My understanding has been that the Serial transmission is indeed done (on the Arduino Uno) via the pins named TX->1 and RX<-0? With this I assume that the Atmega has a machine code that would allow in 1 or processor cycles (125 or 62.5 ns) to set a byte (i.e. Port byte DDRD) as to forward exactly one bit of information for further processing to the ATmega16U2 "serial to USB" chip?

If this is true I would expect that 1 Byte = being 8 bits would require a discouragingly slow 8 to 12 cpu cycles (500ns to 1us)? Is this true?

1
  • If 16 megabit is discouragingly slow then you are in for a big disappointment. The default serial setting is 9600 baud, and the normal max is 115200. Commented Sep 12, 2015 at 19:16

2 Answers 2

6

No, it is not true.

You are assuming (wrongly) that the CPU is doing the UART communication. It isn't.

The UART is a completely separate piece of hardware inside the chip. It runs by itself. The CPU merely places the byte to transfer into a special function register (SFR). The UART then takes that and clocks it out through the IO pins at the right rate for the serial communication. While that is going on the CPU is free to perform other operations.

The CPU can then either consult another SFR to determine if the transmission has finished, or utilize an interrupt that the UART will trigger when the transfer has been completed.

5
  • great, any change that would allow to make any reasonable guess how many bytes can be writen in a processor cycle? Also was it another wrong idea that the DDRD would have bits related to the tx/rx see arduino.cc/en/Reference/PortManipulation? maybe you would be able to extent your else already helpful answer, thank you! Commented Sep 12, 2015 at 17:54
  • The number of bytes you can write per second depends entirely on the baud rate the UART is running at.
    – Majenko
    Commented Sep 12, 2015 at 17:56
  • Given the Arduino Uno (I am unsure if the revision is of importance), would you know what would the UART be? Also I think that the data must be somewhere indicated to the UART by the Atmega328, which runs at 16Mhz, I thought it was unable to tell more than 16 million times a second something to the UART, which then could have baud rates higher than what could be indicated by the Atmega328 on the Uno, right? Commented Sep 12, 2015 at 18:04
  • The UART has a baud rate that is dictated by the 16MHz clock. Read the ATMega328P datasheet to find out all about the UART. The baud rate is a tiny fraction of the 16MHz clock rate - typically measured in the KHz range.
    – Majenko
    Commented Sep 12, 2015 at 18:21
  • maybe indeed my assumption was wrong to the point that I did not explicitly refer to the UART chip doing the eventual sending out of data. I assume anyway I was quite rightly assuming that the Arduino Uno's 328 yet has to bring the data to this UART chip. To what I can understand this is done via the TX RX pins linked to the 16U2 UART, hence the questions reasoning was somewhat right assuming that the it takes at least 8 CPU cycles to send 1 Byte, only that some 6 or 7 out of those 8 the Atmega can do whatever else and is not doing a read of RAM to that SFR. Commented Sep 14, 2015 at 6:07
1

According to the datasheet:

Baud rates at 16 MHz

Running at 16 MHz (as the Uno does) you can get up to 2 Mbps.

If this is true I would expect that 1 Byte = being 8 bits would require a discouragingly slow 8 to 12 cpu cycles (500ns to 1us)? Is this true?

For a bit or a byte? At 2 Mbps that is a bit every 8 clock cycles.

would you know what would the UART be?

The UART is built into the processor chip. I suggest you read the datasheet.

I thought it was unable to tell more than 16 million times a second something to the UART, which then could have baud rates higher than what could be indicated by the Atmega328 on the Uno, right?

You can't do anything more than 16 million times a second at 16 MHz. And the clocking out of bits (in SPI, serial, or I2C) itself requires clock cycles, although they are done in parallel with the processor instructions by the hardware.


This is related to your other thread Can Arduino Uno's serial handle to foward push through 1-wire protocol? isn't it? Your end objective, I am guessing, is to try to implement 1-wire reading/writing via sending each bit via serial. This is just not the right way to achieve that objective.

In fact this thread in particular is coming across as an X-Y problem - your stated objective of wanting high-speed serial, is not really the problem you are trying to solve, is it?

5
  • you tell it right Nick, indeed the quesiton was in line with the other inquiry about implementing a firmata/bitflash type of protocol related to pass on 1-wire data. As @Majenko pointed out, in addition to my own calculations the time requirements are at best hardly matched. I thank you for your answer, I liked it and maybe can inquire that if the I had another UART chip than the Arduino Uno's Atmega16U2-MU which worked at a higher at say 32Mhz I had changes to Serial sent more than one byte per cycle of the Atmega328P, did I get that right? Commented Sep 13, 2015 at 7:07
  • 1
    if I had another UART chip - no, because you need to communicate with this chip somehow. The fastest method would be SPI which can send one byte every 16 clock cycles.
    – Nick Gammon
    Commented Sep 13, 2015 at 20:53
  • communicate with the chip somehow As suggested in the answer from @Majenko there would be a SFR in which the Atmega328 but the 8 bits (complete 1 Byte). It seems that such a step would be atomic 1 or 2 Atmega328 cycles. So is the "fastest communication rate" between the Atmega328 and the Atmega16U2 the 1 byte each 16 clocks? Commented Sep 14, 2015 at 5:38
  • Most of the "store" instructions are two clock cycles, so yes, it would take two clocks to load up the UART register, so it can start sending. Then, remember, that serial has a start and stop bit, so that is 10 bits per byte, not 8. I'm not sure if the Atmega16U2 will support 2 Mbps rate when communicating with the Atmega328, but even if it did, it takes more than zero clock cycles to then send this data in/out the USB port. I think you are flogging a dead horse here.
    – Nick Gammon
    Commented Sep 14, 2015 at 5:49
  • I have already ordered for a black beagle bone. It combines in one device what I wanted to achieve via a "Arduino extended BananaPi". I simply could learn from your answer and comment and hence revisited and thought. thank you Commented Sep 14, 2015 at 6:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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