Dlaczego Serial.write () jest wolniejszy niż memcpy ()?

Jeśli przyjrzysz się implementacji:

 size_t HardwareSerial::write(uint8_t c) { _written = true; // If the buffer and the data register is empty, just write the byte // to the data register and be done. This shortcut helps // significantly improve the effective datarate at high (> // 500kbit/s) bitrates, where interrupt overhead becomes a slowdown. if (_tx_buffer_head == _tx_buffer_tail && bit_is_set(*_ucsra, UDRE0)) { // If TXC is cleared before writing UDR and the previous byte // completes before writing to UDR, TXC will be set but a byte // is still being transmitted causing flush() to return too soon. // So writing UDR must happen first. // Writing UDR and clearing TC must be done atomically, otherwise // interrupts might delay the TXC clear so the byte written to UDR // is transmitted (setting TXC) before clearing TXC. Then TXC will // be cleared when no bytes are left, causing flush() to hang ATOMIC_BLOCK(ATOMIC_RESTORESTATE) { *_udr = c; #ifdef MPCM0 *_ucsra = ((*_ucsra) & ((1 << U2X0) | (1 << MPCM0))) | (1 << TXC0); #else *_ucsra = ((*_ucsra) & ((1 << U2X0) | (1 << TXC0))); #endif } return 1; } tx_buffer_index_t i = (_tx_buffer_head + 1) % SERIAL_TX_BUFFER_SIZE; // If the output buffer is full, there"s nothing for it other than to // wait for the interrupt handler to empty it a bit while (i == _tx_buffer_tail) { if (bit_is_clear(SREG, SREG_I)) { // Interrupts are disabled, so we"ll have to poll the data // register empty flag ourselves. If it is set, pretend an // interrupt has happened and call the handler to free up // space for us. if(bit_is_set(*_ucsra, UDRE0)) _tx_udr_empty_irq(); } else { // nop, the interrupt handler will free up space for us } } _tx_buffer[_tx_buffer_head] = c; // make atomic to prevent execution of ISR between setting the // head pointer and setting the interrupt flag resulting in buffer // retransmission ATOMIC_BLOCK(ATOMIC_RESTORESTATE) { _tx_buffer_head = i; sbi(*_ucsrb, UDRIE0); } return 1; }  

W zasadzie odpowiada na wszystkie pytania.

Jeśli bufor jest pusty i nic nie wysyła, wyśle znak bezpośrednio, więc jest synchroniczny (ale wysłanie znaku będzie znacznie szybsze niż narzut wywołań zwrotnych funkcji i tak dalej)

Nie, nie możesz użyć memcpy, ponieważ zastępuje on tylko bufor, ale nie robi nic innego, jak faktycznie uruchamia rejestr danych gotowy przerwanie ani właściwe ustawienie liczników head / tail (jest to okrągły bufor, więc może być scenariusz, że nadpiszesz coś poza buforem)

I funkcja write jest wywoływana dla każdego znaku osobno (wszystkie inne specjalizacje zapisu używają tego)

Również jeśli bufor jest pełny, będzie czekać, aż będzie miejsce na kolejny znak.

Kopiowanie do bufora szeregowego to nie to samo, co

, nie.

Bufor szeregowy to bufor cykliczny . Z tego powodu istnieje wiele obliczeń potrzebnych do ustalenia, gdzie dokładnie w buforze należy umieścić następny znak. To wymaga czasu. memcpy() po prostu kopiuje jeden blok pamięci bezpośrednio na inny. Nie sprawdza i nie może zawijać się jak bufor kołowy.

Przyczyną, dla której wyższe szybkości transmisji wydają się wolniejsze, jest to, że każdy znak jest pobierany z bufora przez przerwanie.Im wyższa szybkość transmisji, tym częściej to przerwanie jest wyzwalane, a więc tym więcej czasu procesor spędza na przetwarzaniu tego przerwania w celu wysłania następnego znaku. Co więcej, procesor ma mniej czasu na przetworzenie umieszczenia danych w buforze szeregowym.

Testowana funkcja to prawdopodobnie Serial.write(const uint8_t *buffer, size_t size). Jeśli szukasz go w HardwareSerial.h, zobaczysz

  using Print::write; // pull in write(str) and write(buf, size) from Print  

i implementacja jest w Print.cpp:

 /* default implementation: may be overridden */ size_t Print::write(const uint8_t *buffer, size_t size) { size_t n = 0; while (size--) { if (write(*buffer++)) n++; else break; } return n; }  

To jest zapis bajtów o jeden, a dla każdego bajtu uruchamiany jest cały kod HardwareSerial::write(uint8_t c). Obejmuje to testy pełnego lub pustego bufora oraz arytmetykę aktualizowania _tx_buffer_head.

Jak stwierdzono w komentarzu nad kodem, byłoby możliwe zastąpić to specjalną implementacją. Zasadniczo można skopiować bufor liniowy do bufora pierścieniowego, używając co najwyżej dwóch wywołań memcpy() i aktualizując _tx_buffer_head tylko raz. Byłoby to prawdopodobnie bardziej wydajne niż obecna implementacja, przynajmniej dla rozmiarów bufora z zakresu, którego używasz (blisko, ale mniej niż pojemność bufora pierścienia).

Czy byłoby warto? Może w twoim przypadku tak by się stało. Ale może również uczynić kod bardziej złożonym i wymagać więcej flashowania. A korzyść będzie prawdopodobnie bardzo mała dla osób piszących małe bufory. Nie jestem pewien, czy żądanie ściągnięcia implementujące ten rodzaj optymalizacji może zostać zaakceptowane. Możesz spróbować, jeśli masz na to ochotę.