Software ignoring PE1 as fourth lever input?

[Bernard Fife]

Addicted,

My dbug counter counts up when 5V is applied to PE1, and down when it is removed. So that is as designed, and the port appears to be configured correctly. Hopefully you see the same thing there, as that would mean the problem is in the gear deduction logic, not the actual physical signal sensing. If that's the case, I should be able to sort it out fairly quickly.

Lance.

[Bernard Fife]

Addicted,

I did find another problem in the code wrt the lever deduction. This particular problem *should* be fixed in the attached 4.144q code (uses the same INI as the previous code, and still has the PE1 dbug counter in place).

Monitor_4144q.abs.s19

(73.35 KiB) Downloaded 616 times

Lance.

[Addicted]

Thanks Lance, unfortuantly I was in bed when you uploaded this code I'll test it as soon as I'm home from work...

[Addicted]

Hello Lance,

The polling works, in one position it goes up, in the other in goes down.


However, more importantly..

The manual gauge works properly!!!!! What did you do?

[Bernard Fife]

Addicted,

That is great news! I deeply apologize that it took so long to sort this, that was entirely my fault (both the bug itself and the time it took to sort out).

The problem was in the logic for the number of active inputs. The code was supposed to recognize the 4th input as high if the number of inputs was greater than 3 (i.e. 4) AND the PE1 input pin was high. But what it was actually doing was if the number of inputs was 4 OR the input was high. The previous code should have been if the number of inputs was 3 OR the input was high.

The old code looks like this:

Code: Select all

GearHex = 0x01; // Initialize hex value for checking gear patterns
for (ix=0; ix < (inpram.num_gears + 4); ix++)
{
if (   ((inpram.Inputptrn[0] & GearHex) == (Inputstate[0] * GearHex)) 
	&& ((inpram.Inputptrn[1] & GearHex) == (Inputstate[1] * GearHex))
	&& ((inpram.Inputptrn[2] & GearHex) == (Inputstate[2] * GearHex))
	&& ((num_inputs == 4) || ((inpram.Inputptrn[3] & GearHex) == (Inputstate[3] * GearHex)))
	)
	{ set the appropriate lever value in the code based on the current GearHex value and return}
        GearHex = GearHex * 0x02; // 0x01, 0x02, 0x04, 0x08, ... only if we haven't found a gear and returned

} // end for (ix=1,ix<=NUM_GEARS,ix++)

and the new code is like this:

Code: Select all

GearHex = 0x01; // Initialize hex value for checking gear patterns
for (ix=0; ix < (inpram.num_gears + 4); ix++)
{
if (   ((inpram.Inputptrn[0] & GearHex) == (Inputstate[0] * GearHex)) 
	&& ((inpram.Inputptrn[1] & GearHex) == (Inputstate[1] * GearHex))
	&& ((inpram.Inputptrn[2] & GearHex) == (Inputstate[2] * GearHex))
	&& ((num_inputs < 4) || ((num_inputs == 4) && ((inpram.Inputptrn[3] & GearHex) == (Inputstate[3] * GearHex))))
	)
	{ set the appropriate lever value in the code based on the current GearHex value and return}
        GearHex = GearHex * 0x02; // 0x01, 0x02, 0x04, 0x08, ... only if we haven't found a gear and returned

} // end for (ix=1,ix<=NUM_GEARS,ix++)

Th code is just comparing the input states (Inputstate[x]) to the user pattern (Inputptrn[x]) for each gear's bit position (GearHex) until it gets a match, in which case it sets the lever value and exits from the routine.

Lance.

[Addicted]

Lance, you have nothing to apologise for. I appreciate everything you do.

A year ago that code would have made no sense to me, but after a year of working with the Arduino IDE and C it no longer looks like total gibberish

Its a considerably more complex version of the routine I wrote for my Alphanumeric display, I was lucky in that I was working with a fixed input matrix where you're having to work with one defined by the user, amongst a million other variables!

Will it be safe to continue with that code? what will that counter do when it becomes 'full'?


Soooo all I need to do now is climb under the car and solder in a diode on my PWM line and I'm good to go.... scarey...

[Bernard Fife]

Addicted,

Yeah, it amazes me that *I* understand it sometimes! Before MegaSquirt I had no electronics or code background at all (though I had plenty of automotive experience - mostly with formula cars).

Yes, the posted test code is safe to continue with. Except for a small change to the dbug variable (to assign it back to its original use) this will soon be released as 4.145 code. The dbug variable has been in the code right from the beginning. But it hasn't always been reported. Normally that channel is used for reporting the number of skipped VSS teeth. This is done in one line in the code like this:

Code: Select all

outpc.dbug = VSS_error; // set dbug to VSS error count unless used for 
						 // logging elsewhere in code

But when I need a variable for debugging (often!), I comment out that line with // (which is the ONLY place outpc.dbug is used) and put an assignment somewhere else. For example, in the code you tested it was:

Code: Select all

// outpc.dbug = VSS_error; // set dbug to VSS error count unless used for 
						// logging elsewhere in code
						
if (FOUR_WD & FOUR_WDpin) outpc.dbug++; else outpc.dbug--; // DEBUG

where FOUR_WD and FOUR_WDpin are 'defined' as:

Code: Select all

// 4WD
#define FOUR_WD PORTE
#define FOUR_WDpin 0x02

This just tells the compiler that wherever it sees FOUR_WD substitute PORTE, and wherever it sees FOUR_WDpin substitue 0x02 (you can tell these are compiler directives and not C statements because they begin with # and don't end with a semicolon).
So:
if (FOUR_WD & FOUR_WDpin)
is the same as
if (PORTE & 0x02)
or equivalently
if (PE1 is high).

Using defines makes the code more readable and more portable between processors (for another processor I can just change the assignment in the file, and all the rest of the code can stay the same).

BTW, there also happens to be an input debug variable. This can be used to toggle or set values in the code from TS, and often comes in handy. You can see this variable under the 'Tools -> Debugging Input Variables' menu (this menu is sometimes commented out for release code), and the input value can be set to either a voltage (0-5V) or an ADC value (0 to 1023) and used in the code in any way one likes.

Having these permanently built into the code and INI makes debugging easier.

Lance.