in which Windows terminal you are running make? Cygwin or something similar? There is a shell message /usr/bin/sh: bin/check_qspi_crc: No such file or directory
I did test it just in Windows terminal (cmd)
I did it also in Windows terminal cmd, no Cygwin.
Now i moved the Github-Content from the MinGW directory to my users directory,
did am 'make clean', and another 'make', but i get the same error.
Well, this is exactly the thing, which makes using of Linux machines much easier for embedded software development.
Did you check your PATH Windows environment variable, does it have usr/bin somewhere?
I don't use WIndows PC for embedded SW development, so I'm afraid that I have no idea how to fix.
But in any case tools from /bin folder should be updated to work in Windows, so that is another challenge
There had been 'WinAVR-20100110\' in the path (but no usr/bin !), containing also some Unix-style commands.
For testing I changed your 'setenv.bat' temporarely to
many thanks for checking this!
It is reassuring that both files are executable.
Also interesting, that the sizes reported by the DM42 also differ from the sizes within Linux (ls).
many thanks for checking this!
It is reassuring that both files are executable.
Also interesting, that the sizes reported by the DM42 also differ from the sizes within Linux (ls).
Thomas
Building images from the same sources using gcc running on Linux and Windows producing different binary results does not necessarily mean something is configured wrong on one of those platforms, gcc has done this since the mid-90's at least. I'd guess it's differences in the libraries, but never found answers (after a lot of looking) but in the end, both images worked OK.
many thanks for checking this!
It is reassuring that both files are executable.
Also interesting, that the sizes reported by the DM42 also differ from the sizes within Linux (ls).
Thomas
Building images from the same sources using gcc running on Linux and Windows producing different binary results does not necessarily mean something is configured wrong on one of those platforms, gcc has done this since the mid-90's at least. I'd guess it's differences in the libraries, but never found answers (after a lot of looking) but in the end, both images worked OK.
Thanks for the background information!
Ultimately, it is crucial that the images are executable.
Some more hints for recommended working envorinments (e.g. from David and/or Michael) are very welcome!