[chirp_devel] [PATCH][BTECH] Bug fix about radios resetting on the download, fixes #3015

[Dan Smith]

> This read of the second ID is way beyond in the high mem area, the area
> that is not touched by the OEM software, we are doing a simple and
> common read but this radios has the bad behavior (bug? feature? flag?)
> to send a misplaced \x05 byte on the first reads... and this misplaced
> \x05 is the one that is doing the block shorter or longer.

Before or after the block you have to read the longer block? Anything
you can do to anticipate that the longer read is needed would be good.

Can you read the id block after the rest of the clone is done? You can
always stitch the image together later if need be.

> The OEM always use the 64 bytes length on the reads, but this particular
> high mem reads is always 16 bytes, the restriction you see later in the
> code about almost 16 bytes is because the string we need is in the lower
> 16 bytes.

Meaning the OEM software asks for 64 bytes in its communication with the
radio, or that the radio returns 64 bytes?

I don't think that the portmon-reported length is necessarily the length
that the software is reading, but rather the amount returned to the
application.

> This can be another approach, send the request for the 16 bytes and read
> at least 16 (from the 21 it must be) then process it and at the end do a
> serial flush to get the buffer clean (or a dummy read of the 5 following
> bytes)

Any time you're doing a flush or throwing away data in the middle of a
clone procedure, I'm highly concerned because it means we don't know
what all we're reading ...

> No, the read size (64 bytes) is constant trough the read, the same we
> have on the write to the radio with 16 bytes on each bloc, but this
> particular high mem reads is always 16 bytes only.

So we could go with a timeout of 5 minutes then right? I'm being
hyperbolic, but what I mean is, you only ever need a short timeout if
you're reading more than is available...

--Dan