43oh

# tripwire

Members

193

14

## Reputation Activity

1.
an anti static bag is a Faraday cage.  The idea isn't to throw the device into a cage at the last minute, but rather to build the shielding into the device itself so that it is always protected.  Obviously this is impossible for devices that require wireless communication, but it is possible to isolate the main electronics (e.g. with optoisolators) from the RF side such that only one small piece of the system is vulnerable.  Even then, it depends on the strength of the EMP, and circuits can be electrically hardened to tolerate the transients produced by the pulse.  So in an idea device, you would have sensitive electronics shielded inside a robust Faraday cage, coupled non-electrically to hardened electronics that cannot be shielded.

Electronics can be designed that can function (not just survive powered down) in very strong fields and perform quite happily.  Of course this level of engineering is quite involved and expensive, which is why these things only exist in applications that require them.
2.
I wouldn't know why not. A small resistor calculation would give:
3v3/47k = 70uA even if the launchpad would have a resistor on this pin elready, the accumulated current would be about 140uA. There is no problem for the MSP to drive such a pin (I say this, because the programmer part of the launchpad is another MSP430).
3. tripwire reacted to cubeberg in Int To Hexa ?
Are you looking to convert it to hex in a string or to display somehow?  The int value itself isn't specifically decimal or hex - those are just ways of displaying a certain value.
4. tripwire reacted to roadrunner84 in Int To Hexa ?
So.... where do you need to "convert to hex"? I see you writing a lot of bytes in the 0xAB form, but that is just the representation, sending 0x7F is the same as sending 127; both are the same number.
The only place where you actually would need to convert to hex, is where you'll need to print (or write human readable over serial) numbers which must be hexedecimally represented, I failed to find such a requirement in your code. I mean, you are actually sending bytes which are not human readable, so the rest of the data in between doesn't have to be human readable either, right?
5. tripwire reacted to roadrunner84 in Int To Hexa ?
Wait, what are you doing here?! you do a constant division by a number that is a power of two!
Also, you state that the result (?) of this division is in the range 0 to 127 (7 bit), so basically you're dropping the least significant (LSB) three bits  of a short integer (in a long variable)!
Could I suggest using
unsigned char sensor1Valor; sensor1Valor = analogRead(A3) >> 3; // shift 3 bits to the right, dropping the 3 LSB; effectively divide by 8 // using "analogRead(A3) / 8" might just be compiled to the very same thing, and may be more readable to you Also, your address bytes are stored in long integers, use unsigned char for that, as that is the suitable range for your address bytes.
6. tripwire reacted to roadrunner84 in Low Power Mode
It is true that _BIC_SR_IRQ() can be called only from the ISR (interrupt service routine) but not from any functions called from within that ISR. As the ISR are part of the Energia library (as you state, in winterrupts.c) you cannot influence SR with _BIC_SR_IRQ() from within the attached function.
As a suggestion to the energia team, how about having attached functions returning true or false (or sleep or wakeup when using an enum), where either of these will wake from LPM and the other doesn't?
Returning to sleep from an interrupt should be reliable behaviour, it is part of the MSP430 processor architecture and cannot be overridden by the IDE, library or compiler. If you don't have reliable wakeup behaviour, you probably have wakeup behaviour inside your library (winterrupts.c probably).
I am using LPM extensively in my watch firmware, even stronger; I do not have any "main loop"! After initialisation, the main() function will go in low power mode and none of my interrupts will ever wake it; all code is inside the interrupts.
7. tripwire reacted to grahamf72 in Low Power Mode
I had a bit of spare time on my hands today, so had a bit of a play with activating low power modes.  I had a basic clock sketch that I had been using to test the RTC library that I posted on the RTC thread, and modified it a bit to see if I could get it to still work in low power mode.

I discovered a few things about Energia in the process, so it was quite a productive day of play. Here are a few of my notes which hopefully will be of benefit to some others.

1. I was originally relying the Energia function millis() to do software switch debouncing.  The function millis() derives its count from the WDT timer triggering an interrupt at 31.25khz (on 16MHz devices such as MSP430G2553).  The timing is derived from SMCLK which is in turn derived from the DCO clock. In LPM3 the DCO is disabled, so the interrupt is not called, meaning millis() no longer works. I did consider changing the WDT to get its signal from ACLK but because the smallest divider is 64, the WDT would only be called 512 times/second instead of 31250 times/second, making millis() and delay() inaccurate by a factor of ~60. Instead I changed my logic so that once a switch was pressed it stayed out of low power mode until the user had finished. Alternatively, because the 430 has Schmitt inputs, I could do hardware debouncing quite easily with just a capacitor & resistor.

2. Inside an ISR, further interrupts are disabled, so although the DCO & SMCLK are running inside the ISR, millis() still won't work, because the interrupt will not be called. In theory delay() should work as it re-enables interrupts, however I found it to be unreliable, possibly because I was getting re-entrant problems. delayMicroseconds() works for short delays, as it is a simple loop that relies on the time instructions take to execute.

3. According to the mspgcc documentation, when an interrupt is called during low power mode, it should return to low power mode when the ISR finishes. My experiments seem to indicate that this behaviour isn't reliable.  My interrupt running off the A0 timer seemed to return to the LPM about 3 times in 4.  The pin interrupts seemed to never return to LPM. I have looked over the code in wiring.c & winterrupts.c and cannot see why this should be the case. In any case, it is a positive, because after a pin interrupt triggers, the loop() continues to run, allowing it to do other useful functions.

4. According to the mspgcc documentation you can override the Low Power Mode when an ISR exits by using the pseudo-function _BIC_SR_IRQ().  This function can only be called from an ISR. This works from within the ISR that I created for the RTC library, however it does not work if you use AttachInterrupt() to attach an interrupt to one of the 430's input pins. The reason being that the ISR is buried in WInterrupts.c, which then calls the user function. Although I cannot see any code to cause it, the ISR that handles input pin interrupts leaves the system at full power when it exits. This is fortunate, as otherwise there would be no way to resume the system to full power after a pin interrupt.

So putting it together, the basic guidelines that I have worked out for using low power mode are:
In your setup() function, configure the interrupts that you need - eg Attach interrupts to your pushbuttons
If you want a timed interrupt, configure it to run off ACLK & configure ACLK.
Set your Low-Power-Mode in loop() as per the below - this way after an interrupt runs, your loop() will continue.
void loop() { //put code here that will run on the first pass of loop, and every subsequent loop //... _BIS_SR(LPMx_bits | GIE); //Turn on low power mode // Execution will stop at the _BIS_SR line above. // Any code here will not run until AFTER an Interrupt has triggered and // the ISR has finished running. // If an Interrupt is never triggered, this code will never run. // ... }
The low power modes are as follows:
LPM0_bits - Low power mode 0 - the CPU & MCLK are disabled, SMCLK & ACLK still run. This means the WDT will still run and generate interrupts at 31.25kHz
LPM1_bits - Low power mode 1 - the CPU & MCLK are disabled. The DCO will also be turned off if SMCLK isn't derived from it. Because Energia derives the SMCLK from DCO, DCO will still run, as will the WDT interrupts. With the standard Energia clock setup, this becomes identical to LPM0
LPM2_bits - Low power mode 2 - CPU, MCLK, SMCLK & DCO disabled, DC generator still runs (The DC generator is used for the DCO). ACLK still runs.
LPM3_bits - Low power mode 3 - CPU, MCLK, SMCLK, DCO & DC Generator disabled. ACLK still runs. The difference between this and LPM2 is that with the DC generator disabled, the DCO takes a little longer to start back up.
LPM4_bits - Low Power mode 4 - all clocks (including ACLK) are disabled. In this mode no timing functions will operate - the CPU can only be woken up by a pin interrupt.

Attached is my clock example that uses my RTCplus library (attached to one of my posts in the RTC thread) to display date and time on a 16x2 LCD and allow date and time to be set with a pair of buttons. My earlier version of this that didn't switch to low power mode was using 5mA as measured with a DMM across the VCC jumper on the launchpad (not including the LCD display current). By converting this to low power mode, consumption dropped to 2uA measured on my DMM. Each second as it ticks, my DMM spikes up to about 300uA. The actual consumption during the tick is probably closer to 5mA but for such a short time my DMM couldn't catch it. If you want to test this example, you will need to amend the RTCplus header so that the line "#define RTCSUBSECONDS" is commented out.

Using LPM requires a bit of thought about what functions will run when, but for a task that only needs to do something infrequently or responding to user input, it can make a huge difference to the power consumption.

sketch_Low_Power_LCD_Clock.zip
8. tripwire reacted to oPossum in Int To Hexa ?
void uint32hex(uint32_t x, char *s)
{
unsigned n = 8;
s += n;
*s-- = 0;
do {
*s-- = "0123456789ABCDEF"[x & 15];
x >>= 4;
} while(--n);
}

9. tripwire got a reaction from RobG in Value line errata updated - new BCL12 workaround
Hi guys,

I just noticed that the errata files for the value line were updated on 17th January. The new files contain a revision to the BCL12 text, adding the following advice:

"In the majority of cases switching directly to intermediate RSEL steps as described above will prevent the occurrence of BCL12. However, a more reliable method can be implemented by changing the RSEL bits step by step in order to guarantee safe function without any dead time of the DCO."

Might be of interest if you've been getting DCO lockups as I have recently!
10. tripwire got a reaction from bluehash in Value line errata updated - new BCL12 workaround
Hi guys,

I just noticed that the errata files for the value line were updated on 17th January. The new files contain a revision to the BCL12 text, adding the following advice:

"In the majority of cases switching directly to intermediate RSEL steps as described above will prevent the occurrence of BCL12. However, a more reliable method can be implemented by changing the RSEL bits step by step in order to guarantee safe function without any dead time of the DCO."

Might be of interest if you've been getting DCO lockups as I have recently!
11.
With a resistor, so to sum it up:
+---\_/---+ | MSP430G | | | | /RST |---------------+--[47k]--(+) | | | | TEST |--[47k]--+ --- C | | | --- +---------+ | | === === get it? ;-)

Leaving TEST open might work just fine, but you may sometimes boot up and get "stuck" in bootloader/SbW/JTAG mode, pull it down for more robust booting behaviour.
×
• Blog

• #### Activity

×
• Create New...