[Cstk-devonly] RE: read() method

[Stuart R. <st...@Cs...>]

> It seems that the only way to solve that read(DC,uint) problem is to
> pass twice over the log file, with the first pass to get the minimum and
> maximum limits for that specific channel. This is something you can do
> with log files, but not with, say, streaming data (over serial line,
> UDPs, ...). 
> 
> That's also what I meant in the comment for the empty read() method: it
> first of all needs an object to store its data in, and it's impossible
> to estimate number and type of channels for streaming data.
> So I think we should just stick to the first two read(...) methods, and
> make the logfile parser read(DC,uint) method a bit superior (over
> rs232parser and the like) by not specifically requiring type definitions
> for the channels - what do you think?

Yes, I agree about the read(DC, uint) method for LogFileParser
`superior'. It certainly makes more sense. After all, of course, the
channels are specified by the associated XML file (AFAIK). This means that
even for rs232 input, CSTK at least knows how many channels to expect.

This does raise the issue of value scaling. For example, if I have a
channel in a log file that starts off as a 8bit number, but eventually
turns into a high 64bit number, the way that this is interpreted will
the visualisation and any other receivers of this data that are sensitive
to scale.



later,
Stuart
---
digimail:              st...@tr...
electromagic-interweb: http://www.cs.nott.ac.uk/~str