ADUCM360 и RS485

[optical illusion]

Несколько слов по проекту СN0359.
Вот фрагмент схемы подключения RS485, никаких ноу-хау.

Обратите внимание, что в этом чипе есть несколько физических устройств работающих с COM-портом и UART. Модем работает по стандарту который был еще в первых IBM PC. И приемопередатчики RS485 пинами управления всегда подключались в линии RTS. Ибо RTS удерживается на все время передачи посылки, вот лини CTS включается только на время передачи одного бита - это похоже на импульсы синхронизации. Если мне память не изменяет.
На этой схеме CN0359 пин управления RS485 подключен к выводу P0.5/CTS/IRQ1. Т.е. если бы использовался модем то подключение должно быть к другому пину P0.4/RTS/ECLKO. Вывод RTS подключен к управлению LCD - команда\данные.
Однозначно используется устройство - UART. Типовой UART всегда имеет 9 битный режим работы, потому как это во первых стандарт, во вторых никто не будет переделывать структуру UART что бы оттуда выдрать режим Mode 3 (9 бит). "Выдрать" иногда бывает сложнее чем "всунуть", основные затраты - это сертификация и разрешения - это очень дорого.
ADI очень плотно и долго работают с RS485. У них большой выбор разных чипов с этим интерфейсом.
Сам RS485 в Mode 3 управляется одним битом - затрат минимум. Это просто переключатель в выборе источника аппаратного прерывания.
То что у них есть в UART 9 бит режим - нет никакого сомнения.
В тексте кода CN0359 нет управления переключения в этот 9 бит режим, потому как он находится в приватном классе - это очевидно.

PS Хотя у модема должны быть режимы без поддержки RTS и CTS. Не факт, что это не модем используется.
А вот вопрос, приватный класс - это как библиотека? Ее можно "выделить" и затем таскать в другой софт?

Вопрос: а что Вам конкретно нужно по теме?
:

Допустим есть несколько чипов ADUC845, которые замечательно общаются между собой по RS485. Каждый имеет свой адрес в линии, когда выставляется адрес все понимают кому это сообщение. Если я хочу заменить ADUC845 на ADUCM360, то мне нужно решить проблему работы по RS485. Так как везде используется UART в режиме 9 бит, то мне нужно заставить ADUCM360 работать в этом же режиме. Логично?

внешнюю поставь

Ха... , поставить Силабс с нормальной поддержкой 9-бит режима UART, а потом просто по SPI подключить к ADUCM360 - и гонять байты туда-сюда?
Работать оно конечно будет, но придется загружать туда софт - дополнительные разъемы, и много всякого гемороя может возникнуть сопутствующего. Не по "человечески" это как то...

[j-Roger]

На этой схеме CN0359 пин управления RS485 подключен к выводу P0.5/CTS/IRQ1. Т.е. если бы использовался модем то подключение должно быть к другому пину P0.4/RTS/ECLKO.

Дополнительные модемные сигналы управления в данном проекте не используются по прямому назначению, а вывод P0.5, управляющий драйвером RS485, - это ногодрыг, правда? Хотя корректнее будет сказать, что это программное управление выводом порта.

Давайте посмотрим в файл source\hal\drivers\uart.cpp:

static int tx_empty(int argc, char *argv[])
{
    if (COMLSR_TEMT_BBA)
    {
        GP0CLR_CLR5_BBA = true; //change to receive status ‹-- cброс  бита
    }
    else
    {
        ...
    }
} 

ssize_t uart_write(const void *buf, size_t count)
{
    ...
    if (COMLSR_TEMT_BBA)
    {
        ...
        GP0SET_SET5_BBA = true; //change to send status ‹-- уcтановка бита
        ...
    }
} 

Ну и в том же файле есть код конфигурации UART в функции uart_open().
Вообще всё управление железом UART находится в этом файле. Загляните туда. Там вообще нет ни классов, ни ООП, обычное функциональное программирование. Если переписать работу с UART под себя, то делать это можно именно тут ( с несколькими важными оговорками ).

А в диалоговых окнах касаемо UART есть всего 2 настройки. Цитата:

}static const menu[] = {{"EXC Voltage", &VoltageDialog},
                        {"EXC Frequency", &FrequencyDialog},
                        {"T-H setup time", &SetupTimeDialog},
                        {"T-H hold time", &HoldTimeDialog},
                        {"TEMP Coefficient", &CoefficientDialog},
                        {"Cell Constant", &CellConstantDialog},
                        {"RS-485 Baud Rate", &BaudRateDialog}, ‹------
                        {"RS-485 Address", &AddressDialog},      ‹------
                        {"Return To Home", &HomeDialog},
                        {"LCD Contrast", &ContrastDialog},
                        {"Firmware Info", &FirmwareDialog}}; 

[optical illusion]

Я сейчас посмотрел в книге "Сопряжение датчиков и устройств ввода данных с компьютером IBM PC" Под. редакцией У.Томпсона и Дж.Узбетера Москва, Мир, 1992." на странице 244:
"Ошибки кадрирования передаваемых данных" - Флаг ошибки кадрирования в регистре состояния УАПП устанавливается в тех случаях, когда приемник, ожидая поступления 1, т.е. стопового разряда (или разрядов) в конце символа, вместо этого считывает 0. Ошибка кадрирования возникает в результате появления ложных разрядов, обусловленных действием шумовых выбросов."

Лукавят господа-авторы. Но не суть. Думаю, этот режим обработки прерывания может быть использован в имитирующем 9 битный режим обработчике прерывания.
В документе UG-367, на странице 141:

UART Line Status Register
Address: 0x40005014, Reset: 0x0000, Name: COMLSR
Table 163. COMLSR Register Bit Descriptions

Bit 3. FE. Framing error. 1: When the stop bit is invalid. Cleared to 0 automatically.

Использую программу Terminal.
Набираю текст в строке, нажимаю кнопку Send, сообщение уходит в МК, затем выводится на LCD.

В программае main(); есть фрагмент отвечающий за выод текста на LCD:

       ReciveString ();	
       LcmPutStr(10,2, (uint8_t*) bufRT);

Подпрограммы приема и обработки прерываний сейчас выглядит так:

//**********************************************
void ReciveString (void){	
	    uint8_t j;
	  ucCalComplete = 0;	
	 for ( j = 0 ; j ‹ 20 ; j++ )	
   {
	   ucWaitForUart = 1;
	   while (ucWaitForUart != 0){}	 			 
			  bufRT[j] = ucComRx;	
			 if (ucComRx == 0xD)   bufRT[j] = 0x20;	    
			 if(ucCalComplete › 0) return;			 
		 } 
     } 

//**************************************************  ************
void UART_Int_Handler ()
{
   volatile unsigned char ucCOMSTA0 = 0;
	volatile unsigned char ucCOMIID0 = 0;	
	ucCOMSTA0 = UrtLinSta(pADI_UART);			// Read Line Status register
	ucCOMIID0 = UrtIntSta(pADI_UART);			// Read UART Interrupt ID register
	if ((ucCOMIID0 & 0x2) == 0x2)	  			// Transmit buffer empty
	{
	  ucTxBufferEmpty = 1;
	}
	if ((ucCOMIID0 & 0x4) == 0x4)	  			// Receive byte
	{
		ucComRx = UrtRx(pADI_UART);
		ucWaitForUart = 0;
		if (ucComRx == 0xD)                 // "Carriage return" detected
			ucCalComplete = 1;
	}
}

Сейчас нужно дописать фрагмент с обработкой Адреса RS485 в UART_Int_Handler.

[индюк]

optical illusion
нет.
взять нужный ацп в виде отдельной микры и нормальный проц отдельно тоже, хоть ту же стмку самую низовую. там как раз 9 бит есть.
причем тут силабс вообще не вкурил.

[optical illusion]

индюк
А нужно будет взять два нормальных АЦП, затем еще один нормальный ЦАП, ну там еще нужен нормальный ИОН, и еще много чего "нормального"...
Про Силабс пишу потому что у меня на него есть много программ готовых к использованию. А с СТМ32 такая же засада - нужно "придумывать" и отлаживать софт.

[j-Roger]

Сейчас нужно дописать фрагмент с обработкой Адреса RS485 в UART_Int_Handler.

Думается, форумчане не будут вам препятствовать, а если даже и попытаются, то не смогут ))

Также думается, что в UART_Int_Handler-е логичнее таки принять всю строку и отдать её как есть на верхний уровень, который будет разруливать её содержимое. Как это сделано в проекте СN0359 и в вашем ( тестовом? ) проекте из поста #30. Пусть ReciveString() и разруливает.

Если хочется непременно в UART_Int_Handler, то, к примеру, такие варианты:
1) по мере поступления символов заполнять буфер прямо в обработчике, чтобы строка была "под рукой" и, когда станет ясно, что приняли адрес, обработать ситуацию - игнорировать входящие данные или принять строку целиком и уведомить верхний уровень.
Частный случай: когда приняли всю строку, то уже ясно, что она содержит адрес.

2) написать конечный автомат для посимвольного анализа входящих данных по мере их поступления. Опять-таки: когда станет ясно, что приняли адрес, обработать ситуацию. ИМХО лишнее усложнение.

[optical illusion]

Когда идет обработка Адреса в RS485 - то это не строка, это всегда только один байт. Диапазон 0-255.
Обрабатываться должно в UART_Int_Handler - тут оперативно нужно принимать решения. Проверка: принятый байт это -Адрес? Если Адрес - он равен адресу МК? Если два раза "да" - дальше идет логика обработки уже следующей сразу за Адресом команды.
Формат посылки обычно имеет вид - Адрес RS485, Команда №1 и т.д.
Можно сказать, что совпадение принятого Адреса и собственного адреса - работает как реле. Подключается (фиксируется) выбранный МК к линии RS485 и далее идет обмен данными (Мастер-Слейв), до тех пор пока не закончится обработка всего пакета команд. Затем МК отключается от линии (после соответствующей команды).


Нашел в документе "UART 16450 Transceiver" описание модема точно такого же как и в ADUCM360, даже названия регистров те же.
В описании регистра "Line Control Register (LCR)", на стр. 4, сказано:

Bit 5: This bit is the Stick Parity bit. When bits 3, 4 and 5 are logic 1 the Parity bit is transmitted and checked as a logic0. If bits 3 and 5 are 1 and bit 4 is a logic0 then the Parity bit is transmitted and checked as a logic1. If bit 5 is a logic0 Stick Parity is disabled.

Если я правильно перевел Гуглом, тут написано, что бит четности принудительно может быть зафиксирован (произвольно) в 1 или 0?

И что тогда будет с прерыванием ошибки четности, если его включить?

[индюк]

Когда идет обработка Адреса в RS485 - то это не строка, это всегда только один байт. Диапазон 0-255.
Обрабатываться должно в UART_Int_Handler - это оперативно нужно принимать решения.

не знаю как в твоем проце, но в куче процов в мультирежиме адрес вообще аппаратно определяется без участия ядра

[optical illusion]

не знаю как в твоем проце, но в куче процов в мультирежиме адрес вообще аппаратно определяется без участия ядра

Ха...
А если у МК поддерживается сразу несколько адресов?
Думаю, такая конструкция "криво" будет работать.

[j-Roger]

Когда идет обработка Адреса в RS485 - то это не строка, это всегда только один байт.

Всегда? А вот в том же проекте ADI СN0359 не так. Там ясно описан формат команды - первым в ASCII-строке идёт набор байтов, который интерпретируется как строковое представление десятичного числа и используется как адрес.
Авторы что-то не знали об RS485? Шутка.

Видимо, стоит более чётко различать физический уровень (RS-485, RS-422, RS-232 и т. д. и т. п) и протокол обмена/формат сообщений.

В общем, всем удачи!