Гарантия того, что по USART все данные ушли Опции

[admiral]

Здравствуйте, не могли бы вы разъяснить такую ситуацию?
Перед входом в спящий режим мне нужно убедиться, что все данные ушли в линию. Для этого есть флаг ТХС. В даташите сказано:
Флаг устанавливается в 1 после передачи всех битов посылки из сдвигового регистра передатчика при условии, что в регистр данных UDR не было загружено новое значение. Флаг сбрасывается аппаратно при выполнении подпрограммы обработки прерывания или программно, записью в него лог. 1

Прерываний я не активировал, т.е. получается что после первой передачи, когда данные ушли, и в буфер я данных для отсылки не заносил, этот флаг установится в 1 и больше никогда не сбросится?
Если да, то получается, что после каждой передачи мне нужно программно сбрасывать этот бит?

[Александр Куличо...]

Что ж тут непонятного. Время на передачу байта фиксированное. Оно и используется в качестве таймера. А байт дальше драйвера 485 не уйдет.
На быcтрую руку примерно так:
По RxC: UDR = dummy; TimeOut = 0;
По TxC: if (++TimeOut <= N) {UDR = dummy;} else {DoOnTimeOut}
N, по моему, должен быть равен 4.
таким образом обнаруживается пауза > (4T...5T) (т.е. не факт, что пауза 4,5Т будет обнаружена)

P.S. Можно в качестве dummy-байта взять 0x0F. ТОгда получим фронт в середине байта на 0,5Т. И выход Tx завести на прерывание (по фронту). ТОгда можно будет обнаруживать паузы > (3,5Т...4,5Т). Но надо ли?

[_Pasha]

ТОгда получим фронт в середине байта на 0,5Т.

Вы ж не забывайте, что длительности в 1,5 и 3,5 Т выбирались исходя их соображений накрыть всех "опоздавших" и "неуспевающих" однозначным событием разделения данных. Имхо, если внутри распознается соответственно 2 и 4 Т, ничего страшного и "роняющего перфоманс" не происходит. Проще надо быть с модбасом

[demiurg_spb]

Проще надо быть с модбасом

Товарищи! Возник у меня ещё один вопрос про modbus.
Хотелось бы узнать какие-нибудь элегантные способы решения проблемы поддержания функционирования стандартных функций чтения-записи регистров и коилов в контексте 8-ми битного little-endian MCU.
Я решаю сейчас данную закавыку через remap-таблицу во FLASH.
Она зараза большая становится, когда много данных нужно ремапить, да и нудно её редактировать (хоть всё уже и так через макросы зафигачено).
Я уже и так и сяк, но ничего другого выдумать не могу. Прошу ALL не стеснятся и высказывать любые здравые предложения! Спасибо!

[_Pasha]

Она зараза большая становится, когда много данных нужно ремапить, да и нудно её редактировать (хоть всё уже и так через макросы зафигачено).

1. Написать приблуду и работать с Ёкселем в формате *.csv
2. Проблема, кстати, сходная с созданием таблицы редактирования/доступа к параметрам: зоопарк валидаторов, read-only/write-only/rw, источник или приемник данных (функция/ОЗУ/eeprom/flash), clear after use...

Код

typedef struct
{
// неявное задание правил доступа RO WO RW - метод == NULL
size_t (*read)(void *src, size_t size);//если результат != заданному size, то ашипко
size_t (*write)(void *dst, void *src, size_t size);
} data_src_stream_t;

typedef struct
{
uint16_t log_addr;
void      *phy_addr;
void *validator; // там же хранится инфа о размере
void *stream;
} remap_tbl_t;
//........................................
struct Valid32_cnt //пример
{
  uint8_t size;// всегда первым байтом пойдет как тэг
  uint32_t low;
  uint32_t high;
} pause_tmr={4,120000,240000};

Про coil_read() или coil_write()
Иногда проще все уложить в switch(), но лучше imho избавляться от двухбайтового оверхеда.
Если нехватка флеша на таблицу - приходится все паковать в битовые поля.

Код

typedef struct
{
uint16_t log_addr;
void      *phy_addr;

uint8_t mate;// многоцелевой индекс - все, что не отображается в полях, потом делается через switch(remap.mate)

unsigned size:2;// elem size
unsigned pool:4;// register pool
unsigned perm_rd:1;
unsigned perm_wr:1;
} remap_t;

Вот видите - у меня тот же бардак

[demiurg_spb]

1. Написать приблуду и работать с Ёкселем в формате *.csv

Тоже об этом думал, но пока что-то останавливает.

2. Проблема, кстати, сходная с созданием таблицы редактирования/доступа к параметрам: зоопарк валидаторов, read-only/write-only/rw, источник или приемник данных (функция/ОЗУ/eeprom/flash), clear after use...

Схожая да не совсем. К параметрам меню не обращаются как к "raw big-endian 16-bit data", и не пытаются читать потоком данные например float или DWORD или BYTE или BIT. И "самое страшное" что могут обратится лишь к младшему или старшему полуслову float или DWORD, а про массивы я вообще молчу:-) И про то, что есть 5 отдельных адресных пространств SRAM, FLASH, EEPROM, DATAFLASH, RTC. Мама помоги!!!! Пока я это всё делал чуть не тронулся умом;-) А всё из-за этого &%@# modbus (нехорошего в общем и целом).
С меню у меня всё достаточно красиво получилось (писал на Си в "стиле С++", некое наследование путём включения базового типа menu_item_t во всех потомков, ну и таки да, реализация методов доступа через switch (item_type) - так компактнее получилось, структуры практически без callback'ов). Написал макросы для ассигнования этих типов и всё получилось читабельно и вменяемо (хоть работы проделано немало).

Вот видите - у меня тот же бардак

Ага, нормально:-)