Running a microcontroller in car - power supply aspects

[Curious.George]

8<

  GIMSK &= (0 << PCIE);  // no more Pin Change interrupts; mask them off

What do you think THIS ^ does?

8<

  GIMSK |= (1 << PCIE);  // unmask Pin Change interrupts; Interrupt source

This suggests PCIE is a small integer (I don't use those processors)

[redwire]

Those are bit-set and bit-clear instructions directly to MCU registers. What you are doing is reading the register, OR'ing 1 with the bit you want to (set) to a 1 (or AND'ing 0 with the bit you want to (clear) to a 0), and then writing that result back to the register. So you leave all other bits in the register alone, just bump the one you are interested in.

The Arduino IDE has all the MCU registers (for ATmega328 or ATtiny85 etc.) defined internally I think in <avr/io.h>. All capital letters are traditionally used for constants.

For the ATtiny85:
GIMSK is the MCU General Interrupt Mask Register at address 0x3B, and within it is
PCIE is the 5th bit position of GIMSK, "pin change interrupt enable bit"
PCMSK is the MCU Pin Change Mask Register, selects which pin(s) will generate a pin change interrupt.
sorta explained here: https://thewanderingengineer.com/201...s-on-attiny85/

Doing the same with the ATmega328:
PCICR is the MCU Pin Change Interrupt Control Register, choose the port A,B or C.
PCMSK2 is the MCU Pin Change Mask Register, choose which pin(s) will generate a pin change interrupt.
example here: https://thewanderingengineer.com/201...ge-interrupts/

In a nutshell, just turning on pin-change interrupts for the pin, the port, the CPU. So when the MCU is asleep, it gets woken up by the Ignition pin going from low-> high (DannyX is opto inverted so high->low).

[Curious.George]

Originally Posted by redwire

Those are bit-set and bit-clear instructions directly to MCU registers. What you are doing is reading the register, OR'ing 1 with the bit you want to (set) to a 1 (or AND'ing 0 with the bit you want to (clear) to a 0), and then writing that result back to the register. So you leave all other bits in the register alone, just bump the one you are interested in.

I understand that's what you THOUGHT you were doing. But, in practice, you're NOT!

PCIE is the 5th bit position of GIMSK, "pin change interrupt enable bit"

If PCIE is actually defined to be "5" (and not 00100000r2 = 0x20), then:

GIMSK &= (0 << PCIE)

is actually:

GIMSK = GIMSK & (0 << 5)

which is:

GIMSK = GIMSK & 0
// 0 shifted left 5 times is still 0

which is:

GIMSK = 0

(i.e., each bit in GIMSK is anded with a 0, yielding a 0 in that bit position)

Again, assuming PCIE is "5", the second quoted line is correct:

GIMSK |= (1 << PCIE)

is actually:

GIMSK = GIMSK | (1 << 5)

which is:

GIMSK = GIMSK | 0x20

which ensures "bit 5" is set in GIMSK regardless of whether or not it was set (or clear!) previously.

The FIRST line of code should have been:

GIMSK &= ~(1 << PCIE)

which is:

GIMSK = GIMSK & ~(1 << 5)

which is:

GIMSK = GIMSK & ~(0x20)
// 0x20 is 00100000r2

which is:

GIMSK = GIMSK & 0xDF
// 0xDF = 0x11011111

In other words, "ensure bit 5 is clear regardless of whether it was set (or clear) previously."

You can test this with a trivial program:

// ensure ALL bits are set just so we can see which one(s) change
foo = 0xFF;
foo &= (0 << 5);
printf("Foo is %d.\n", foo);

foo = 0xFF;
foo &= ~(1 << 5);
printf("Second foo is %d.\n", foo);

[redwire]

I think you're right, I looked at the code and it would never shut off the pin-change interrupt on the Ignition switch input. It's been in the car for 2 years with no fatal troubles (i.e. dead car battery). The only thing I've noticed is if the MCU (accessory timer) is running and then I start the car, sometimes the stereo will cut out and then reboot- which I attributed to my old car battery dropping too low during cranking. But that might be an ignition off->on->off (during cranking)->on (engine running). Three pin change interrupts.

If I am (wrongly) globally shutting off interrupts, the Arduino libraries must overwrite that, as I get serial I/O fine after waking up from sleep.

[Curious.George]

Originally Posted by redwire

If I am (wrongly) globally shutting off interrupts, the Arduino libraries must overwrite that, as I get serial I/O fine after waking up from sleep.

Dunno as I have no experience with that hardware nor the "system" software.

If you have access to ALL of the sources, you might try to search for "GIMSK" anywhere in them and manually examine each such reference to see when it may be taking effect.

[One problem with MOST software is there's never a useful "roadmap" that lets you figure out WHERE to look when you have a problem.]

The other thing you can try (brute force) is littering YOUR code with tests to check the value of GIMSK at convenient places. And, whenever it "looks significant", emit a message, blink a light, HALT the processor (so you can figure out WHERE the test came back "positive").

[I don't know what sort of debug environment you have available]

[Dannyx]

Yeah, I've got some massive learning to do...that went way over my head really quickly Bits and registers and stuff...

I may also have to learn something about PICs in the future, having come across one in a control panel for one of those pump systems I talked about in another thread...we know nothing about what's on there and how it works yet, so that will be my job...

[Curious.George]

Originally Posted by Dannyx

Yeah, I've got some massive learning to do...that went way over my head really quickly Bits and registers and stuff...

I may also have to learn something about PICs in the future, having come across one in a control panel for one of those pump systems I talked about in another thread...we know nothing about what's on there and how it works yet, so that will be my job...

PICs are a lousy place to start as their architecture is really quirky.

If you have NO experience with CPUs/software, your best bet is to pick one of the "classic" processors (1970-80 vintage) with more regular instruction sets and programmer models to "cut your teeth on".

If you could find a copy of the 6800 Microprocessor Applications Manual (that's 6800 not 68000!) it can almost act as a textbook to expose you to the issues you'd need to know. It's long but is an easy read.

Caxton Foster's (poorly named) Real-Time Programming is another quick read.

[stj]

hell no,
start with 6502 - get yourself a commodore64.

[Dannyx]

Originally Posted by Curious.George

PICs are a lousy place to start as their architecture is really quirky.

It's not about "starting" anything - it's already in place and I have to (at least) somehow back up what's on it, if at all possible, should the whole box fail and need replacing....at which point it'd probably be easier and cheaper to rebuild it from scratch using something I'm more familiar with...

[Curious.George]

Originally Posted by stj

hell no,
start with 6502 - get yourself a commodore64.

You may as well push for a 2A03! <frown>

The 6502 is almost as quirky as a PIC and omits many of the features that are now commonplace in MPUs and MCUs.

While the dual accumulator 6800 is a throwback to the past, the SINGLE accumulator 6502 is even worse! EVERYTHING had to go through the accumulator.

You also lost the advantage of the index registers (now commonly used for structure member references as well as accessing the stack frame).

And, of course, the 6502 had a crippled stack (8 bit SP).

The 6502 belongs cleanly in the past, having failed to anticipate any of the more modern features in processors (micro- or otherwise)

[Curious.George]

Originally Posted by Dannyx

It's not about "starting" anything - it's already in place and I have to (at least) somehow back up what's on it, if at all possible, should the whole box fail and need replacing....at which point it'd probably be easier and cheaper to rebuild it from scratch using something I'm more familiar with...

Did you note the sentence that followed: "If you have NO experience with CPUs/software, your best bet is ..."? If you "start" your education on a PIC, you will find "real" processors to be confusing in their more orthogonal designs. The same is true if you start with a single-accumulator design (even if it has TWO accumulators) and then move to a register-file design. There are very different ways of thinking about solutions based on the programmer model you're faced with.

[Dannyx]

Not wanting to give up just yet and also to hopefully get at least close to understanding stuff like in post #143, I briefly looked into registers and binary and stuff like that, since I know nothing about that, though I only did it strictly concerning this project for now, nothing too in-depth.

From what I gather, putting an Atmega328p to sleep involves setting the bits in SMCR (Sleep Mode Control Register) in a certain way, depending on how "deep" you want it to sleep and how many features you need disabled to save power. The datasheet talks about this on page 37. I'm not sure HOW you actually do that just yet. The info on Arduino registers although better than nothing, is a bit brief for my taste and mentions nothing of this SMCR.

Waking it up: what I'm trying to achieve is put the board to sleep after it sits idle for a while, then wake it up when a pin like the pins listening for the lock/unlock commands changes state, which if I understand some of these tutorials correctly is called an "external interrupt" which wakes it up once it's put to sleep by setting that SMCR. On the Arduino Mini pins 2 and 3 support this feature....again, that is if I understand this right...

[Dannyx]

UPDATE: I managed to learn a little bit more about this sleep business, enough to put my board to sleep successfully. Indeed it works: the current consumption drops down by a lot, though I noticed it varies quite a lot between two different projects I tried loading on it, despite the same sleep command is used. I think it has something to do with how many pins are defined as inputs vs how many as outputs, because I saw a video where the guy suggests setting all the unused pins as outputs to cut down the current consumption for some reason...

[stj]

probably because of the pullup resistors

[redwire]

Are you are using this mode:

set_sleep_mode(SLEEP_MODE_PWR_DOWN);

Make sure you turn off the A/D, brown out detection, maybe watchdog timer to get really low current draw under 0.5mA when you go to sleep. Sometimes MCU input pins will float not at 5V or 0V and waste current. I don't think your circuit has any issues there because there are pullup resistors on all I/O. You have no outputs high all the time, which can also waste power.
There are many sleep tutorials, not all correct but they try explain the '328 sleep modes.

When the IGN key is off, I would wait 30 seconds before going to sleep. It's nice to be able to close the car windows without the key back in.

[Dannyx]

Originally Posted by redwire

Are you are using this mode:

set_sleep_mode(SLEEP_MODE_PWR_DOWN);

Yes, that along with sleep_cpu() as per THIS tutorial.
I also got the hang of waking it back up using interrupts 0 and 1 on pins 2 and 3 respectively. I made it so that when you lock the car, the windows roll up and the sleep command is run after the windows have closed. Interrupt 1 is connected to the unlock signal - it wakes the MCU when you unlock the car. Interrupt 0 is the IGN ("ACC", accessory, as I call it) connection - it also wakes the MCU ready to roll some windows when you hop in The reason I use the unlock signal as an interrupt as well is because I made it so that if you double-click the unlock button, so the "unlock" pin (3) on the Mini gets pulled down twice in succession, the windows roll DOWN, say for those hot sunny days, so the car gets some air before you hop in. The same happens for the "lock" pin (4) - click it twice and the windows go up, then the MCU goes to sleep......it works, but I admit the code is a mess

[sam_sam_sam]

Originally Posted by Dannyx

I also got the hang of waking it back up using interrupts 0 and 1 on pins 2 and 3 respectively. I made it so that when you lock the car, the windows roll up and the sleep command is run after the windows have closed. Interrupt 1 is connected to the unlock signal - it wakes the MCU when you unlock the car. Interrupt 0 is the IGN ("ACC", accessory, as I call it) connection - it also wakes the MCU ready to roll some windows when you hop in The reason I use the unlock signal as an interrupt as well is because I made it so that if you double-click the unlock button, so the "unlock" pin (3) on the Mini gets pulled down twice in succession, the windows roll DOWN, say for those hot sunny days, so the car gets some air before you hop in. The same happens for the "lock" pin (4) - click it twice and the windows go up, then the MCU goes to sleep......it works, but I admit the code is a mess

Nice work I like your approach to this project keep up the good work
When you finally finish this project could you show some pictures of the the setup