Похоже, что таймаут по приему RS-485 в LTR43 работает неправильно. В следующем примере если SLAVE не высылает подтверждение на запрос MASTER, то LTR43_RS485_Exchange возвращает -4024, как и должно быть, и дальнейший обмен идет нормально. Однако, если SLAVE "ошибочно" высылает подтверждение, короче, чем ожидалось, то LTR43 зависает, и на просьбы послать что-нибудь еще не реагирует. В чем дело?

Игорь

==================================
Код MASTER:

#include "stdafx.h"
#include "stdio.h"
#include "conio.h"
#include <windows.h>
#include "ltr/include/ltr43api.h"
#pragma comment (lib, "ltr43api.lib")

TLTR43 hltr43;

int main(int argc, char* argv[]) {
    INT err;
    err=LTR43_Init(&hltr43);
    if(err)
        goto End;
    err=LTR43_Open(&hltr43, SADDR_DEFAULT, SPORT_DEFAULT, "", CC_MODULE3);
    if(err)
        goto End;
    printf("Name: %s/n", hltr43.ModuleInfo.Name);
    printf("FirmwareVersion: %s/n", hltr43.ModuleInfo.FirmwareVersion);
    printf("FirmwareDate: %s/n", hltr43.ModuleInfo.FirmwareDate);
    printf("Serial: %s/n/n", hltr43.ModuleInfo.Serial);

    hltr43.RS485.FrameSize=8;
    hltr43.RS485.Baud=9600;
    hltr43.RS485.StopBit=0;
    hltr43.RS485.Parity=0;
    hltr43.RS485.SendTimeoutMultiplier=5;
    hltr43.RS485.ReceiveTimeoutMultiplier=5;
   
    err=LTR43_Config(&hltr43);
    if(err)
        goto End;

    SHORT OutputArray[10]={/'0/', /'1/', /'2/', /'3/', /'4/', /'5/', /'6/', /'7/', /'8/', /'9/'};
    SHORT ConfirmArray[2];
    int n = 0;
    for(;;) {
        printf("%02d:", ++n);
        err = LTR43_RS485_Exchange(&hltr43, OutputArray, ConfirmArray, 10, 2);
        if (err)
            oem_printf("Error %d - %s", err, LTR43_GetErrorString(err));
        else
            printf("%c%c/n", ConfirmArray[0], ConfirmArray[1]);
        Sleep(1000);
    }

End:
    if (err)
        oem_printf("Error %d - %s/n", err, LTR43_GetErrorString(err));

    return 0;
}
==================================
Код SLAVE:

import serial

port = serial.Serial("COM2", timeout=20)
req_n = 0

def slave_exch(resp):
    global req_n
    while True:
        req = port.read(10)
        if not req:
            continue
        req_n += 1
        port.write(resp)
        print "%02d: %s > %s" % (req_n, req, resp)
        break

while True:
    slave_exch("!?")
    slave_exch("!?")
    slave_exch("")
    slave_exch("!?")
    slave_exch("!?")
    slave_exch("!")
    slave_exch("!?")
    slave_exch("!?")
    slave_exch("!?")
    slave_exch("!?")
=============================
Вывод MASTER:

Name: LTR43
FirmwareVersion: 1.5
FirmwareDate: 28.04.2008
Serial: 3R369947

01:!?
02:!?
03:Error -4024 - LTR43:Таймаут получения подтверждения при обмене по RS-485 истек!
04:!?
05:!?
06:Error -4007 - LTR43:Модуль не отвечает!
07:Error -4007 - LTR43:Модуль не отвечает!
08:Error -4007 - LTR43:Модуль не отвечает!
(и т.д.)
=============================
Вывод SLAVE:

01: 0123456789 > !?
02: 0123456789 > !?
03: 0123456789 >
04: 0123456789 > !?
05: 0123456789 > !?
06: 0123456789 > !
(конец вывода)

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

Александр! Заодно посмотрите, что делается на линии в начале передачи. На своем железе я вижу за 5-7 мкс до начала передачи первого старт-бита глюк – отрицательный импульс длительностью ок. 0.7 мкс и глубиной до -1.5 В дифф.

Стал смотреть т.к. на скоростях больше 19200 данные с LTR43 принимаются с ошибками. Например, на 115200 в посылке 0x00313233343536373839 с вероятностью 5-10% первый байт вместо 0x00 читается как 0x80. Для посылки 0xAA… первый байт может читаться как A8, 8A или 80. Приемником работает ICP-DAS I-7561. Это, конечно, ширпотреб, но другие устройства он понимал правильно.

Игорь

Игорь, по поводу отрицательного импульса: Вы подразумеваете при тех настройках LTR43, которые описали выше?  ICP-DAS I-7561 как конфигурируете (там джампера, кажется, есть)? Какой тип кабеля? Какая длина кабеля? Как соединяете ICP-DAS, кабель и LTR43 и нагрузку линии (приведите схему или таблицой соединений опишите)? Крейт LTR и компьютер заземлены на одну шину заземления?

Максимальную достижимую скорость на приём RS-485 в LTR43 уточним по ходу. О результатах сообщим.

Александр! Форма и положение импульса относительно данных от частоты передачи не зависят, однако на 9600 и 19200 ошибок приема нет. Джампер в  I-7561 в позиции «1-channel RS-485 or 1-channel RS-422». «Кабель» - три проводка из шлейфа RFC-1.27 длиной 20 см. «GND» I-7561 подключена к конт. 35 LTR43; между A и B резистор 100 Ом; внешних растяжек нет, внутренние растягивают неактивную линию на +400мВ (на 100 Омах). Крейт и компьютер не заземлены, от подключения осциллографа характер и частота ошибок передачи не меняется. Без нагрузочного резистора напряжение между A и B в неактивной линии ок. +2.5В, лог. «1» +3.8В, лог. «0» -3.5В, в импульсе -2.8В

По вопросу о таймауте могу добавить, что с ltrserver и ltr43api эффект не связан – то же наблюдается при управлении напрямую от Blackfin.

Да, действительно, описанные Вами глюки (отрицательный импульс и зависание при неполном ответе) присутствуют и связаны с текущей прошивкой AVR.

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

Алексей! Других глюков я пока не видел. Еще было бы хорошо насколько возможно увеличить размер буфера отправки/приема (10 байт неудобно) + убедиться в работоспособности на 57600 или 115200. В перспективе было бы интересно, чтобы LTR43 позволял в принципе реализовать полноценный мастер Modbus RTU (кадр до 256 байт, длина ответа заранее неизвестна, всякие там t1.5, t3.5 и прочие прелести).

Еще я не понимаю, зачем нужен SendTimeoutMultiplier. Вроде бы время, которое требуется для отправки байта, однозначно определяется бит-рейтом, числом битов в байте, к-вом стоп-битов и наличием бита четности. Тогда при данной конфигурации модуля мы будем либо всегда получать таймаут отправки, либо никогда не будем получать таймаут отправки. Причем узнать это можно из арифметики вовсе ничего не отправляя и не запуская никакие таймеры в AVR. Правильно?  И в чем смысл?

Ну на счет полноценного modbus с определением границ кадра по таймаутам я подумаю, но обещать не буду, может можно будет сделать отдельный режим, если это будет не сложно.

Расширить кадр по крайней мере до 255 байт можно (просто размер кодируется в команде от ПК в модуль одним байтом, начиная с 1. Наверное можно сделать отдельным режимом что значение 0 означает 256 байт, если актуально именно 256...).

В таймауте на передачу действительно смысла мало... думаю что в новой версии он не будет иметь значение...

Алексей! 256 байт не критично – сейчас мне нужен обмен со своим устройством, поэтому в значительной мере могу подстроиться под ограничения LTR43. В данном случае «комфортный» размер кадра – 60 байт, но в принципе нарезать по 10 тоже можно. Сейчас главное разобраться с глюками и скоростью передачи.

Выслал по почте новую версию