[chirp_devel] [PATCH] [New Model] Add Support for Retevis RT23 Radio

Dan Smith
Thu Jun 15 14:25:55 PDT 2017


> +def _rt23_write_block(radio, block_addr, block_size):
> +    serial = radio.pipe
> +
> +    cmd = struct.pack(">cHb", 'W', block_addr, BLOCK_SIZE)
> +    data = radio.get_mmap()[block_addr:block_addr + BLOCK_SIZE]
> +    cs = 0
> +    for byte in data:
> +        cs += ord(byte)
> +    data += chr(cs & 0xFF)
> +
> +    LOG.debug("Writing Data:")
> +    LOG.debug(util.hexprint(cmd + data))
> +
> +    try:
> +        for j in range(0, len(cmd)):
> +            time.sleep(0.002)
> +            serial.write(cmd[j])
> +        for j in range(0, len(data)):
> +            time.sleep(0.002)
> +            serial.write(data[j])
> +        if serial.read(1) != CMD_ACK:
> +            raise Exception("No ACK")

This inter-byte delay timing is rather unfortunate. I assume your
testing shows that this is the only way the radio will accept the image?

It takes a hair over 1ms to send a single byte at 9600 baud. Sleeping
for 2ms in between means you're sending one byte every 3ms, which is
crazy slow. Do you see the factory software actually writing one byte at
a time in the trace? As we've covered before, doing sleeps at this
granularity requires the operating system to schedule you pretty
regularly to keep up the stream, which is both wasteful and error-prone
of the system is loaded. It also increases the likelihood that the
driver will behave differently on Linux, Windows, and with differing
serial hardware.

Have you tried doing something like writing 8 bytes at a time, with a
sleep in between or something like that?

--Dan



More information about the chirp_devel mailing list