> +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
_______________________________________________
chirp_devel mailing list
chirp_devel@intrepid.danplanet.com
http://intrepid.danplanet.com/mailman/listinfo/chirp_devel
Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers