Go Back   EcoModder Forum > EcoModding > Instrumentation > OpenGauge / MPGuino FE computer
Register Now
 Register Now
 

Reply  Post New Thread
 
Submit Tools LinkBack Thread Tools
Old 08-30-2013, 12:26 PM   #21 (permalink)
EcoModding Apprentice
 
Join Date: Aug 2009
Location: terra firma
Posts: 138
Thanks: 4
Thanked 24 Times in 22 Posts
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.


Last edited by nickdigger; 08-30-2013 at 01:13 PM..
  Reply With Quote
Alt Today
Popular topics

Other popular topics in this forum...

   
Old 08-30-2013, 12:44 PM   #22 (permalink)
EcoModding Apprentice
 
Join Date: Aug 2009
Location: terra firma
Posts: 138
Thanks: 4
Thanked 24 Times in 22 Posts
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.
  Reply With Quote
Old 08-30-2013, 01:28 PM   #23 (permalink)
MPGuino Supporter
 
t vago's Avatar
 
Join Date: Oct 2010
Location: Hungary
Posts: 1,807

iNXS - '10 Opel Zafira 111 Anniversary

Suzi - '02 Suzuki Swift GL
Thanks: 828
Thanked 706 Times in 455 Posts
This the code I use to enable the fuel injector interrupt.
Code:
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?
  Reply With Quote
The Following User Says Thank You to t vago For This Useful Post:
nickdigger (08-30-2013)
Old 08-30-2013, 02:51 PM   #24 (permalink)
EcoModding Apprentice
 
Join Date: Aug 2009
Location: terra firma
Posts: 138
Thanks: 4
Thanked 24 Times in 22 Posts
We've got a one-for-three match:
Code:
  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 ?
  Reply With Quote
Old 08-30-2013, 05:17 PM   #25 (permalink)
MPGuino Supporter
 
t vago's Avatar
 
Join Date: Oct 2010
Location: Hungary
Posts: 1,807

iNXS - '10 Opel Zafira 111 Anniversary

Suzi - '02 Suzuki Swift GL
Thanks: 828
Thanked 706 Times in 455 Posts
Quote:
Originally Posted by nickdigger View Post
We've got a one-for-three match:
Code:
  EIMSK= (1<<INT0);
  EICRA= (0<<ISC01) | (1<<ISC00);
Why are you shifting a zero?

Quote:
Originally Posted by nickdigger View Post
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.

Quote:
Originally Posted by nickdigger View Post
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.

Code:
(1 << ISC01)
Next, that term is ones-complemented by the ~ operator. This turns the value into 253, or 0b11111101.

Code:
~(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.

Code:
(EICRA & ~(1 << ISC01))

or 

(EICRA & 0b11111101)
There's another term in parentheses - this one:

Code:
(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:

Code:
(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.
Attached Thumbnails
Click image for larger version

Name:	20130830 - AtMega8-168-328p72.png
Views:	405
Size:	33.2 KB
ID:	13697  
  Reply With Quote
Old 08-30-2013, 05:44 PM   #26 (permalink)
EcoModding Apprentice
 
Join Date: Aug 2009
Location: terra firma
Posts: 138
Thanks: 4
Thanked 24 Times in 22 Posts
Quote:
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.

Quote:
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.

Quote:
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.
  Reply With Quote
The Following User Says Thank You to nickdigger For This Useful Post:
t vago (09-02-2013)
Old 08-30-2013, 06:02 PM   #27 (permalink)
EcoModding Apprentice
 
Join Date: Aug 2009
Location: terra firma
Posts: 138
Thanks: 4
Thanked 24 Times in 22 Posts
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).

Last edited by nickdigger; 08-30-2013 at 07:23 PM..
  Reply With Quote
Old 09-02-2013, 10:38 AM   #28 (permalink)
MPGuino Supporter
 
t vago's Avatar
 
Join Date: Oct 2010
Location: Hungary
Posts: 1,807

iNXS - '10 Opel Zafira 111 Anniversary

Suzi - '02 Suzuki Swift GL
Thanks: 828
Thanked 706 Times in 455 Posts
Quote:
Originally Posted by nickdigger View Post
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.



Quote:
Originally Posted by nickdigger View Post
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.
Attached Thumbnails
Click image for larger version

Name:	20130901 - snapshot.png
Views:	407
Size:	8.7 KB
ID:	13702  
  Reply With Quote
Old 09-02-2013, 11:13 AM   #29 (permalink)
MPGuino Supporter
 
t vago's Avatar
 
Join Date: Oct 2010
Location: Hungary
Posts: 1,807

iNXS - '10 Opel Zafira 111 Anniversary

Suzi - '02 Suzuki Swift GL
Thanks: 828
Thanked 706 Times in 455 Posts
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...)

Last edited by t vago; 09-02-2013 at 12:27 PM..
  Reply With Quote
Old 09-02-2013, 12:17 PM   #30 (permalink)
MPGuino Supporter
 
t vago's Avatar
 
Join Date: Oct 2010
Location: Hungary
Posts: 1,807

iNXS - '10 Opel Zafira 111 Anniversary

Suzi - '02 Suzuki Swift GL
Thanks: 828
Thanked 706 Times in 455 Posts


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

  Reply With Quote
Reply  Post New Thread


Thread Tools




Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.
Content Relevant URLs by vBSEO 3.5.2
All content copyright EcoModder.com