<Snip> This looks great - I'm going to enjoy trying it out as soon as I go back to one of our msp430 projects (at the moment I'm having to work with a TI TMS320F321 - would like to port gcc/gdb for that for me? Please? The TI tools make IAR's MSP software look cheap and chearful ! ).
> gdb is a general purpose tool. We need to live with what is does. One > odd thing it does is choose some strange block sizes in which to > download code by the remote protocol. When it uses large blocks, writing > to flash is reasonably fast. When it sends tiny blocks, writing to flash > gets slowwww...... Some caching is currently being done, but > improvements are needed. If I fully cache the data any write errors will > not be reported in a timely manner. I am not clear what the best > solution might be. > I think flash write errors are going to be a very rare case, and if you *do* get an error, it doesn't really matter at what time you see the error message, since you will probably have to replace the chip anyway. So I would think the priority should be to improve the speed while everything is working correctly.
