Gyvercore

UART конфигурируется в четыре строчки. Нафига там целый класс рисовать? А потом сидеть ждать, когда байт на скорости 9600 улетит, хотя вместо этого можно заняться другими делами.

 

Спорить не буду - но чего-то там куда-то добавлять в чужой код это удел профессиональных программистов - а я по образованию слесарь. Поэтому мне проще и быстрее разобраться как работает интерфейс и работать с ним напрямую на C/C++ или Ассемблере, чтобы решить любую свою задачу без использования чужих велосипедов. Мне и нужно то слать байт, принимать байт, и знать когда он пришел. Мне вот эта батарея всех этих супернужных функций в своей программе зачем?

 

правило номер пять

....

правило номер двенадцать

 

Самый короткий код

Код (C++):

void UART_Transmit (uint8_t data)
{
    while (!(UCSR0A & (1 << UDRE0)));
    UDR0 = data;
}

Если отправляем по прерыванию, то проверку флага убираем (он сбрасывается сам при входе в прерывание)

А что мешает писать так, как ниже? Зачем лишние сущности в виде костыля на костыле?

Прерывание по готовности регистра данных (сам пакет ещё не передан!)

Код (C++):

ISR (USART_UDRE_vect)
{
   
}

Прерывание сразу после отправки пакета

Код (C++):

ISR (USART_TX_vect)
{
   
}

Прерывание сразу после принятия пакета

Код (C++):

ISR (USART_RX_vect)
{
   
}

 

Ну если вы под оптимальностью понимаете исключительно размер кода, то спорить не буду. Но в классе Serial есть буферизация приема и передачи, что существенно повышает эффективность работы с портом.

 

я понимаю только скорость выполнения кода. Сколько при этом будет занято флеша или ОЗУ - это всё вторично, т.к. является данностью (занимай хоть всё и вся). Но если не хватает, то ОЗУ и флеш нынче не стоят ничего. А вот перейти на более быстрый 8-ми битный проц та ещё задача. Переходить фактически не на что.

Что-то мешает организовать такой буфер вне класса? К примеру, кольцевой?

 

Ну так буфер, в большинстве случаев, повышает скорость выполнения кода.

Ничего не мешает, но зачем если он уже организован и весьма эффективно?

 

А вот первые ляпы разобраны. Жаль автор не стал смотреть всё целиком, а ограничился беглым взглядом на пару файлов. Уверен, что ляпов там ....