----- Ursprüngliche Nachricht ----- Von: Grant Edwards Gesendet am: 16 Mrz 2011 17:51:51
>>>> It's not only that the datasheets talk about disabling the watchdog. >>>> Disabling an already disabled watchdog does no harm. >>> neither is enabling it again a problem, if you actively want to use it. >> But not enabling it when the docs say it is enabled > What docs say it's enabled when main() is entered in an app built with > mspgcc? The processor datasheet says that after a BOR/POR/PUC the WDT is enabled. Disabling it by inherently placed default compiler code, especially if this is neither well documented nor easily to prevent, is worse than bad. > IMHO, leaving it enabled during startup would have been more > desirable. Not only more desireable, but a MUST. > I think a way to prevent the startup code from disabling > the WDT is an absolute requirement. indeed. Here we totally agree. > But, as long as there's a way to get either behavior, I don't think > changing the default behavior should be undertaken lightly. Not if 'the way' means writing your own startup code (in assembly language) or using compiler-specific switches, attrivutes and other things, just to get the expeccted default behavior. besides being less than not obvious, it also digs the gap between mspgcc and the 'official' MSP compilers even deeper. >> However, being unprotected for some milliseconds (which is an >> eternity) while you think you are, isn't good. In fact, it is way >> worse than being protected when you don't think you are :) > Is an option to prevent the WDT from being disabled by startup code > insufficient for that scenario? Yes, if it is not the default behavior. Imagine a PC where the BIOS will silently switch off the UDMA without an option to enable it, and probably without telling you at all. Saying that you can write your own driver for the controller and enable it again wouldn't be a viable option for the typical user who just wants to use the PC. Luckily, there's an OS that will likely come with the driver. But on MSP, there is no OS, only the user code. And on mspgcc there isn't even an IDE that will act like a BIOS setup. (and while a slow HD while booting the OS is a nuisance, a disabled WDT is much worse) >> Using a WDT for dixing software bugs is very bad style. What happens? >> The device resets and runs into the same condition again. It's a >> dirty way to 'fix' defective code or faulty program design. > One might claim that having a backup generator available to power the > cooling pumps in a nuclear reactor is "bad style" too, but I'm not > going to argue against that! No, this kind of backup is agains hardware failure, not against conceptional flaws in the design of the cooling system. This WDT use is rather like designing the power cords to the pumps too thin and adding a thermal-triggered switch to shut off the pumps if the wires got too hot until they cooled down again. (you can imagine what happens to the reactor during this shutoff time) ----- Ursprüngliche Nachricht ----- Von: Peter Bigot Gesendet am: 16 Mrz 2011 14:03:36 >> I doubt anyone will try to directly compile a linux program or even an old >> DOS program for the MSP. > That's the sort of assumption I'm not willing to make. There's a lot > of working code out there, and a definite value in portability and > conforming to what the C and C++ languages require regardless of > platform. While I agree with you, it doesn't hit the point. Compiling a DOS/Linux program for MSP is like trying to compile a Fortran program with mspgcc, expecting it to work. We don't talk about machine independent functions here, it's about the system startup. It's like expecting windows working flawlessly when you just move the system HDD from one system to a different one with completely different hardware (maybe not even an x86 processor). But that's getting us too far: > My goals are: [...] and I fully agree with them. >> Of course proper documentation is required for any implementation. >> And with 'proper' I don't mean a one-liner in the mspgcc source code, >> but rather an exhaustive explanation in a real manual that's available >> without Wiki, mailing list or digging through repository reports. > There is in fact a real manual for mspgcc, in docbook format, which > I've placed in the mspgcc git repository and am slowly bringing up to > date as I make changes. The original version is on the web at > http://mspgcc.sourceforge.net/manual/, I didn't want to criticise you in any way, and I really appreciate your work, including this topic. It's just my experience with many free/openSource/whatever projects, that the documentation is focused on the features the developer is proud of, but doesn't cover details nor is it understandable for non-developers or covers possible pitfalls or side-effects. > and it should be easy to put > the generated html and even pdf versions into distributions. That's what I meant - currently you're lost with no complete documentation. Lately I got hodl of the documentation of the CSS compiler (which I don't have) and it is really interesting and exhaustive. It doe snot, however, clearly state that it does not implement any C++ standard. It just refers to K&R when it describes what is implemented (which does not mean that all is implemented) It also covers the fact that CSS is NOT initializing the uninitialized data area to 0 (as all other C compilers do), probably for startup speed reasons (WDT). When someone brought this topic, It took me just 5 minutes to get the docs online and find the chapter. (if I had had the compiler, it would have been faster) of course it is a commercial product and there are people dedcatedly working on the docs. >> BTW: the other compilers for MSP (IAR/CCS) enter LPM4 on main exit >> as default, rather than jumping in place. > I find this comment compelling too. > Although TI recommends: > bis 0xf8, sr > to enter LPM4, my preference is: > dint > bis 0xf0, sr > so that any maskable interrupts left enabled by the application don't > cause the MCU to start running through the constant section. The idea > is you only get going again through an NMI which inherently jumps to > the reset vector. > Comments on this? I really don't want another variation point where > you get to specify a branch destination to follow the LPM4 code > through some sort of compiler directive. Both may have a reason. Some people just expect the ISRs to continue even if main() has done its job of initializing the hardware. Some might put an LPM_EXIT code into the ISRs and wakeup the processor from LPM, lettign it run into the void. I'd neither set nor clear the GIE bit on main exit. But add another jump $-2 behind the bis '0xf0,sr', so if an ISR exits LPM, the MSP will enter it again. Anyway, for most interrupts (such as timers), LPM4 might be too deep, as it disables the oscillators, effectively stopping the timers (unless the clocks are unconditionally requested) P.s.: on devices which support LPM4.5, a port interrupt will cause a POR. This is, however, something the user has to initiate, and doesn't touch the end of main. ------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d _______________________________________________ Mspgcc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mspgcc-users
