Bug #9401: Memory editor reads last memory twice - CHIRP

Actions

Copy link

Bug #9401

closed

Memory editor reads last memory twice

Added by Kosta A. about 3 years ago. Updated about 3 years ago.

Status:

Closed

Priority:

Low

Assignee:

Kosta A.

Category:

Target version:

Start date:

09/28/2021

Due date:

% Done:

100%

Estimated time:

Chirp Version:

daily

Model affected:

(All models)

Platform:

All

Debug Log:

I read the instructions above:

Description

There is an off by one error in the read logic for special channels, which causes the last memory to be read again...

For example, in a driver with 100 memories (0..99) and 5 special memories (100..105) the memory editor first retrieves memories 0 thru 99, and subsequently kicks off a low priority job to read the special memories, however rather than starting at 100 it begins at 99, thus reading the final non-special memory again...

This has no real consequence on the result other than being a bit confusing to developers when working on a driver, and obviously being unnecessary

Actions

Copy link

Updated by Kosta A. about 3 years ago

Status changed from New to Resolved

In the orginal description i described the issue as pertaining to special memories, this is technically not accurate, as the issue refers to the memories loaded outside of the specified memory range...

The memory editor first loads the lo..hi+1 memories (where lo and hi are computed by the UI), then loads the hi..max memories (where max is computed from the driver memory bounds), thus loading the hi'th memory twice.

Either way a patch has been sent to the mailing list.

Actions

Copy link