Code download time.

[Don_Kirby]

Obviously, I'll find this out as soon as I have device and compiler in hand, but I am curious about the program download time for the N-mode devices vs. VM devices. Slightly longer I'm assuming.


-Don Kirby

[dkinzer]

I am curious about the program download time for the N-mode devices vs. VM devices.

The native devices download about twice as fast. Here's some test data:

[table][mrow] Device[col]Code Size[col]Time
[row]ZX-24a[col]31646[col]~10 sec.
[row]ZX-24n[col]39676[col]~5 sec.
[/table]
The download format for the VM devices is based on the Intel Hex format using 16-byte records so there's a fair amount of overhead involved. Moreover, the data has to be shifted out the the external EEPROM serially.

In contrast, the download format for the native devices contains binary records that are of Flash page size (256 bytes). This means that fewer characters have to be transmitted over the serial link for the same code size.

[mikep]

There is a code explosion for native mode which might be anything from 4 to 1 up to 20 to 1. So byte for byte the VM instructions are more powerful than AVR machine language. My guess is that the same program will nearly always download slower for native mode even though the download speed is actually 2x faster.

On the other hand I'm not sure it really matters that much one way or the other.

[dkinzer]

My guess is that the same program will nearly always download slower for native mode even though the download speed is actually 2x faster.

Incidentally, the data in the table above was for the same program compiled for each device. This is an unusual case, however, where 31,553 bytes of the code are for a data table contained in Program Memory. The difference in code size for each case is the actual executable code.

[spamiam]

There is a code explosion for native mode...

Hehe, I like that phrase, "code explosion". I visualize a big bang with lots of smoke, and ASM and C statements flying every which way!

-Tony

[mikep]

Hehe, I like that phrase, "code explosion". I visualize a big bang with lots of smoke, and ASM and C statements flying every which way!

You have obviously never seen me write code

The point is that the ZVM instructions are very compact and can express quite powerful concepts in a small number of bytes. For example calling a system function in the VM is at most one byte or two. In AVR C this is a minimum of 4 bytes.

[stevech]

pcode versus machine code:

ah so.. evermore: "which do you want: small, or fast?"

(of course, it isn't always so cut-and-dry)

[stevech]

I am curious about the program download time for the N-mode devices vs. VM devices.

The native devices download about twice as fast. Here's some test data:

[table][mrow] Device[col]Code Size[col]Time
[row]ZX-24a[col]31646[col]~10 sec.
[row]ZX-24n[col]39676[col]~5 sec.
[/table]
The download format for the VM devices is based on the Intel Hex format using 16-byte records so there's a fair amount of overhead involved. Moreover, the data has to be shifted out the the external EEPROM serially.

In contrast, the download format for the native devices contains binary records that are of Flash page size (256 bytes). This means that fewer characters have to be transmitted over the serial link for the same code size.

what serial port speed?
My binary-block mode bootloader for AVRs runs at 57600 or more, with a low bit-rate error crystal.

[dkinzer]

what serial port speed?

115.2K baud. At that speed and 40K of code, just sending the data bytes takes about 3.5 seconds. Additional time is required to send address, count, and error checking data, waiting for writes to be performed, and sending acknowledgements.

The approximate times that I reported were based on visual observation of a second hand and the download progress output. They could easily be off by a second either way.

[stevech]

is the bootloader's baud rate choice user defined? 115K may not work in many situaitons. No doubt the answer lies in something I should have already read.

[dkinzer]

is the bootloader's baud rate choice user defined? 115K may not work in many situaitons.

The rate is set at 115.2K. There is a protocol for switching to 19.2K baud but neither the IDE nor the zload utility currently implement it. This is the same situation with all other ZX devices.

Under what circumstances do you believe that problems may arise?

[stevech]

cable length/capacitance
PC side baud rate accuracy
use of USB-Serial converters
use of Ethernet-to-serial servers, or WiFi to serial

so IMO, the AVR bootloader should have some way to be compiled for or jumper-sensing or some such for lower rates, say, 38.4 or 57.6

[spamiam]

It is fairly easy to implement automatic baudrate detection based on the the bit times of a synch character sent by the host. It is about 100 extra bytes, likely less when coded in ASM.

At least the ability to drop down to 38.4K would be nice. This is because 38.4K has a low error when communicating to AVR devices which run at a multiple of 4MHz (at least it is true for 16Mhz, and 20MHz, and I am presuming the lower rates too).

-Tony

[mikep]

It is fairly easy to implement automatic baudrate detection based on the the bit times of a synch character sent by the host. It is about 100 extra bytes, likely less when coded in ASM.

Agreed

At least the ability to drop down to 38.4K would be nice. This is because 38.4K has a low error when communicating to AVR devices which run at a multiple of 4MHz (at least it is true for 16Mhz, and 20MHz, and I am presuming the lower rates too).

While true I suspect that the native devices will only come with a 14.7456 Mhz crystal as all of the ZBasic library code is built and tested around this frequency.

[stevech]

Yes- but not everyone has a simple 3 ft. serial cable connection, as I listed above.