Скоростное управление девайсами

DimanVIP

Возникла необходимость проапгрейдить одну систему.
Суть ее такова: стоит древний комп с досом, управляет по LPT десятком механизмов. Скорость до 32 срабатываний на одно устройство в секунду.

Задача: перевести все это на ноутбук с Виндой. Заодно сократить количество проводов от ПК до устройства(бук планируется унести подальше от девайсов).

Думается: Лепить на USB, по LAN дуже медленно получится и геморно.
Со стороны ПК будет стоять преобразователь на 485 интерфейс с at90usb82. Со стороны девайса обратный преобразователь на каком-нить МК.
Вся загвоздка в том что Вынь система не реального времени, отсюда один БОЛЬШОЙ минус: заранее нифига не известно, за сколько времени сигнал от моей программы доберется до исполнительного устройства.
Посему много чего думается.... Но что-то все больно наворочено получается...

Хотелось бы услышать мнения, советы по сему поводу. Может кто уже решал подобные задачи.

Реклама

МитяРа

Мяу DimanVIP..
Если не используется протокол LPT, а устройства просто вкл./выкл. линиями порта, то можно просто например сделать так:
Выводы LPT, которые управляют механизмами подключаются на вход сдвигового регистра, там-же ставится тактовый генератор.
Тем самым мы преобразуем параллельный код управления в последовательный..
Потом через 485 передаём эту последовательность и импульсы синхронизации на второй сдвиговый регистр, на том конце..

Вот собственно и вся идея...

Реклама

DimanVIP

Сбацать этакий сериализатор вовсе не проблема. Проблема в том что на буке нет LPT.
Да и нафиг он собственно нужен с новой вводной: уменьшение количества проводов(переход на витуху).
Девайсы действительно имеют всего два положения, вкл\выкл.

Собственно пока думаю так: инициализировать МК в устройстве (настройки под каждый конкретный механизм находятся и изменяются в ПК). Потом только с ПК отправлять 10 бит(грубо говоря), где каждый бит отвечает за свой механизм. МК в устройстве получает этот пакет, смотрит биты, и если бит стоит в 1, то он запускает исполнительный механизм на время заданное при инициализации.
Это конечно самый простой вариант, но он не решает проблемы реалтайма. Хотя если обеспечит джитер в 5 мс, на нем остановлюсь.

Еще один не маловажный момент, порядок работы исполнительных механизмов заранее известен.
На основе этого есть мысль передавать порядок работы в МК устройства(сколько хватит памяти, потом "подливать" остальное). Останется потом только обеспечить синхронизацию МК и ПК.... Опять проблема....как?

DimanVIP

накидал маленький чертежик, чтоб не запутаться:

Реклама

DX168B

Пусть МК шлёт ответ ПК, что часть памяти освободилась. ПК быстро начнёт доливать данные и перед каждой отправкой пакета сначала дождаться ответа от МК, что можно посылать ещё пакет. ПК шлёт пакет и снова ждёт от МК ответа (слать ещё один или ждать) Надо сделать так, чтобы чтобы скорость отправки пакета была быстрее, чем его исполнение в МК.
Алгоритм таков:
При первом запуске заполняем кольцевой буфер в МК пакетами от ПК.
После каждого пакета, ПК должен ждать разрешение от МК, чтобы отправить следующий пакет.
МК поедает сначала пакты подряд, пока не заполнит свой буфер. После этого он уже не отвечает ПК, а приступает к исполнению первого пакета, как он его исполнит, то отсылает ПК разрешение на передачу следующего пакета и приступает к исполнению следующего пакета а новым принятым пакетом заменяет исполненный пакет. Причём надо сделать так, чтобы МК грузил пакеты до тех пор, пока не заполнит буфер. Если будет где-то задержка (винда тормознёт и опоздает), то у МК есть в запасе неисполненные данные, которые он будет исполнять один за другим автономно. Как Винда придёт в чувство, то МК параллельно исполнению будет грузить новые пакеты с ПК, пока не заменит всё старое.
Так работает аудиобуфер в МП3шниках.
Метод исполнения виртуальных комманд можно построить методом табличной косвенной адресации. На АСМе в МК AVR это делается очень легко. Приём данных можно организовать по прерываниям, к примеру SPI или UART.

Реклама

DimanVIP

Это все само собой разумеещееся.

Плюс к этому привяжу синхронизацию отображения "прогресс бара" на ПК. Пусть там ПК глючит пучит и таращит, вся "четкость" процесса будет сосредоточена в МК. Пусть лучше не совсем четко будет отображаться ход выполнения на ПК, чем он будет выполняться в реале.

Реклама

DX168B

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

BCluster

DimanVIP писал(а):32 срабатываний на одно устройство в секунду

это не высокоскоростной. Для МК/ПК это вообще не скорости. LAN не даст значимых задержек в вашей задаче. Ерунда. Но его использовать неудобно, если только комп сильно удален.
А так USB -> FIFO, что нибудь от FTDI и вперед. Насчет того что винда не рил тайм ос - опять же для ваших скоростей это ерунда.

DimanVIP писал(а):Хотя если обеспечит джитер в 5 мс

совершенно легко. Да и вообще драйверы работают в другом режиме, нежели обычные приложения. Ну и на крайний случай есть RTX - риал тайм для винды.

DimanVIP

BCluster писал(а):Ну и на крайний случай есть RTX - риал тайм для винды.

C этого места можно подробнее...

BCluster

http://www.directinsight.co.uk/products ... m/rtx.html - но он тебе не понадобится, не те скорости

Когда речь идет о реал-тайме, там требования к времени реакции до 20мкс например.

Jack_A

BCluster писал(а):http://www.directinsight.co.uk/products/venturcom/rtx.html - но он тебе не понадобится, не те скорости Когда речь идет о реал-тайме, там требования к времени реакции до 20мкс например.

Крутая штука ! Но сто'ит, видимо, много денег.
Что касается этой задачи, то исходняк непонятен: тупо гнать байт за байтом - и все? Бегущая строка ? Если это управление каким-нибудь оборудованием, то должны быть обратные связи. А если без обр.св. - только циклограмму, и засада только в нереалтаймовости Винды, я бы времянку задавал головным МК - уж у него-то проблем с ОС не будет по причине ее отсутствия, а по опустошению буфера переключил бы вывод на другой буфер, а первый без спешки заполнял бы из ПК свежей порцией инфы.

ploop

BCluster писал(а):
DimanVIP писал(а):Хотя если обеспечит джитер в 5 мс
совершенно легко. Да и вообще драйверы работают в другом режиме, нежели обычные приложения. Ну и на крайний случай есть RTX - риал тайм для винды.

Драйверы это одно, но если логика сосредоточена в обычном ПО - на задержку около 35мс можно рассчитывать смело. Примерно с такой частотой идёт очередь обработки системных сообщений (проверялось на winXP).

Я бы советовал пересмотреть немного задачу, точнее, сделать как уже предложил DimanVIP

Плюс к этому привяжу синхронизацию отображения "прогресс бара" на ПК. Пусть там ПК глючит пучит и таращит, вся "четкость" процесса будет сосредоточена в МК. Пусть лучше не совсем четко будет отображаться ход выполнения на ПК, чем он будет выполняться в реале.

С ПК идут команды блоками, а интерпретатор этих команд вынести в МК. При том эти блоки будут улетать быстро как по ЛАНу, так и по USB (в смысле для данной задачи скорости более чем достаточно).

DimanVIP

На ПК хранится алгоритм работы исполнительных устройст. Плюс на нем отображается процесс отработки этого алгоритма, не более.

Спасибо всем откликнувшимся за советы и подсказки.

Делать буду так:
Сначала происходит инициализация устройства данными из ПК. Потом заполняется приемный буфер устройства.
Устройство раз в 1/32 сек будет брать пакет из приемного буфера, выполнять его, и отправлять ПК ответ, в виде количества свободных ячеек приеного буфера.
ПК получив ответ, отправляет запрошенное количество блоков. И также корректирует позицию отображения "прогресс бара".

Думаю так будет лучше всего.

З.Ы. ОС не требуется, но когда понадобится (возможно в скором будущем, когда поменются типы приводов), она полностью ляжет на МК устройства.

DimanVIP

Хочется рассказать, почему возникли сомнения касательно скорости.

Давным давно в порядке эксперимента делал связь между ПК и МК. Со стороны ПК висела FT'шка с 485 преобразователем, и прикидывалась COM портом. На МК тоже стоял 485 преобразователь и дисплей(для наблюдения за количеством принятых пакетов, битых пакетов и т.д.). Связь шла по витухе.

Протокол был самописный, формат пакета с ПК был такой: 0x55---полезный байт---CRC.
На что МК ему отвечал, если пакет проходил нормально: 0x55---OK
После получения подтверждения ПК слал следующий пакет.

Дык в ходе экспериментов выяснилось, что скорость обмена от скорости передачи практически не зависит. Главным "тормозом" было время переключения COM порта с передачи на прием и обратно. Сейчас по памяти уже не помню, но что-то порядка десятка мили секунд.

Т.е. если организовывать связь таким образом, она бы точно не уложилась в требуемое значение.

Думаю с предложенной реализацией такого не будет, тем паче "шлангом(COM портом)" прикидывать преобразователь не собираюсь.

DX168B

В TINY2313 есть прерывания:

Код: Выделить всё

USART0_RXC ; USART0 RX Complete Handler
USART0_DRE ; USART0,UDR Empty Handler
USART0_TXC ; USART0 TX Complete Handler

Переключать там ничего не надо.

Код: Выделить всё

;--------------------------------------------------------
; Set baud rate
ldi temp0, 51
ldi temp1, 0
out UBRRL, temp0
out UBRRH, temp1
; Enable receiver and transmitter, Rx int-t enable, TX int-t enable, UDR empt int-t enable.
ldi temp0, (1<<UDRIE)|(1<<TXCIE)|(1<<RXCIE)|(1<<RXEN)|(1<<TXEN)
out UCSRB, temp0
; Set frame format: 8data, 1stop bit
ldi temp0, (0<<USBS)|(3<<UCSZ0)
out UCSRC, temp0
;--------------------------------------------------------

Далее просто разрешаем прерывание по окончанию передачи, пихаем первый байт данных в UDR а потом по прерыванию и всё остальное. После всей процедуры передачи зарпещаем это прерывание.
Так-же и с приёмом. По прерыванию запихиваем данные в буфер из регистра UDR.
Переключать ничего не надо.

DimanVIP

DX168B писал(а):Переключать там ничего не надо.

DimanVIP писал(а):Главным "тормозом" было время переключения COM порта

А COM порт у нас где? Правильно в ПК.

DX168B

Хм... Не видел, чтобы в ПК надо было что-то переключать. Я программировал на основе WinAPI.
Даже DLL-ку себе сделал. Тоже - один раз инициализация, за тем уже просто с ним работаем.
Я даже организовывал приём и передачу двумя разными потоками. Всё работало одновременно.
Программы, написанные мною, работают даже с виртуальными портами блюдуса и с переходниками USB-COM (проверял на чипе CP2102).

DimanVIP

Естесственно что для разработчика там все прозрачно. И никаких "ручных" переключений нет. А вот в реальности винда переключает СОМ довольно-таки долго.

DX168B

Настроек у него куча:

Код: Выделить всё

//**************************************************************************
extern "C" __declspec (dllexport) bool DXCOM::Open(int port, int baud, int rttm, int rttc, int wttm, int wttc)
{
	char COM_string[20];
	sprintf(COM_string,"\\\\.\\COM%d", port);

	m_hFile = CreateFile(COM_string, GENERIC_READ|GENERIC_WRITE, 0, NULL,						
	   OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL,NULL);
	

	if(m_hFile == INVALID_HANDLE_VALUE)
	{				
		return false;
	}


	DCB dcb;
	GetCommState(m_hFile, &dcb);

	COMMTIMEOUTS CommTimeOuts;
	CommTimeOuts.ReadIntervalTimeout		 = MAXDWORD;
	CommTimeOuts.ReadTotalTimeoutMultiplier  = rttm;
	CommTimeOuts.ReadTotalTimeoutConstant    = rttc;
	CommTimeOuts.WriteTotalTimeoutMultiplier = wttm;
	CommTimeOuts.WriteTotalTimeoutConstant   = wttc;

	SetCommTimeouts(m_hFile, &CommTimeOuts);


 	memset(&dcb,0,sizeof(dcb));
 	dcb.DCBlength = sizeof(DCB);
 	GetCommState(m_hFile, &dcb);
 	dcb.BaudRate = DWORD(baud);
 	dcb.ByteSize = 8;
 	dcb.Parity = NOPARITY;
 	dcb.StopBits = ONESTOPBIT;
 	dcb.fAbortOnError = TRUE;
 	dcb.fDtrControl = DTR_CONTROL_DISABLE;
 	dcb.fRtsControl = RTS_CONTROL_DISABLE;
 	dcb.fBinary = TRUE;
 	dcb.fParity = FALSE;
 	dcb.fInX = dcb.fOutX = FALSE;
 	dcb.XonChar = 'b';
 	dcb.XoffChar = 'd';
 	dcb.fErrorChar = FALSE;
 	dcb.fNull = FALSE;
 	dcb.fOutxCtsFlow = FALSE;
 	dcb.fOutxDsrFlow = FALSE;
 	dcb.XonLim = 128;
 	dcb.XoffLim = 128;

	SetCommState(m_hFile, &dcb);

	this->state = true;
	return true;	
}

Если правильно настроить, тормозов быть не должно. Тем более решить можно, подъёмом скорости обмена (baudRate)

DimanVIP

DX168B писал(а):Если правильно настроить, тормозов быть не должно.

Не поделитесь как?

DX168B писал(а):Тем более решить можно, подъёмом скорости обмена (baudRate)

DimanVIP писал(а):Дык в ходе экспериментов выяснилось, что скорость обмена от скорости передачи практически не зависит.