Hey, maybe I'm straying a bit from the conversation, but 1. Is there a way to obtain (and set) the registers? I want to try a feature where I create preemptive "threads", in which after certain interrupts, I will save the current context (registers) and the instruction line I was executing (which is already in the registers, the PC), and start executing from another address.. And when I'm done with that, reload the PC and all the other registers and resume working on that "thread"… I'm guessing that 8 * 16 = 128 bytes would be the least memory I would need for each context save. Is it not?
2. Where can I find tutorials or more info to read about custom linking scripts? I also want to try a feature where I have a base system setup and a special memory area reserved for a module, and when the base system receives a new module (with a flash memory proxy or whatever), it replaces the old one… I'm assuming the entry point for that module would have to be the same function name and the same memory address (is it not?) Best regards, --------------------------------------- Sergio Campamá sergiocamp...@gmail.com On Dec 6, 2011, at 11:10 PM, Wayne Uroda wrote: > Thanks. That is what I expected the wakeup keyword did so I am happy with > using it. > > I personally only use the critical and wakeup keywords. Of course putting > dint and eint calls at the start and end of the function is easy, but I > prefer critical as it saves the current state of GIE on the stack and pops it > on exit (whereas hand coding dint eint will always leave your function with > interrupts enabled). > > There is probably some easy macro I don't know about to push and then pop the > status register but if you push and then forget to pop I imagine you might > rip your hair out for a while trying to work out what is going on :) > > Our platform is fully hand coded from the ground up (custom C startup, custom > linker scripts, custom ELF based tools) to allow for custom bootloader / > firmware loading. So the critical and wakeup keywords will be the least of > somebody's worries should they ever need to port the code to IAR ;) > > - Wayne > > -----Original Message----- > From: pabi...@gmail.com [mailto:pabi...@gmail.com] On Behalf Of Peter Bigot > Sent: Wednesday, 7 December 2011 11:59 AM > To: Wayne Uroda > Cc: mspgcc-users@lists.sourceforge.net > Subject: Re: [Mspgcc-users] Enter LPM4 without missing the wakeup interrupt > > On Tue, Dec 6, 2011 at 5:53 PM, Wayne Uroda <wayne.ur...@grabba.com> wrote: >> Thanks for the discussion - I apologise for my code sample having flaws, it >> isn't production code just something I threw together to illustrate the >> point. In my case I am only interested in the level of the pin (sleep when >> it is low, awake when it is high) and so I am not concerned with missing >> edges other than the critical edge which brings me out of LPM4. I am aware >> that I still need to be careful of the order in which I enable the >> interrupt/clear the ifg and disable interrupts before finally checking the >> level of the pin and entering LPM4 if appropriate. >> >> One thing that I have never done is use the on_exit macro - I use the wakeup >> keyword instead - I'm guessing there are potential problems with the wakeup >> keyword? > > The wakeup function attribute in mspgcc is equivalent to having > "bic_status_register_on_exit(0xF0)" in your interrupt handler (and > LPM4_bits is 0xF0). There's nothing intrinsically wrong with it > except that it's opaque, and will only do exactly that operation, so > you couldn't (for example) clear GIE on exit using it. > > Personally I never remember what "signal", "wakeup", "reentrant", and > "critical" as function attributes mean exactly, and if I encounter > them I have to go read the compiler source to remind me what they do. > As far as I know they're also specific to mspgcc, so people who use > IAR or CCS won't understand what you're doing either. > > Peter > >> >> - Wayne >> >> -----Original Message----- >> From: JMGross [mailto:msp...@grossibaer.de] >> Sent: Wednesday, 7 December 2011 12:47 AM >> To: MSPGCC mailing list, >> Subject: Re: [Mspgcc-users] Enter LPM4 without missing the wakeup interrupt >> >> >> Hello Wayne, >> >> you correctly detected a possible problem in your code, which from my >> experience really is an exception. Most 'coders' don't >> care for realtime influences and then wonder why the code doesn't work (or >> use a watchdog do reset the CPU when the code >> unexpectedly 'hangs'. >> >> A generic solution to your problem has already beenb pinted out. Set LPM and >> GIE in the same instruction. >> Both, the LPM bits as well as GIE are located in the status register, so it >> comes down to an atomic operation: >> BIS #(LPM4|GIE), R2 >> >> In this case, if an interrupt happened before GIE is set and LMP is entered, >> the following will happen: >> GIE/LPM is set. >> LMP is exited, since an ISR is pending. (I'm not sure whether the DCO/XT >> wakeup time does apply in this case) >> the instruction after the BIS is executed (it aslready had been fetched >> before the BIS was executed, hence the usual NOP after an LPM entry) >> the status register including the GIE and LPM bits is stored on the stack >> GIE ans LPM bits are cleared >> the ISR is executed. >> >> If the ISR doesn't manipulate the stored status register copy on the stack, >> then when exiting the ISR, teh SR is restord and LPM/GIE are >> in effect again. >> >> So if you clear the LPM bits inside the ISR (using the proper 'on_exit' >> macro!), MSP won't return to LPM. >> >> However, your code example has several more flaws. >> - When your ISR does not clear the IFG bit for th einterrupt, the ISR will >> be re-entered as soon as it exits. >> If it does, the port1.ifg.pin1=0 assignment will clear a possible next >> interrupt, and you'll miss it. >> - you enable porti.ie.pin1 in every loop. It stays enabled (unless the ISR >> disables it) and interrupts may >> happen all the time (or after this point) independently of LPM4. You should >> clear GIE on exit of the ISR too, >> so when main is awakened, no further interrupts are handled unless you want >> them again. >> - you check for port1.in-.pin1. But even if an interrupt happened, P1.1 >> might have gone low again in the meantime. >> It's better to set a global flag inside the ISR (don't forget to mark it >> volatile) and check this. >> - depending on the compiler capabilities, the use of bitfields may result in >> less efficient code. >> That's one reason why bitfields for the many registers (especially ports) >> have been removed from the 'official' >> header files. Especially since every bit operation is a RMW >> (read-modify-write) operation on the whole register >> (which may have side-effects that are easily missed when one jus tlooks on >> the bit oepration). >> Also, since the registers are 'volatile', manipulation of multiple bits in >> the same register results in multiple >> RMW operations. Due to the volatile nature of the registers, the compiler is >> not allowed to group them. >> (the sequential access might be intentional). >> >> If you want to implement a debounce feature, a typical way to do it is to >> start a timer inside the port ISR >> and disable port interrupts (PxIE=0). >> When the timer expires, the tiemr ISR will check for the current port pin >> state, re-enable port interrupts and >> depending on the port pin state will set a global flag and end LPM. >> It gets a bit more tricky if you have multiple interrupt pins, but there >> have been implementations discussed >> and posted in the 'official' MSP forum: e2e.ti.com. >> >> JMGross >> >> >> ----- Ursprüngliche Nachricht ----- >> Von: Wayne Uroda >> An: mspgcc-users@lists.sourceforge.net >> Gesendet am: 06 Dez 2011 00:40:59 >> Betreff: [Mspgcc-users] Enter LPM4 without missing the wakeup interrupt >> >> I have a question which isn't technically related to MSPGCC (more of a >> msp430 question) but I thought one of you smart people >> might know. >> >> Imagine the following scenario: >> >> /* 1*/ while (1) >> /* 2*/ { >> /* 3*/ if (!port1.in.pin1) >> /* 4*/ { >> /* 5*/ // Enable interrupt (rising edge) for pin 1.1 >> /* 6*/ port1.ies.pin1 = 0; >> /* 7*/ port1.ifg.pin1 = 0; >> /* 8*/ port1.ie.pin1 = 1; >> /* 9*/ >> /*10*/ // Enter sleep mode, but only if the pin is still >> not high >> /*11*/ if (!port1.in.pin1) >> /*12*/ { >> /*13*/ LPM4(); >> /*14*/ } >> /*15*/ } >> /*16*/ >> /*17*/ // Awake >> /*18*/ // Do real work here >> /*19*/ } >> >> The ISR for port1 interrupt just wakes up the processor from LPM4 and clears >> the IFG for pin 1.1. >> >> The problem I see is that there is a small window (between the execution of >> line 11 and line 13) where pin1.1 can go high, have >> the ISR handled and the IFG cleared, and then the system can incorrectly go >> into LPM4 even though pin1.1 is high. >> >> My thoughts are that the only way around this is to avoid using LPM4 and >> poll the state of pin 1.1, which is what I have done in >> previous designs. As far as I know there is no way to atomically enter LPM4 >> and enable interrupts so that the pending pin1.1 >> IFG can be handled AFTER entering LPM4, thus bringing the system out of LPM4. >> >> Has anybody come up against this? Is using LPM3 the best/only workaround? >> >> I am using 1 family chips, MSP430F148 in particular. >> >> Thanks, >> >> - Wayne >> >> ------------------------------------------------------------------------------ >> All the data continuously generated in your IT infrastructure >> contains a definitive record of customers, application performance, >> security threats, fraudulent activity, and more. Splunk takes this >> data and makes sense of it. IT sense. And common sense. >> http://p.sf.net/sfu/splunk-novd2d >> _______________________________________________ >> Mspgcc-users mailing list >> Mspgcc-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/mspgcc-users >> >> >> ------------------------------------------------------------------------------ >> Cloud Services Checklist: Pricing and Packaging Optimization >> This white paper is intended to serve as a reference, checklist and point of >> discussion for anyone considering optimizing the pricing and packaging model >> of a cloud services business. Read Now! >> http://www.accelacomm.com/jaw/sfnl/114/51491232/ >> _______________________________________________ >> Mspgcc-users mailing list >> Mspgcc-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/mspgcc-users >> >> ------------------------------------------------------------------------------ >> Cloud Services Checklist: Pricing and Packaging Optimization >> This white paper is intended to serve as a reference, checklist and point of >> discussion for anyone considering optimizing the pricing and packaging model >> of a cloud services business. Read Now! >> http://www.accelacomm.com/jaw/sfnl/114/51491232/ >> _______________________________________________ >> Mspgcc-users mailing list >> Mspgcc-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/mspgcc-users > > ------------------------------------------------------------------------------ > Cloud Services Checklist: Pricing and Packaging Optimization > This white paper is intended to serve as a reference, checklist and point of > discussion for anyone considering optimizing the pricing and packaging model > of a cloud services business. Read Now! > http://www.accelacomm.com/jaw/sfnl/114/51491232/ > _______________________________________________ > Mspgcc-users mailing list > Mspgcc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mspgcc-users ------------------------------------------------------------------------------ Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ _______________________________________________ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
