> .You are right about the fragility of this development. > A response to the " segmentation error issue " from one of the developers > Dmitry <di...@mail.ru> was and I quote. > "I cant help here, cause I'm not running windows" > Yet In the download web page Dmitry is given credit for the port toWindows > > I understand this is a free platform and that we should expect to get what > we paid for. However this is was promoted in Circuit Cellar in an article > about MPS430 and also at the mikrocontroller web site from which it was > downloaded. The article and the website say it is windows compatible > Some will always shoot or impune the messenger or grasp at any convenient > reason for the lack of results. Some will feel that the reporting of a > defect by a user brings with it the obligation for that user to undertake > fixing it. If this is the philosophy of this development group it will have > a chilling effect on the quality of the end product. Perhaps it already has > since the fact is this doesn't at the moment work reliably across Windows. >
The msp430 gcc and gdb ports are perfectly usable on Windows, as long as you use real windows (NT, W2K, and possible XP) rather than toy windows (Win9x, including WinME). As far as I know, the compiler itself is fine under Win9x, but some people have trouble with gdb (and in particular, Insight). For some, it works fine, and for others it is unstable or fails to work at all - that's life with Win9x. It would be nice if Circuit Cellar and mikrokontroller made this a bit clearer, but then almost nobody considers Win9x to be a sensible choice of platform for serious development work. You will not find any modern commercial development software (for embedded development or otherwise) which lists Win9x as "recommended" - indeed, you will find very little modern software, except perhaps games, that recommends Win9x. Although most software will normally run on it, you must be prepared to accept problems and crashes with no apparent justifications - and that applies to simple word processors or web browsers, never mind development tools. Just ask Microsoft technical support how to improve the reliabilty of your Win9x system - the two suggestions will be to format the disk and re-install windows, or to upgrade to XP. Fighting with the inconsistencies and instabilities of Win9x is a waste of time for the msp430 gcc and gdb developers - they have plenty of far more useful work to do on the tools themselves. The tools rely on basic functionality being available in the underlying system - Linux and other unix-type OS's provide such functionality natively, and NT (including W2K and XP) provide most of it, while Win9x cannot provide reliable OS services such as process seperation or multi-tasking. The gdb tools use cygwin to provide the OS services on top of the underlying Windows system - for NT, this is can be done reliably since much of the groundwork is provided by NT. But Win9x is missing so much that by some definitions it cannot be classified as an operating system (after all, even WinME is fundamentally 16-bit single-tasking DOS with a partially 32-bit gui on top). Cygwin has only recently been able to work well on Win9x, and is regularly updated with fixes and improvements on Win9x. This is something that the Cygwin developers are working hard at, and the msp430-gcc developers can and should pretty much ignore Win9x-specific issues. So if you want to try using Win9x for development work, then by all means try, and let others know of your successes or failures. Sometimes there will be small things that can been done to fix problems, or there will be work-arounds. You can help by ensuring that you have the latest version of cygwin first - that can make a big difference. But if you really want to use a computer for work, and want to be able to rely on it, then switch to W2K (or, obviously, Linux, *bsd, etc.). Don't blame the msp430-gcc developers for MS's failures, and don't make the mistake of mixing up problems with individual Win9x systems with a working Windows port of the software.
