----- Ursprüngliche Nachricht ----- Von: Peter Bigot Gesendet am: 13 Dez 2011 15:05:09
> On Tue, Dec 13, 2011 at 5:42 AM, JMGross <msp...@grossibaer.de> wrote: >> It is possible that the re-fetching did not take place in early silicon. >> Entering LPM is just stopping MCLK, and why should an instruction >> be re-fetched when the MCLK speed changes (to 0Hz and back)? > One more try: interrupt service routines. Well, it makes no difference whether an ISR is executed a cycle sooner or later, as there are no assumptions at all in the code at which moment an ISR will happen (else one could save time by just using a function call). For asynchroneous interrupts, a slit of a MCLK tick may decide whether an interrupt event is scheduled on this or the next isntruction. However, there was a recommendation to put a NOP behind an instruction that clears GIE, because depending on the very moment an interrupt happens, it may be that the following instruction will be executed before the interrupt. And as you quoted before, GCC still has this NOP in its __disable_interrupt intrinsic (and others). However, this wasn't what I was meaning. Setting the CPUOFF bit is just switching off the CPU clock. One can think of it like a I/O pin controlled by a status register bit. And the I/O pin will switch off (gate) the MCLK generation. Without additional circuitry, when the clock reappears by an external event, it is as if no time has passed, the CPU core just continues. There was just an overlong CPU cycle. If an instruction ahs been fetched already, it will continue. To work around all implications that it is more than just an overlong clock cycle, a lot of additional circuitry is required. Which shall, in best case, not have any slowing influence on normal operation. Quite a difficult task. As one can see by the (relatively small) errata list. (see the current PC processors errata lists, they are books - even if 99% of them only are of importance for OS or driver developers, but that's what MSP developers are too) >> Well, the logical issues are a reason, but maybe nobody was thinking >> of them when implementing it first. > I really dislike the attitude that looks back on other people's work > and assumes they didn't know what they were doing. Oh, I do not assume that someone dosn't know what he's doing. But I know from experience, that people usually do not know or imagine how tomorrows requirements will influence todays work. Especially when under pressure. In an ideal world, the whole project and all requirements are known and fixed before the first concept for implementation is laid out. But we don't live in an ideal world, and often enough a new or changed feature 'must' be implemented when the product is almost in the shipping stage. So it's rather that they didn't/couldn't know where the will have to go when they did the first implementation. > If you read the erratum description carefully, CPU18 does not apply > when LPM is entered using immediate values, as with > __bis_status_register(LPM0_bits | GIE). I have confirmed this with > both positive and negative tests on a CC430F5137 with CPU18. You're right. immediate values are not triggering it. However, setting/clearing GIE alone is no immediate but a register mode operation (using the constant generator). Well, not for LPM, though. > I have not yet seen code that enters LPM in any other way. Not that > it isn't done, just that it is, in my experience, unusual. Me too. Since CPUOFF etc. is not available through the constant generator, I agree that immediate mode is the usual case. I wonder why register mode will affect it while immediate mode won't. Since immediate mode like all other but register mode, will do an additional data read. In the last years, I found so many errors in the MSP documentation, (while not much, considering the total amount of text) that I'm suspicious of the correctness when I encounter information that doesn't seem to follow a clear path. It's so easy to make a typo, and if there's nobody else who has the internal knowledge to notice it, it may go through undetected for ages. Happens to my own documentations too sometimes. >> I'm really sorry that I cannot use your compiler right now. >> But at the current state (with still many unresolved issues >> and a quick update cycle) I cannot convince anyone >> to using it in production environment. > FUD. This concern is addressed with the LTS release policy. I didn't read this policy, but anyway, the current version is still lackign some things (the fuill 20 bit support) which would make a good excuse for a migration. And since we (actually I) had to do a complete verification of all code parts for all old projects, I'll wait until I either must switch (e.g. for new chips that are incompatible due to required compiler workarounds) or just cannot resist anymore. However, it's not FUD. It's just the unquestionable fact that the two are not identical and therefore there are differences. And to ensure that existing code (we just cannot install a different compiler for each project) will work as before, every little bit would have to be tested and certified again before the new binaries are allowed to be used. (the problem is, that each new device gets its own binary compiled - the current system structure doesn't allow configuring them after production, and no two are 100% identical) To do so for each new 'stable' compiler version, well, it's just too much work. Which I had to do - and had to guarantee. > Since you have no experience with the current toolchain, though, I > would again appreciate it if you were more careful about projecting > your experiences with a four year old version into advice and armchair > diagnoses to people who are using the current, supported one. That's why I always (unless I forget) add that this is based on 3.2.3 > You are a highly respected member of the MSP430 community, > and people may mistakenly read more into your opinions and > recollections on this subject than is justified. That's why I never wanted to be a politician. :) I'll try to keep this in mind. JMGross ------------------------------------------------------------------------------ Cloud Computing - Latest Buzzword or a Glimpse of the Future? This paper surveys cloud computing today: What are the benefits? Why are businesses embracing it? What are its payoffs and pitfalls? http://www.accelacomm.com/jaw/sdnl/114/51425149/ _______________________________________________ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
