Проблема с приемом данных в произвольные моменты времени

[MONSTR]

Здравствуйте!

Есть следующая система: ПК -> USB-UART -> Микроконтроллер Atmega32

Без проблем получается средствами VISA передавать данные с ПК на МК и обратно, НО:

Есть необходимость в ПРОИЗВОЛЬНЫЕ моменты времени принимать посылки от МК, то есть хотелось бы в программе на LabVIEW организовать прерывания в моменты, когда МК отправляет данные. Программа на ПК должна как-то понять, что МК отправляет данные и только тогда запускать функцию Read.

В теме не очень давно, ковыряюсь уже неделю, не выходит. Подскажите, пожалуйста, кто знает, как решить проблему.

[Borjomy_1]

А что насчет коллизии, когда вы отправили данные с ПК на МК, а в этот момент МК захочет отправить свою посылку?
Правильнее реализовать опрос МК по состоянию готовности данных. И тогда, при приходе готовности, запрашивать данные с МК. Готовность, кстати можно выдавать не сразу, а в течение какого-то времени, например 100мс. В течение этого времени либо досрочно приходит ответ от МК, что данные готовы, либо по истечению таймаута приходит ответ, что данные не готовы. Программу приема в LV настроить на таймаут 150мс. Тогда по выходу из этой задачи вы сможете отправить свои команды. А контроллер уже не сможет отправлять данные самостоятельно, когда вы производите обмен.
Сейчас у вас при двунаправленном обмене получается два инициатора. Это неправильно, никогда работать не будет нормально. Обычно контроллер делают подчиненным устройством, которое выдает информацию только по запросу.

[IvanLis]

Есть необходимость в ПРОИЗВОЛЬНЫЕ моменты времени принимать посылки от МК, то есть хотелось бы в программе на LabVIEW организовать прерывания в моменты, когда МК отправляет данные. Программа на ПК должна как-то понять, что МК отправляет данные и только тогда запускать функцию Read.

В теме не очень давно, ковыряюсь уже неделю, не выходит. Подскажите, пожалуйста, кто знает, как решить проблему.

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

[MONSTR]

Сейчас у вас при двунаправленном обмене получается два инициатора. Это неправильно, никогда работать не будет нормально. Обычно контроллер делают подчиненным устройством, которое выдает информацию только по запросу.

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

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

Так нечего пока смотреть - не знаю как реализовать. Пока сделан обмен данными по запросу ПК, а как инициировать приём данных компьютером "по желанию" МК (без предварительного запроса от ПК) - не знаю.

[Vitekkz88]

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

Вынесите опрос статусных регистров в отдельный поток и проверяйте их состояние самостоятельно каждую секунду например.
Или это будет противоречить Вашему протоколу обмена данными с контроллером?

[MONSTR]

Вынесите опрос статусных регистров в отдельный поток и проверяйте их состояние самостоятельно каждую секунду например.
Или это будет противоречить Вашему протоколу обмена данными с контроллером?

Нет, не противоречит, протокол сами придумываем, учимся, изобретаем свой велосипед Видимо так и придётся делать, как Вы говорите.

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

[IvanLis]

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

Я Вам про это и говорил.
Для приема данных организуете отдельный цикл. Настраиваете окончание приема посылки по "терминатору". А МК соответственно этим терминатором оканчивает посылку. Когда посылка принята, она передается в другой цикл (для этого как правило используются очередь - Queue).
В цикле обработки принятый пакет разбирается (в заголовке пакета можно указать что с ним делать, т.е. определить "правила") и потом уже в зависимости от "правила" обрабатывается тем или иным способом.

[MONSTR]

Я Вам про это и говорил.
Для приема данных организуете отдельный цикл. Настраиваете окончание приема посылки по "терминатору". А МК соответственно этим терминатором оканчивает посылку. Когда посылка принята, она передается в другой цикл (для этого как правило используются очередь - Queue).
В цикле обработки принятый пакет разбирается (в заголовке пакета можно указать что с ним делать, т.е. определить "правила") и потом уже в зависимости от "правила" обрабатывается тем или иным способом.

Может я чего-то не понял, но всё же.
Вы говорите о завершении приёма данных и дальнейшей их обработке. С этим всё ясно. Меня же интересует начало приёма данных, а именно - как сделать так, чтобы программа на ПК начинала приём именно тогда, когда МК их будет передавать без запроса со стороны ПК.

Для приема данных организуете отдельный цикл.

А как программа перейдёт в этот цикл, именно тогда, когда МК отправляет посылку?

[IvanLis]

Меня же интересует начало приёма данных, а именно - как сделать так, чтобы программа на ПК начинала приём именно тогда, когда МК их будет передавать без запроса со стороны ПК.

Это реализуется не Вами и не в LabVIEW, порт постоянно находится в ожидании. Если Вам интересны механизмы, то можете почитать самостоятельно.

А как программа перейдёт в этот цикл, именно тогда, когда МК отправляет посылку?

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

[Borjomy_1]

Получается все проще - перед посылкой команды проверять наличие в буфере посылки. Так как вы эти данные не заказывали, то это "последний выдох".

[MONSTR]

Borjomy_1, а объясните, пожалуйста, немного подробнее - как это сделать - всегда проверять значения в "Bytes at port" или использовать функцию ожидания события?

[Borjomy_1]

Перед операцией запроса производить проверку "Bytes at port". Но все равно метод является извращением. Какая вам разница, узнали ли вы о том, что контроллер выключился, сейчас, или на 100мс позже? Все равно с ним ничего сделать не удастся. Поэтому ОБЫЧНО устройства просто опрашивают с некоторым интервалом. Наступление таймаута однозначно указывает от отваливание контроллера (таймаут не обязательно делать 10сек, как по умолчанию. Достаточно удвоенного максимального времени обмена). Также это и диагностирует пропадание связи. Ваше решение при пропадании связи не работает и вы можете узнать об этом, только послав команду, т.е. это будет действительно слишком поздно.

[MONSTR]

Благодарю всех за советы! Решение приняли. Инициатор всегда будет ПК.