Receiving serial slow to process

I am currently working on a 2way interface with a Yamaha RXV2067 receiver via serial one off the problem I have come across is when receiving the serial from the Yamaha the strings come in quicker than Homegate can process them, so it appears to buffer them then works its way through them which makes the process quite slow.
Not to bad if you are doing some thing like changing radio station that the Yamaha only sends a couple of strings which is fine . But if you are changing source to the iPod you get all the Matadata coming at you, Homegate buffers it all them starts to process it all string by string which takes for ever.
Any Idea?s on how we can speed this process up

 

If you are only processing one command on each logic engine "scan", then the problem you have found can occur. There is nothing to stop you from processing all of the commands in the buffer on a single scan.

There are various ways of doing this, but something like this would work well:

Code:

repeat
  ReadSerial(1, CommandString, #13#10);
  if Length(CommandString) <> 0 then
  begin
    { process command string here }
  end;
until Length(CommandString) = 0;

 

Thanks Darren

Tried the sample code and works very well at speeding things up but we have some side effects, probably due to the way we have structured the program:

There is one module that only has ReadSerial(1, s,#13#10);
Then there are 11 other modules checking the value of s to see if they need to do anything. Other modules are for things like the three zones on the Yamaha, an ipod module etc.

I tried the repeat/until using s as the string in the iPod module just in the one part looking to write the iPod metadata to the screen worked great, but occasionally other commands are missed when the repeat/until is active. I guess these missing commands are getting caught in the loop code?

What do you suggest?

 

Just a thought

Not sure if this is relevant but I find the if hasChanged function very useful for controlling whether to run a pile of comparison checks.

Maybe look at your string value first to see if it has changed, if it hasn't then the code skips the logic which goes on to see what the new value is and figure out what to do with it. A way to have lots of 'lookup' type logic while only running it where input has changed maybe?

 

I would have some boolean "flags" which get set within the repeat loop to record whether certain messages were received.

I am not familiar with the particular serial protocol you are using, but the code could be something like:

Code:

VolumeHasChanged := false;
ChannelHasChanged := false;
repeat
  ReadSerial(1, CommandString, #13#10);
  if Length(CommandString) <> 0 then
  begin
    { process command string here }
    if pos('Volume', CommandString) = 1 then
    begin
       { extract new volume from string }
       ...
       VolumeHasChanged := true;
    end
    else if pos('Channel', CommandString) = 1 then
    begin
       { extract new channel from string }
       ...
       ChannelHasChanged := true;
    end;
  end;
until Length(CommandString) = 0;

...
{ in separate module }
if VolumeHasChanged then
begin
  ...
end;

if ChannelHasChanged then
begin
  ...
end;

 

The HasChanged function does not work with strings. The argument can only be boolean, integer or real.

If you want to see if a string has changed, you would need to save a copy of the string from the last scan and compare it with the new scan.

 

We are nearly there but still have a couple of issues see attachment

 

With problem 1, I think that the problem is that in the place where you are checking for @iPOD:LINE2TXT= the begin/end block should have the copy statement within it.

I don't understand what problem 2 is. You might need to add some logging to see what is going on.