|
Written on: 08. 04. 2015 [17:02]
|
|
Esen
Эсен Монолдоров
Topic creator
registered since: 26.02.2014
Posts: 15
|
есть функция отправляющий код и получающий ответ по rs485.
в архитектуре x86 все работает нормально а в armv7l получаю не правильно.
вот код функции
str_inASCII="93 08 0D";
//Первод отправляемого в бинарный
str_in=Special.FLibSYS.strEnc2Bin(str_inASCII);
// вычисление CRC16
out = 0xFFFF;
for( i = 0; i < str_in.length; i++ )
{
out = out^str_in.charCodeAt(i);
for( j=0; j<8; j++ ) out = (out&1) ? ((out>>1)^0xA001) : out >> 1;
}
str_out=SYS.strFromCharCode(out&0xFF,(out&0xFF00)>>8 );
//получение кода с CRC
str_outASCII=str_inASCII +" "+ Special.FLibSYS.strDec4Bin(str_out);
//отправка и получение ответа
rez=SYS.Transport.Serial.out_ttyUSB0.messIO(Special.FLibSYS.strEnc2Bin(str_outASCII),0.2);
while(true)
{
trez = SYS.Transport.Serial.out_ttyUSB0.messIO("");
if( !trez.length ) break;
rez+=trez;
}
//получение в читабельный формат
hex=Special.FLibSYS.strDec4Bin(hex1);
в x86 ответ: 93 00 01 B5 DD 00 00 00 07 00 00 00 01 00 01 2D 61 23 8C
в armv7l: 93 00 01 B5 DD 00 00 00 07 00 00 00 01 00 01 2D61 23 8C
вопрос как вылечить?
|
|
Written on: 08. 04. 2015 [21:00]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
registered since: 12.12.2007
Posts: 3750
|
"Esen" wrote:
в x86 ответ: 93 00 01 B5 DD 00 00 00 07 00 00 00 01 00 01 2D 61 23 8C
в armv7l: 93 00 01 B5 DD 00 00 00 07 00 00 00 01 00 01 2D61 23 8C
вопрос как вылечить?
А проблема то в чём?
Special.FLibSYS.strDec4Bin() предоставляет бинарный поток в читабельном виде и для другого не предназначен.
Вывод читается и в первом и втором случае, с разным отображением перевода строки.
Learn, learn and learn better than work, work and work.
|
|
Written on: 09. 04. 2015 [06:45]
|
|
Esen
Эсен Монолдоров
Topic creator
registered since: 26.02.2014
Posts: 15
|
"roman" wrote:
"Esen" wrote:
в x86 ответ: 93 00 01 B5 DD 00 00 00 07 00 00 00 01 00 01 2D 61 23 8C
в armv7l: 93 00 01 B5 DD 00 00 00 07 00 00 00 01 00 01 2D61 23 8C
вопрос как вылечить?
А проблема то в чём?
Special.FLibSYS.strDec4Bin() предоставляет бинарный поток в читабельном виде и для другого не предназначен.
Вывод читается и в первом и втором случае, с разным отображением перевода строки.
Проблема в том что в архитектуре ARM при получении бинарного потока 47 символ приходит без пробела.
Наблюдаю такую закономерность при получении от serial.
дело в том что полученный бинарный поток разделяется на несколько кусков и ответ может получится не правильным.
я получаю ответ так.
otvet1=(hex.slice(3,5)+hex.slice(6,8)+hex.slice(9,11)+hex.slice(12,14)).toInt(16);
Может я бинарный поток не так обрабатываю?
|
|
Written on: 13. 04. 2015 [09:07]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
registered since: 12.12.2007
Posts: 3750
|
"Esen" wrote:
Проблема в том что в архитектуре ARM при получении бинарного потока 47 символ приходит без пробела.
Наблюдаю такую закономерность при получении от serial.
дело в том что полученный бинарный поток разделяется на несколько кусков и ответ может получится не правильным.
Не полученный бинарный, а декодированный, что одинаково на всех архитектурах!
А раз так то я думаю нужно задуматься о том зачем его декодировать в читабельный вид, а затем обратно.
Примеры изучите и поймёте, что это лишнее: http://wiki.oscada.org/HomePageEn/Using/APIFunctionLibs/LibUserPrtDevs
Так-же смотрим на SYS.strDecode(), на предмет декодирования без разделителя.
И на объект IO, для разбора-формирования потоков со сложными типами данных.
Learn, learn and learn better than work, work and work.
|
|
Written on: 27. 04. 2015 [21:16]
|
|
Esen
Эсен Монолдоров
Topic creator
registered since: 26.02.2014
Posts: 15
|
Все вроде разобрался. Пользовательский протокол создан на проверку CRC.
req =SYS.XMLNode().setAttr("ProtIt","PSCH").setAttr("addr","93").setAttr("kod","01303030303030");
SYS.Transport.Serial.out_ttyUSB0.messIO(req,"UserProtocol");
if(!req.attr("err").length) kodout=req.text();
Новый наверняка глупый вопрос. Как округлить полученную цифру 246.0063 на 246.01 что-то не получается.
|
