[SOLVED] Scan Matrix help

[Narwhal]

This weekend I've been trying to get the scan matrix to work when connected via J5 (A0..A3).  I'm using the sm_fast.asm example and the j5_io.asm examples together.

The code setup:

in sm_fast.asm I've defined latch and port definitions as follows:

#define SM_SRIO_LAT_SCLK	LATA	; Pin D.3
#define SM_SRIO_PIN_SCLK	3
#define SM_SRIO_LAT_RCLK	LATA	; Pin D.2
#define SM_SRIO_PIN_RCLK	2
#define SM_SRIO_PORT_DIN	PORTA	; Pin D.1
#define SM_SRIO_PIN_DIN		1
#define SM_SRIO_LAT_DOUT	LATA	; Pin D.0
#define SM_SRIO_PIN_DOUT	0

Init() of main.c is:

void Init(void) __wparam
{
	MIOS_AIN_UnMuxed();
	MIOS_AIN_DynamicPrioSet(0);
	MIOS_AIN_NumberSet(0);

        // set J5 A.1 to be input and all other lines to be output
	J5_IO_Init(0x2);

  	// initialize the timer function for the debounce counters
  	// we want to setup the timer with a frequency of 1kHz = 1 mS
  	// prescaler 1:1 should be used
  	// calculate the required number of clocks for this period:
  	//   clocks = period / 100 nS = 1 mS / 100 nS = 10000
	MIOS_TIMER_Init(0x00, 10000); //10000);

	// initialize the scan matrix driver
	SM_Init();

	// initialize the shift registers
        // I'm hoping to eventually be able to use the SRIO driver!  - please oh please
	MIOS_SRIO_NumberSet(0);            // DONT USE THE MIOS SRIO DRIVER!!!
}

The Hardware Setup:

I've created a small board that just a DOUT X2, and a DIN X1.  It's wired into J5 A.0 - A.3.

I've connected this board to the norman J8 J9 location and it works fine.  When I connect it to J5 though it seems that the software isn't getting the input correctly.  Using a scope, I can see the DOUT being strobed low just, and when I press a button in the matrix, I can the lines going into the DIN pulsing low as that column is scanned by the DOUT. But I'm not getting any recognition, by testing the sm_button_value variable, that a button has been pressed.

Is there something I'm missing here?  Shouldn't this work?

Kurt

[TK.]

Without reading the complete posting: which version of j5_io.asm are you using?

Recently I found a bug, and updated the mios_base package

The change is also available in the repository (for the case that you are using SVN to receive updates automatically)

Best Regards, Thorsten.

[Narwhal]

hmm ok.. I'll check that out.  Mine is dated July 9.  snvmios isn't letting me connect right now.

Kurt

[TK.]

SVN: I will check this soon, seems to be an incompatibility with the new server (common access via ssh is working, but it isn't public)

As you can see here:

http://svnmios.midibox.org/listing.php?repname=svn.mios&path=%2Ftrunk%2Fmodules%2Fj5_io%2F

the last change was 2008-08-05, and this version is also available in the current mios_base package

Best Regards, Thorsten.

[Narwhal]

I used the web access to view the diffs and applied them by hand.. It certainly looked promising, but it didn't work.

[Narwhal]

I've reconfirmed that the hardware works perfectly when connected to J8 J9, so it seem to certainly be a software problem.  On observation that may be a clue is that, when connected to any of the J5 locations, it always shows that one of the buttons is pressed when it boots up.. whereas when its connected to J8/J9 it never shows such until a button is actually pressed.  Perhaps a timing issue when reading DIN via port-a or port-e?

I don't think it's of any real importance, but I am using a 18f4620.

[TK.]

I don't think it's of any real importance, but I am using a 18f4620.

of course, this is important.

It must be ensured, that the selected hardware flags are matching with your processor type (specified in the Makefile as PROCESSOR variable), because as you can see in j5_io.inc, the ADC is disabled depending on PIC_DERIVATIVE_NEW_ADC (defined in hw_flags.h)

You can doublecheck the right selection by searching in the .lst file (in your project it's probably named project.lst) for the J5_IO_Init function. You should see, that opcodes have been generated for "movlw 0x0f", but not for "movlw 0x07"

If this doesn't help: what is the content of address 0xf92 (TRISA), 0xf96 (TRISE) and 0xfc1 (ADCON1) - they can be read out with the debugging window of MIOS Studio.

Best Regards, Thorsten.

[Narwhal]

Ah Haaa!  <light bulb goes on>

Ok, I am aware of the usage of PIC_DERIVATIVE_NEW_ADC in j5_io.inc.  So I guess I assumed that the 4620 must not qualify as a a new adc because I hadn't seen any file that indicated it would qualify as that.  I did search the pic18f4620 header file assuming this define would be in there.

The problem is that I don't have a hw_flags.h file.  It doesn't exist in my project directory, and it's not in the j5_io modules directory. .  Searching my hard drive, I found a version of the hw_flag.h file and I can see now that the 4620 IS a new style adc, and it's absolutely the case that my code is built with PIC_DERIVATIVE_NEW_ADC undefined.  So BINGO this has to be the problem.

But..

To address this condition where I don't have a hw_flags.h, I only found two copies of it and neither of them were in the repository directories.  One is in a j5_dout_v1d directory that is a j5 dout example app that I downloaded, and the other is in the midibox_sid_v2_0_rc25 directory, another download.  I don't find the file anywhere in my entire copy of the svn repository. 

#1) Where exactly is this file supposed to reside normally?

#2) Where is the appropriate place to include this header file?  Obviously it's of vital use to the j5_io.inc file, but it isn't included there?  Is that just an oversight, or is there something deeper I'm missing?

Thanks for the help TK!!  This is the most certainly what the problem is and I can hardly wait to try it out.

[Narwhal]

Problem solved.

Stryd had me remove the j5_io init call and I initialized the tristates and the adcon1 myself in the first lines of Init() in my main.c.  And it worked!  I'm so excited!  I can't wait to finish off the simple stuff remaining.

Kurt

[TK.]

You wouldn't notice such issues if you would setup your project properly.

It's also hard to help you if you are starting to modify modules by hand, or if you are using expired packages from different releases.

Therefore I recomment you:

1) use the most current mios_base package or use SVN, both contain the latest releases - especially of j5_io and hw_flags.inc

2) Don't copy files you find in application release packages, they could be expired or buggy (bugs which may not be relevant for the released application, but for yours)

3) try to use global defines or packages whenever possible.

E.g., it was a good decition to use j5_io, because it allows other users to compile the project for PIC18F452 without modifying your source code

Best Regards, Thorsten.

[stryd_one]

Yeh that was just a hack to make it work in the meantime - the next step is to fix it up so it uses the new structure completely and the j5io module can be used again :)

Although, the whole module is not really needed, and the init functions can be 'borrowed' and they are portable to both ADC variants.

[Narwhal]

I'll definitely be getting to my clean up mode and moving to the new structure.  It just wasn't at the top of my list because I'm trying to learn everything very very quickly.  I'm definite in cowboy development mode.. sorry about that, I just think that it has to be with the amount of time I have.

Really it boiled down to me pushing forward too fast and missing the facts that I should have updated, and I should have set the define for the actual processor type rather than assuming it was the same as the 18f452.

When I release this, it'll be all cleaned up, playing by the rules, and able to be use usable by multiple chip types.  I promise.  ;D

Kurt