t vago's MPGuino workspace thread

[nickdigger]

uint8_t injDir = (PIND ^ injDirection) & (1 << PIND2);

Hmm. I used ( (PIND & (1<<PIND2)) ^ injEdge ), where injEdge is 0x00 or 0x04 (to match the bitmask 1<<2). Should have been functionally the same. I may try it again. Or maybe it's because i was pulling injEdge straight from the parameters section, and not making it volatile. I'll recompile & see what code i get.

[nickdigger]

Weird My last post isn't displaying, even though the index shows it was posted 15 minutes ago...

In short, I thought because I was checking directly against the injEdge parm, instead of a "volatile", that maybe that's why mine wasn't working. I recompiled, checked the asm output, and that isn't the problem. Back to the drawing board, i guess.

[t vago]

This the code I use to enable the fuel injector interrupt.

EICRA = (EICRA & ~(1 << ISC01)) | (1 << ISC00); // set injector sense pin control
EIFR = (1 < INTF0); // clear fuel injector sense flag
EIMSK = (1 << INT0); // enable fuel injector sense interrupt

Does yours look the same?

[nickdigger]

We've got a one-for-three match:

  EIMSK= (1<<INT0);
  EICRA= (0<<ISC01) | (1<<ISC00);

I have nothing for EIFR. Atmel says EIFR is always cleared (set to 1) when INT0 is config'd as a level interrupt. Nothing for EIFR in the dual-pin setup either, and it works. Not sure if you typo'd the (1 < INTF0) in your code, or just a cut+paste typo.

The ISC00 and ISC01 would be 11 for RISING, 10 for FALLING, 01 for CHANGE, 00 for LOW.. You seem to be... setting yours to 00 ?

[t vago]

Originally Posted by nickdigger

We've got a one-for-three match:

  EIMSK= (1<<INT0);
  EICRA= (0<<ISC01) | (1<<ISC00);

Why are you shifting a zero?

Originally Posted by nickdigger

I have nothing for EIFR. Atmel says EIFR is always cleared (set to 1) when INT0 is config'd as a level interrupt. Nothing for EIFR in the dual-pin setup either, and it works. Not sure if you typo'd the (1 < INTF0) in your code, or just a cut+paste typo.

It would, of course, help to not assume that I just make typos and other errors.



Kindly take note of that last sentence - This flag is always cleared when INT0 is configured as a level interrupt. As I am configuring INT0 as a change interrupt, not a level interrupt, this last sentence does not apply. Also, we don't want the interrupt to immediately fire off once a sei() instruction is executed to re-enable interrupts. Therefore, it is imperative to clear any pending interrupt condition for a given interrupt, prior to enabling said interrupt. You just don't know what you're going to get, otherwise.

Originally Posted by nickdigger

The ISC00 and ISC01 would be 11 for RISING, 10 for FALLING, 01 for CHANGE, 00 for LOW.. You seem to be... setting yours to 00 ?

Let's go over my logic for EICRA, shall we?

The term takes something in parentheses, then logic-ORs it with another term. This result is then written back to EICRA.

From elementary mathematics, the stuff in parentheses has priority over the other stuff. The innermost parentheses term gets evaluated first. That would be:

The below term shifts a 1 leftward by a value determined by the constant ISC01. It happens to evaluate to 2, or 0b00000010.

(1 << ISC01)

Next, that term is ones-complemented by the ~ operator. This turns the value into 253, or 0b11111101.

~(1 << ISC01)

or

~(0b00000010)

Then, the value is logic-ANDed with whatever is in EICRA. This has the effect of turning off bit 1 in the value stored in EICRA.

(EICRA & ~(1 << ISC01))

or 

(EICRA & 0b11111101)

There's another term in parentheses - this one:

(1 << ISC00)

As ISC00 is a constant 0, this term happens to evaluate to 1 << 0, or 1, or 0b00000001.

So, moving onto the expression, we have:

(EICRA & ~(1 << ISC01)) | (1 << ISC00)

or

(EICRA & 0b11111101) | 0b00000001

We logic-OR the (1 << ISC00) with the modified value. Finally, the modified value is written back to EICRA.

This technique has the effect of modifying only the lowest two bits in EICRA, leaving the other bits alone. This is standard practice whenever hardware registers are modified at the bit level. It ensures that only the desired bits are messed with, and leaves the other bits alone.

This technique avoids all sorts of subtle bugs that are caused by brute-force writing a value to a hardware register that controls more than one hardware feature. This would include features that aren't being used, or that are used for something else in your program, or are not yet implemeted in the hardware you're testing the program in.

This technique also lets everyone else who is reading your code know that you meant explicitly to set the bits as you have. It avoids ambiguity caused by something like (0 << ISC01), which otherwise makes no sense.

[nickdigger]

Why are you shifting a zero?

To self-document the code. The pre-compiler washes it out, and it costs nothing. It is a carryover from the dual-int setup, which has
EICRA= (1<<ISC01) | (0<<ISC00) | (1<<ISC11) | (1<<ISC10), or the obverse, depending on injEdge.

Let's go over my logic for EICRA, shall we?

OK. I read (EICRA & ~(1 << ISC01)) | (1 << ISC00) as
(EICRA & ~(1 << ISC01) | (1 << ISC00)). I didn't expect anyone would tiptoe around the EICRA bits since they only handle the two interrupts.

It would, of course, help to not assume that I just make typos and other errors.

So did (1 < INTF0) work by accident, instead of (1 << INTF0) ? Anyway, i'll try setting it.

[nickdigger]

OK, it works now. I'm assuming EIFR was the difference. Thanks.
edit: Scratch that. I reread the datasheet, and decided to remove the EIFR bit. It still works, without it. I'm not sure why my first attempt failed, but it's working now. Maybe it was my cheap trick of setting injEdge to 0x04 (which i'm still doing).

[t vago]

Originally Posted by nickdigger

So did (1 < INTF0) work by accident, instead of (1 << INTF0) ? Anyway, i'll try setting it.

For the life of me, I cannot see how that got posted here as (1 < INTFO). Maybe it was a cut/paste type.

Originally Posted by nickdigger

OK, it works now. I'm assuming EIFR was the difference. Thanks.

Glad it worked. I dislike using direct values within the code itself. Using "const (type) (name) = (some value);" helps more with being able to read the code, and prevents strange bugs from happening.

[t vago]

Okay, did some re-coding of the MAP sensor support. Unfortunately, that led to some code bloat. The code was at about 17800 bytes when I finally got it to work as I wanted. So I decided, "Aw, hell," and coded in a few more things that I thought would be nice.

So, now, the stored parameters now reflect whether the MPGuino is in metric or US mode. The displayed parameter labels even change, based on whether metric or US mode is selected. Also, it is now possible to calculate that "microseconds per gallon" value from within the MPGuino itself. All you need are the number of injectors in your vehicle, the injector rated flow rate, and the injector rated fuel pressure (which is normally 43.5 psig, or 3 Bar).



(cut/paste type? Geez...)

[t vago]

The injector pressure differential correction factor code has been written, and is now in a stable version. Code testing is underway.