thanks4opensource / buck50

STM32F103 logic analyzer and more
GNU General Public License v3.0
565 stars 57 forks source link

interested in Windoze support? #8

Closed nerdralph closed 3 years ago

nerdralph commented 3 years ago

Despite your comments about the difficulty supporting Windows, my initial scan of buck50.py doesn't show many Unix dependencies. I've used pyserial for utilities that run on Windows and Linux. https://github.com/pyserial/

If you're interested in Windows support, I'm willing to work on the mods and send a pull request when it's done.

BTW, buck50 builds with only a few warnings using arm-gcc 5.4.1 under mingw.

thanks4opensource commented 3 years ago

Thanks for the offer. I don't know if "interested" is the right word -- I wouldn't have any use for it, and feel that Windows users have plenty of alternatives available to them so don't need this project's firmware/software. But if the changes/patches/pull-request isn't overly invasive I'd be open to integrating it.

If pyserial creates an integer file descriptor that can be used with the various os module methods (os.write(), etc) it should be fairly easy. buck50.py only creates the global usb_fd descriptor from the NIX /dev/... device special file in a few places. But it does then use it heavily. That's what I meant by "invasive", above. If the changes are just automatically detecting Windows and calling pyserial instead of os.open(), etc. in those few places, that would likely be acceptable. If it's bracketing every use of usb_fd with if windows: ... else: ... then likely not. Of course I'd also appreciate it if the changes were kept to a minimum -- no swapping all the NIX line endings to DOS, no replacing spaces with tabs and/or changing the indentation/formatting, etc. If not you can always maintain a separate ported repository as long as it respects the code's license and credits the original authorship.

I also have a small pending update to buck50.py (fixes a help system typo plus a very unlikely bug that I doubt anyone has hit). If you can hold off a day or two until I get it pushed up it would make any potential merges easier.

I would be interested in seeing the arm-gcc 5.4.1 warnings when compiling buck50.cxx and/or buck50_asm.s . It's always good to have a cross-check using different compilers. The makefile in this repository has both "-Wall" and "-Wextra" turned on, and I've built using gcc-arm-none-eabi-8-2018-q4-major and gcc-arm-none-eabi-9-2020-q2-update without warnings. If the numbering scheme is consistent, "5.4.1" seems quite old. But again, if the warnings are valid and the changes minor I'll consider handling them.

nerdralph commented 3 years ago

"Interested" is the right word for the question I was asking. I wondered if you have a disdain for Windows, which is why I asked the question that way. I avoid C/C++ development on Windows, but for languages like PERL or python I'll try to support Windows when it can be done cleanly. I can't promise I'll be able to test and maintain Windows compatibility in the future, so Windows support doesn't seem like a practical idea.

As for the warnings, here they are:

src/buck50.cxx: In function 'PeriphStatus i2c_master_addr(uint32_t, uint8_t, uin
t8_t, uint8_t)':
src/buck50.cxx:1851:17: warning: attributes at the beginning of statement are ig
nored [-Wattributes]
                 [[gnu::fallthrough]];
                 ^
src/buck50.cxx:1840:25: warning: variable 'reader' set but not used [-Wunused-bu
t-set-variable]
     volatile uint32_t   reader;