[refactoring] Optimisation for processing chipid files

[Sylensky]

Hi everyone,

during my work i made some changes to the stlink library which i thought of would benefit the overall project.
These changes include optimizations in the processing of chipfiles and in a seperate PR the addition of option byte descriptions.

• printing processed chipfiles only when it makes sense (not in st-info --version)
• moved the dump chip printout from stderr to stdout
• the chipfile read buffer was quite large for a rather small file and since its processed line per line it doesn't make sense to define the buffer that large. (maybe i made it too small when someone adds a rather big description in the chipfile?)
• sscanf already looks for spaces and seperates them so there was no need to explicitly look for spaces in my opinion
• the filedescriptor wasn't closed after the file has been processed. - fixed that

[gszy]

Hi @Sylensky, thanks for your contribution. I’ve left a few comments in the changes.

[gszy]

I’m sorry for the delay, I hope I’ll be able to review this PR next week.

[Nightwalker-87]

Yes, there is nothing else I can report from my side actually... 😔
@Sylensky Please stay tuned - it will remain on our ToDo list.

[gszy]

Well, no luck, I won’t have enough time. Just one more thing I’ve spotted: the new small buffer size may cause issues on lines having long comments.

[Sylensky]

I thought about that aswell. Making it double should totally be enough. Or do you see a case where such long comments might still be useful?

[gszy]

I’m not sure about its usefulness, but FWIW here F76x_F77x.chip has quite a long line:

stlink/config/chips/F76x_F77x.chip

Line 12 in 8d96e76

option_base 0x1fff0000 // STM32_F7_OPTION_BYTES_BASE /* Used for reading back option bytes, writing uses FLASH_F7_OPTCR and FLASH_F7_OPTCR1 */

[Sylensky]

I checked the other files and the F76x_F77x.chip has the longest line so far. Choosing a buffer size of 256 should be in my opinion enough even if there is going to be more description on a line.