I just resubscribed to this forum after a 10 year hiatus. I have a very similar issue with an LCD that needs to cross ports on the databus. I found that the DEFINE statement was quite nice when I wanted to move away from the stock pins and ports assigned by PBP, but I wondered if I could take it a little further. Looking at the code below:


'*** LCD defines and initialization **************************
DEFINE LCD_EREG PORTB
DEFINE LCD_EBIT 3 'LCD enable on PORTB.3
DEFINE LCD_RSREG PORTB
DEFINE LCD_RSBIT 2 'LCD RS on PORTB.2
DEFINE LCD_DREG PORTB
DEFINE LCD_DBIT 4 '4 BIT REGISTER ON UPPER 4 BITS OF PORTB
'************************************************* **

My initial thought was just to make a fake "aliased" port called PORTQ and then use it in the definition of LCD_DREG. I thought I could make it as follows:

PORTQ VAR WORD
PORTQ.0 VAR PORTB.1
PORTQ.1 VAR PORTA.3
..... You get the picture. But I was sorry to find out that this is not possible. (it was sort of dumb to think it would) The second problem with my idea is the fact that even if I make a fake port, it is not recognized by the PBP compiler as a valid port to which LCD_DREG could be assigned.

Now as Steve Irwin the Crock hunter would say..."I probably shouldn't be doing this...." but I decided to poke around in the actual PBPPIC14.LIB and see how this LCD stuff is done. Now I'm not that good with assembly, but I can see a trend happening in the code. There appears within the code a section called "Fake Port settings" where the PORTA AND PORTB are modified if the compiler is calling a 12C67X or 14C000 part. This leads me to believe that an intelligent person could indeed make a fake PORTQ which could be aliased. Now I'm not about to try to modify the actual PBPPIC14.LIB myself, but I would do it if I knew it would work. (Hey, I paid for it so I can screw it up if I want to!) If a port could not be faked because these are hardware calls, then at the very least the actual LCD write section of the library could be modified to address the specific pins instead of banging the whole port.

I'm sure that MEL doesn't like us poking around with the file and I don't even know if the compliler would accept a modified file, but this approach seems easier than actually modifying hardware, especially if your talking about quantities of 1000.

I guess if we are truly looking for the highest efficiency then passing the data to be written to an assembly subroutine would be best, and it would keep people from screaming about modifying the PBP libraries. I'll be on the lookout for such a routine that can be added as an include file.

-John