Running a microcontroller in car - power supply aspects

[stj]

Re: Running a microcontroller in car - power supply aspects

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

[Curious.George]

Re: Running a microcontroller in car - power supply aspects

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.

[Dannyx]

Re: Running a microcontroller in car - power supply aspects

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]

Re: Running a microcontroller in car - power supply aspects

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]

[redwire]

Re: Running a microcontroller in car - power supply aspects

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]

Re: Running a microcontroller in car - power supply aspects

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]

Re: Running a microcontroller in car - power supply aspects

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]

Re: Running a microcontroller in car - power supply aspects

8<

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

[B]What do you think THIS ^ does?[/B]

8<

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

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

[redwire]

Re: Running a microcontroller in car - power supply aspects

It is easier to write software by breaking it down into little pieces. You can write out pseudo-code as it is called, just to nail down the big picture.
Then, you drill down into each piece, and do the hard work of coding a little chunk at a time. (in all truth, I only use 'state-machine' code for all Arduino projects now, it's what the pro's use, so much less pain)

[Dannyx]

Re: Running a microcontroller in car - power supply aspects

Looks awfully complex...haven't looked into it yet, so maybe I'll pull it off...registers and in-depth stuff go a bit over my head

[redwire]

Re: Running a microcontroller in car - power supply aspects

Here are snippets of my Arduino code. There is an AVR sleep library.
First, I have a pin change interrupt (on IGN and pushbutton input) to allow wakeup even though the MCU is asleep.

To go to sleep, I shut off the A/D and analog comparator to save power, and enable the pin change interrupt.

#include <avr/sleep.h>
// these snippets for ATtiny85

//------------------------------------------------------------------------
ISR(PCINT0_vect) { // Pin Change Interrupt
// GIFR automatically cleared here; hope timers don't use them
// clear the pin change interrupts and turn them off
// good to wake and run now; or no change during normal interrupt

 GIMSK &= (0 << PCIE); // no more Pin Change interrupts; mask them off
 sleep_disable(); // now that we've woken up, stay up; 
 DEBUG_PRINTLN("**int WAKE ***");
 state=sWAKE_FROM_SLEEP; // duplicate - in case we (return) wake up in lala land
}

//------------------------------------------------------------------------
void SleepSession(void) {
  
 // configure and enter sleep mode, only pin change interrupt (ign switch or pushbutton press) wakes us
 ADCSRA &= ~_BV(ADEN); // disable ADC and save power ~0.3mA at 5V; _BV is a macro
 // not sure if BOD (fuse) is used, analog comparator if used may need to disconnect too to save power.

 // config pin change interrupts 
 cli(); // disable global interrupts as we are reconfiguring them
 PCMSK = 0b00011000;  // unmask pin change interrupts on pins PB3, PB4- the switch inputs
 GIMSK |= (1 << PCIE); // unmask Pin Change interrupts; Interrupt source
 // not sure if timer interrupts happen on Arduino with Attiny85, leave otehrs alone

 set_sleep_mode(SLEEP_MODE_PWR_DOWN);
 sleep_enable();
 sei();         // re-enable global interrupts, sleep is set up now
 sleep_cpu(); // go to sleep
 
 //---------------------- W A K E ---------
 /* Upon waking, the program will continue from here. */
 state=sWAKE_FROM_SLEEP; // ensure we go to the correct next state
}
//------------------------------------------------------------------------

[stj]

Re: Running a microcontroller in car - power supply aspects

it's in the cpu, not sure if arduino language has it - but it probably does.
or just hit the registers directly to lower the clock or shutdown sections of the chip

[Dannyx]

Re: Running a microcontroller in car - power supply aspects

I'm planning on using the sleep feature as well. This thing is listening for a lock/unlock signal and acting accordingly, so why not have the MCU sleep when it's doing nothing ? I hope it can be done, that is, "wake" the MCU when one of its pins acts (car is locked/unlocked).

[redwire]

Re: Running a microcontroller in car - power supply aspects

Ahhh much better current drain You need that extra 4mA for the MCU

I made a car key-off timer with ATtiny85 with LP2951, to charge phone or listen to stereo for 3hrs if you push a button or key-off. If I stall and restart my engine, it would always reboot the stereo (which takes a long time) so I wanted a battery-power feed to stop that. IGN wire always cuts out when you crank.

What I do is wake up the MCU when the ignition key goes on, and after, I wait 30 seconds and put the MCU to sleep. This saved a lot of current. The A/D I don't use but that section draws a lot of current so I switch it off.
MCU running at 1MHz (A/D off) it was 2mA (plus LED) and going to sleep 0.02mA plus the LP2951, which gives 0.12mA when sleeping. I mention it because it could be something to consider adding to your code, the sleep function. Or shutting off the A/D and Hall sensors when you are not using them.
But maybe your current drain numbers will be good enough. Just giving ideas.

[Dannyx]

Re: Running a microcontroller in car - power supply aspects

Sorted. It turns out the zener diode ZD7 was clamping too low for some reason, causing excess current drain. I removed it and replaced it and it's now working as it should

I also installed the polyfuse, so this whole thing is ready to be tested on the car now

[Dannyx]

Re: Running a microcontroller in car - power supply aspects

I came up with an idea to try and track down the part that's drawing spurious current without having to tear the traces apart: I started by removing the IC and optocouplers from their sockets, since it was the easiest thing to do. I then supplied 5v to the "regulated" output of the IC from an external PSU and measured the current draw on that - 4mA are still there, so it's not the IC, nor something on the 12v side.

I then tried out each type of component individually with the power supply, by using an identical one from my parts bin and placing it in series with the bench supply and my ammeter, including the three types of caps and the 5.1v zener diode. None drew any current at all. The zener diode starts breaking down at around 5.5v, as a side note, which is great news because that's the maximum the Arduino's VCC pin can take.

I then supplied 5v after those pull-up resistors, to confirm whether it's those ceramic caps that draw current, since they were the only part remaining on the board, but no they're not: I get no current draw here at all ! With all said and done, my money is on the small 10uF electrolytic or tantalum cap on the 5v rail (on the output pin of the IC), although I tested these individually and neither drew any current at all ! I must admit the idea of placing two types of caps of the same value (10uF) on the output of the IC is an undocumented/unfounded idea of mine that I came up with on my own, fearing a single electrolytic may fail due to the hot environment and result in the output overshooting (having seen what the IC does with NO cap at all >> 10v on the output !), so the more professional folks out there may be quick to pan this, but hey - learning

[Dannyx]

Re: Running a microcontroller in car - power supply aspects

it's probably going through the pullup-resistors

Yes, but they aren't connected to the Arduino ATM (because it's not inserted)...unless the optocoupler + the ceramic cap has leakage, which is to be expected...

[stj]

Re: Running a microcontroller in car - power supply aspects

it's probably going through the pullup-resistors

[Dannyx]

Re: Running a microcontroller in car - power supply aspects

Just try pull the Vreg IC out of the socket, then you can see if it is ahaed or after, the current drain.
I find chinese electrolytics have high leakage currents.

I'll remove the IC and supply 5v directly with an adapter or something and measure the current draw on that. It'd be great if it's just the cap, since I can easily remove it and replace it (hopefully with something better quality)....

[redwire]

Re: Running a microcontroller in car - power supply aspects

Just try pull the Vreg IC out of the socket, then you can see if it is ahaed or after, the current drain.
I find chinese electrolytics have high leakage currents.