From 0c19d406206531c41e66c1b734185979ccfb9fa1 Mon Sep 17 00:00:00 2001
From: Tim Stadtmann <tim.stadtmann@rwth-aachen.de>
Date: Wed, 29 Jun 2016 13:41:33 +0200
Subject: [PATCH] Fix wrong response buffer assignment in outputRead
These fixes are applied in both Command.m and Brick.m, that is, the
entire low-level. From a user-POV, nothing changes for now. The
internal tacho count can now be read correctly.
---
source/Brick.m | 10 ++++++++--
source/Command.m | 4 ++--
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/source/Brick.m b/source/Brick.m
index 9010495..71ed096 100644
--- a/source/Brick.m
+++ b/source/Brick.m
@@ -1587,8 +1587,14 @@ classdef Brick < handle
% firmware would put tacho first and speed second.
% If I tell the brick that I need a DATA8 and THEN a DATA32, ignoring the rule
% and going with the firmware version, I get an error in the response. (error flag)
- speed = msg(6);
- tacho = typecast(uint8(msg(7:10)),'int32');
+ %speed = msg(6);
+ %tacho = typecast(uint8(msg(7:10)),'int32');
+ tacho = typecast(uint8(msg(6:9)),'int32');
+ try
+ speed = msg(10);
+ catch
+ speed = 0; % Sometimes, the response packet lacks the 10th byte...?!
+ end
if brick.debug > 0
fprintf('Speed: %d\n', speed);
fprintf('buggy Tacho: %d degrees\n', tacho);
diff --git a/source/Command.m b/source/Command.m
index 26deaa9..fa20a01 100644
--- a/source/Command.m
+++ b/source/Command.m
@@ -2122,13 +2122,13 @@ classdef Command < handle
% - opOUTPUT_READ,LC0(layer),LC0(no),GV0(speed),GV0(tacho)
%
% Example::
- % cmd.opOUTPUT_READ(0,MotorBitfield.MotorA,0,1)
+ % cmd.opOUTPUT_READ(0,MotorPort.MotorA,0,1)
cmd.addDirectCommand(ByteCodes.OutputRead);
cmd.LC0(layer);
cmd.LC0(no);
+ cmd.GV0(tacho);
cmd.GV0(speed);
- cmd.GV1(tacho);
end
function opOUTPUT_TEST(cmd,layer,nos,value)
--
GitLab