Request to add features

[GoogleCodeExporter]

I have implemented three new features that are very useful for my use case of 
stm32flash. I hope they are useful to others too. They are all added as options 
to the command line.

-N Disable reset after operation.
   When using GPIO sequences for controlling boot mode and reset
   it is not necersary to send reset-code to RAM of MCU so it is nice
   to skip this step during query/program/verify operations.

-F Enable fast GPIO (100x).
   Instead of 100000 and 500000 µS sleep, sleep 1000 and 5000 µS.
   Useful for very impatient users like myself.
   (0.018 seconds compared to 0.813 when just verifying 
   connection to device)

-D Dummy mode.
   Do not query device or do anything except GPIO sequences.
   Useful for resetting, stopping or starting MCU when GPIO is
   connected to !NRST on MCU.

Regards
Mikael Lövqvist

Original issue reported on code.google.com by ledalert...@gmail.com on 5 Aug 2014 at 5:48

Attachments:

• 0001-Added-support-for-fast-GPIO-dummy-mode-for-resetting.patch

[GoogleCodeExporter]

Thanks for posting your patches! However, I have just merged a large rewrite 
from Antonio so your patches must be revised. The -N option is not needed 
because we will from now on not do reset by default, but allow -R for reset.

Original comment by lists.to...@gmail.com on 8 Aug 2014 at 11:23

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

I just had a look, it looks very nice, I like the idea of having different port 
interfaces!

I started working on the new patches but realized something I have overlooked.
When using the serial port the connected MCU may output stuff on it before it 
is reset uising the GPIO sequence, this may cause the input buffer to have junk 
in it which will interfer with stm32flash. I remembered that I did solve this 
in an old version I modified by flushing the input buffer so I implemented a 
flush() in the port_interface and started implementing it in w32_serial, 
posix_serial and i2c when I realized that I2C won't receive things "by mistake" 
since it is a master driven protocol, one could still use ioctl for incoming 
flush but I am unsure what is the best approach. Either flush() on an i2c 
device will just return OK and do nothing because i2c doesn't need flushing, or 
it should use ioctl just like flushing a serial port. Since I don't have any 
I2C-device to test on I am not sure how to go about this. Any suggestions?

Original comment by ledalert...@gmail.com on 9 Aug 2014 at 7:48

[GoogleCodeExporter]

Actually, further testing does not indicate the flushing was the issue, I will 
do some research when I can borrow a logic analyzer and see what's going on in 
reality. I will come back with fresh patches as soon as I have made sure 
everything works as expected.

Original comment by ledalert...@gmail.com on 9 Aug 2014 at 7:58