SysLibCom

[ВладОвен]

Ну да ладно. Отправка байтов налажена. Теперь есть проблемы с приемником. Пишем в программе:

myComRead(xExecute := TRUE, hCom := myComOpen.hCom, pBuffer := ADR(arrMassiveReceive), szBuffer := 10, udiTimeOut := 1000);

Сую в порт одиночные символы / не сую в порт одиночные символы.

xDone всегда отключен. xBusy всегда включен. Что можете посоветовать начинающему программисту?

[Евгений Кислов]

Что можете посоветовать начинающему программисту?

Как и раньше - внимательно изучить документ по ссылке из поста #5.

[ВладОвен]

Как и раньше - внимательно изучить документ по ссылке из поста #5.

Нет.

У меня вопрос!
В блоке Read есть параметр udiTimeOut. Он определяет время (толи в mS, толи в uS) через которое произойдет таймаут по приему.
Я записал туда число 10 000 000.

Что произойдет через этих 10 миллионов попугаев? Какой флаг должен установиться через это время? Что должно измениться?

[Евгений Кислов]

В блоке Read есть параметр udiTimeOut. Он определяет время (толи в mS, толи в uS) через которое произойдет таймаут по приему.
?

Это не так. Это таймаут доступа к буферу COM-порта.

Что произойдет через этих 10 миллионов попугаев? Какой флаг должен установиться через это время? Что должно измениться?

Если за это время не случится xDone или какая-то другая ошибка, то:

xError - TRUE
eError - COM.ERROR.TIME_OUT

[ВладОвен]

Правильно ли я понимаю, что функциональные блоки Write и Read реализованы по разному (что затрудняет их понимание и читаемость кода)?

1. Ф-блок Write не отдаёт xDone до тех пор, пока физически не отдаст последний байт линию COM-порта. Я пробовал на скорости 1200 отдать 255 байтов. Ф-блок Write блокирует программу более 2-х секунд. Реализовано хорошо: исключается наложение отдаваемых пакетов (потому-что блокируется программа).

2. Ф-блок Read отдаёт xDone сразу же, как только физически добрался до буфера. Придется сталкиваться с пустыми массивами, закольцованными массивами (придется проверять это). Параметр udiTimeOut выполняет непонятную своим смыслом функцию. Этот параметр должен был блокировать программу на указанное время, а после отдавать xDone, размер принятых байт (szSize) и принятый буфер (arrBuffer)! И ненужно было бы вводить свои кастомные таймера для таймаута, код был бы понятнее.

Ну а если нельзя блокировать программу, то зачем это сделано в ф-блоке Write? Он тоже мог бы тупо перекидывать в буфер и сразу же отдавать xDone? Пусть байты вылетают из порта своим ходом (хардовым способом).

В общем: Write блочит прогу, Read не блочит прогу.

PS: А еще обратите внимание, что параметр szSize отдает не количество принятых байт, а указывает на последний байт в кольцевом (!) буфере приема (arrBuffer). И если принятая посылка будет больше буфера, то вы получите недостоверное значение.

[Евгений Кислов]

Придется сталкиваться с пустыми массивами, закольцованными массивами (придется проверять это).

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

Этот параметр должен был блокировать программу на указанное время, а после отдавать xDone, размер принятых байт (szSize) и принятый буфер (arrBuffer)!

Должен кому?
Библиотека CAA SerialCom включает в себя асинхронные ФБ, которые не блокируют задачу, в которой вызываются.
В этом их преимущество - сохранение стабильного времени цикла без лишних джиттеров.

Для любителей "блокировать программу" - есть библиотека SysCom.

Он тоже мог бы тупо перекидывать в буфер и сразу же отдавать xDone? Пусть байты вылетают из порта своим ходом (хардовым способом).

Тогда другой пользователь спрашивал бы: почему после отправки запроса я читаю приемный буфер и вижу в нем свои же отправленные байты?
В общем, так себе решение.

И если принятая посылка будет больше буфера, то вы получите недостоверное значение.

А если читать документацию и разумно подходить к написанию кода - то таких проблем не будет.

[ВладОвен]

Ок. Спасибо за разъяснения.
Получается, что эта библиотека асинхронная. По задумке не блокирует программу.
Но отправка пакета реализована с блокировкой из-за того, что-бы не ловить свои-же байты.

[ВладОвен]

Евгений, здравствуйте.
А можете объяснить почему не срабатывает такая конструкция при открытии порта?

WHILE NOT myComOpen.xDone DO
    myComOpen(xExecute := TRUE, usiListLength := SIZEOF(arrParams)/SIZEOF(COM.PARAMETER), pParameterList := ADR(arrParams));
END_WHILE

Правильно ли я понимаю, что из-за того, что я блокирую программу?

[capzap]

Евгений, здравствуйте.
А можете объяснить почему не срабатывает такая конструкция при открытии порта?

WHILE NOT myComOpen.xDone DO
    myComOpen(xExecute := TRUE, usiListLength := SIZEOF(arrParams)/SIZEOF(COM.PARAMETER), pParameterList := ADR(arrParams));
END_WHILE

Правильно ли я понимаю, что из-за того, что я блокирую программу?

потому что while выполняется в рамках одного цикла, а необходимо несколько циклов плк, чтоб получить обмен с аппаратным сом-портом

[ВладОвен]

Привет.
Помогите решить такую проблему:
Мне нужно получить посылку длинной 39 байт. Посылка должная прийти асинхронно. Т.е. чёрт знает когда.
Мне приходится постоянно циклически слушать порт:

CASE bStep OF
    00: ...
    01: // Принимаем пакет
        myComRead(xExecute := TRUE, hcom := hCom, pBuffer := ADR(arrReceive), szBuffer := 255, udiTimeOut := 0);
        IF myComRead.xDone THEN
            bStep : = 2;
        END_IF
    02: // Проверяем длину принятого пакета
        IF myComRead.szSize = 0 THEN // Нулевая длина: уходим в начало
            myComRead(xExecute := FALSE);
            bStep := 1;
        ELSE
            bStep := 4;
        END_IF
    04: ...
END_CASE

Пакет принимается, но иногда поломанный. Я записывал длину каждого принятого пакета в массив и увидел вот что:
arrBufferLen[] = 0, 0, 29, 10, 0, 0, 0, 0, 0, 0, 0
Т.е. принимаемые 39 байт разбились на отдельные пакеты длиной 29 и 10 байт.
Очевидно, что это происходит из-за рассинхронизации процессов.

Как этого избежать? При этом длина входного пакета всегда разная.