Quoting Pierre-Emmanuel Goudet <[email protected]>:
> Just did some tries to get a faster loading and I got the best speed
> (6 times faster ! no so bad ;O)
>
> Here is my conclusion with the following command:
>
> $ mspdebug12 -d /dev/com8 --fet-force-id MSP430F5438A uif -j
> "erase" "load ti-txt-file"
>
> The max BLOCK_SIZE I got inside "fet.c" is : 499
> To use that I also grew up these two buffers of "fet.c":
> datapkt[2048] and buf[2048]
> And I've set the "prog.h" constant PROG_BUFSIZE to 1024.
>
> Maybe ALL modification are not mandatories, please tell me you mind
> about all this.
The modifications you made were all required - however, buf needs to
be twice as large as datapkt to allow for escape characters.
I've just pushed through a new change to the git repository which adds
a "fet_block_size" option. This affects both read and write transfers,
and it looks like it speeds things up quite a bit, though I've only
tested it with a small chip.
If you add this to your .mspdebug file:
opt fet_block_size 1024
You should get the same results as you did above. Be careful though -
there have been reports of crashes with some devices when the transfer
buffer size is too big (probably due to the availability of RAM on the
chip?).
- Daniel
--
D.L. Beer Engineering
www.dlbeer.co.nz
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Mspgcc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
