передача завершена - когда данные ушли по физическим линиям регистр пуст - значит, можно записать новый байт на передачу, но предыдущий еще до конца не отправился.
передатчик буфферизирован, т.е. там как бы очередь из 2 (или более) регистров, из которых "виден" программисту только первый - когда он пуст, в него можно записывать новое. а непосредственно в линию выдаются данные из самого последнего, сдвигового регистра.
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ очень важен контроль процесса заряда и разряда для избегания воздействия внешнего зарядного напряжения после достижения 100% заряда. Инженеры КОМПЭЛ подготовили список таких решений от разных производителей.
Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре.
Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.
передача завершена - когда данные ушли по физическим линиям регистр пуст - значит, можно записать новый байт на передачу, но предыдущий еще до конца не отправился.
в каких случаях нужно использовать ПЕРЕДАЧА ЗАВЕРШЕНА, а в каких РЕГИСТР ДАННЫХ ПЕРЕДАТЧИКА ПУСТ ? почему тогда просто не оставили режим РЕГИСТР ДАННЫХ ПЕРЕДАТЧИКА ПУСТ ? как я понимаю он шустрее
когда ты прочитаешь принятый байт из регистра данных, то он тоже станет пуст. а потом в прерывании по пустому регистру ты начнешь гадать, от чего он пуст - по окончании передачи или по окончании приема. лично я использую прерывание "передача завершена" и там посылаю следующий байт на передачу.
_________________ Мудрость приходит вместе с импотенцией... Когда на русском форуме переходят на Вы, в реальной жизни начинают бить морду.
в каких случаях нужно использовать ПЕРЕДАЧА ЗАВЕРШЕНА
Для управления направлением потока данных: например, для выключения передатчика или управления RS-485. Отключать передачу следует именно по факту завершения передачи последнего байта, а не по факту вычитывания его из регистра. Иначе пакет окажется обрезан сзади.
_________________ ВНИМАНИЕ! Я часто редактирую свои сообщения, поэтому перед ответом мне советую обновить страницу. За перенос модераторами в МЯВУ тем с моими сообщениями я ответственности не несу.
UBRR0 = (F_CPU + 4 * BAUD_RATE) / (8 * BAUD_RATE) - 1; // если с кварцем
UCSR0A = 1 << U2X0; // удвоение скорости обмена( предделитель уменьшается с 16 до 8)
UCSR0B = 1 << TXEN0 | // разрешение передачи 1 << TXCIE0; // разрешение прерывания по завершению передачи UCSR0C = 1 << UCSZ00 | 1 << UCSZ01 | // определение размера слова данных в 8 бит 1 << USBS0; // передатчик посылает 2 СТОП-бита }
void uart_send_char(unsigned char *ch){
while (! (UCSR0A & _BV(UDRE0)) ); // Wait for empty transmit buffer UDR0 = *ch; }
int main(void) {
UART0_Init();
sei (); // Global enable interrupts
while(1){
uart_send_char(ch);
}
}
подключил терминал
как вычислить почему в терменале нет переданных с мк данных ?
mickbell, а разве кто-то говорил, что отключать передачу надо посреди телеграммы?
Отключать передачу надо сразу же (!) после отправки последнего стоп-бита. Уточняю: по окончании передачи этого бита. Осталось понять, каким образом узнать, что этот самый момент таки случился.
как вычислить почему в терменале нет переданных с мк данных ?
Прежде всего, осциллографом посмотреть, что делается на линии TXD (со стороны МК) - RXD (со стороны компа): есть там сигнал или нет. Затем посмотреть, какова длительность передачи бита, и сравнить с заявленной скоростью, возможно, они не соответствуют. Если всё правильно, то надо подать на комп сигнал с другого источника - возможно, порт помер.
_________________ ВНИМАНИЕ! Я часто редактирую свои сообщения, поэтому перед ответом мне советую обновить страницу. За перенос модераторами в МЯВУ тем с моими сообщениями я ответственности не несу.
UCSR0B = _BV(TXEN0); // разрешение работы передачика USART UCSR0C = _BV(UCSZ01) | _BV(UCSZ00); // определение размера слова данных в 8 бит
while(1){
UDR0 = 'W'; // инициализация передачи _delay_ms(100);
}
}
Posted after 4 minutes 24 seconds: на основе приобретенных знаний написал свою ф-цию передачи данных прошу подсказать и поправить если можна это реализовать проще
if(bit_is_clear(UCSR0A,TXC0)){ // если предыдущая передача закончена p = s; UDR0 = *p; p++; enable_interrupt_when_data_register_USART_is_empty; }
}
а если предыдущая передача не закончена, что тогда? _delay_ms(1000) для надежности? и зачем тогда огород с передачей по прерываниям, если все равно ждать время?
выключаю зануду.
лично я, хоть меня и критиковали не раз за такой подход, в исключительно редких случаях реализовывал передачу по прерываниям, в основном меня всегда удовлетворяет передача по тупому ожиданию:
тем более, что подобный принцип прекрасно поддерживается системными функциями printf, использовать которые для вывода на компьютерную консоль - милое дело! и практически весь UNIX вырос из именно такого, блокирующего printf...
а вот прием чаще всего удобнее именно по прерыванию. для меня лично, конечно...
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
if(bit_is_clear(UCSR0A,TXC0)){ // если предыдущая передача закончена p = s; UDR0 = *p; p++; enable_interrupt_when_data_register_USART_is_empty; }
}
а если предыдущая передача не закончена, что тогда? _delay_ms(1000) для надежности? и зачем тогда огород с передачей по прерываниям,
относительно _delay_ms(1000) , я его вставил специально чтобы вывод на терминал был медленным, в реальном проэкте такого конечно же не будет относительно законченности предыдущей задачи: мне представляется, изходя из своего опыта, что было бы правильней не начинать новую передачу пока старая не закончена. Допустим у нас сработали два внешние прерывания с периодичностью в 5мс, и на каждое из них мне нужно как-то отреагировать, допустим послать по юарту 2/3 книги война и мир, это пример явно зафантазированный, но как говорится чем ярче краски тем красивее картинка, так вот исходя из данного примера сообщение второго прерывания нужно бы поставить в очередь пока инфа с первого не передастся, а потом уже чтобы автоматом запустилось второе. Вот такое мое видение, допускаю что можна проще. Интересует сам принцип, насколько он правильный ?
тем более, что подобный принцип прекрасно поддерживается системными функциями printf, использовать которые для вывода на компьютерную консоль - милое дело! .
было бы правильней не начинать новую передачу пока старая не закончена.
ну так и где это условие у вас? у вас, если флажок пустоты буфера не установлен, функция тупо ничего не сделает, а вызвавший её код никак об этом не узнает...
лично я, хоть меня и критиковали не раз за такой подход, в исключительно редких случаях реализовывал передачу по прерываниям, в основном меня всегда удовлетворяет передача по тупому ожиданию
Но ведь по прерываниям удобнее. Сказал камню "выведи мне там Хелло-ворлд" и занимаешься своими делами, потом время от времени спрашиваешь сколько там байтов пришло в ответ (может и ноль). Я не представляю как подход на задержках встраивать в конечный автомат.
Добавлено after 1 minute 55 seconds:
Цитата:
тем более, что подобный принцип прекрасно поддерживается системными функциями printf, использовать которые для вывода на компьютерную консоль - милое дело! и практически весь UNIX вырос из именно такого, блокирующего printf...
В UNIX изначально была многозадачность, то есть пока интерактивный поток ждет пользователя, демоны вполне себе выполняются.
удобнее, как проще. конечный автомат написать - это думать надо... а так - не надо
COKPOWEHEU писал(а):
и занимаешься своими делами
это когда дел много...
COKPOWEHEU писал(а):
то есть пока интерактивный поток ждет пользователя, демоны вполне себе выполняются
так в МК то же самое. просто для меня приоритеты расставлены так: то, что должно делаться быстро, делается по прерываниям, а то, что может и подождать - в основном цикле. отсюда прием по прерываниям в фоне, а вывод - без прерываний в цикле.
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
удобнее, как проще. конечный автомат написать - это думать надо... а так - не надо
Э-э-э... Вы что, работу с UART каждый раз с нуля пишете? А если кольцевой буфер и прерывания уже написаны, подключение ничем не отличается от работы на задержках.
Сейчас этот форум просматривают: veso74 и гости: 38
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения