LCD_AnyPin.pbp

[Darrel Taylor]

It should be the constants, not the defines.

But Sayzer is right. OSC con 20 will not compile if you have used DEFINE OSC 20.
Which means PBP thinks your PIC is running at 4Mhz.

[Ziko87]

It should be the constants, not the defines.

But Sayzer is right. OSC con 20 will not compile if you have used DEFINE OSC 20.
Which means PBP thinks your PIC is running at 4Mhz.

Sorry you guys, I wrote:

OSC WITH 20

but I had to write:

DEFINE OSC 20

I could not understand the error because it compiled correctly. Thanks to all.

[jellis00]

Was LCD_AnyPin included in PBP version 2.6 as was suggested a couple of times in this thread? If not, why not?

[jellis00]

Now that PBP3 is released let me re-phrase my above question: Was LCD_AnyPin included in PBP3 and if not, why not?

[mister_e]

Not it's not, because it's not a common and frequent way to use an LCD.

[Darrel Taylor]

The mechanism used in LCD_ANYPIN that overrides library commands was used in PBP3.

However, it was used in the HPWM command due to necessity.
Microchip changed the 18FxxK80 parts so much that the CCP modules were not compatible with the old HPWM library code.

So Jeff wrote some new HPWM routines, I came up with a way to replace the existing library routines (borrowing from LCD_AnyPin), then Charles did the actual implementation on a chip by chip basis in the .pbpinc files. Really cool stuff.

We've talked about it alot, and as long as no bad side affects are found with the K80 HPWM commands ... one possibility is to allow overriding many of the library functions with new routines, and I'm sure LCD_AnyPin will be one of the first if that happens.

Steve,
In another thread you mentioned PBP_HARDWAREDEF.
That's part of the library override.

In the .pbpinc file for a K80, that macro is declared.
It is simply a #include, that adds the new code for HPWM.

A #define is added too (HPWM_OVERRIDE).
The old library code is wrapped with IFNDEF HPWM_OVERRIDE, so with the define ... the old routines are eliminated and the new included routines take over.

Imagine overriding HSERIN/HSEROUT to use buffers.

[mister_e]

Thanks for the explanation, still waiting the user command (whatsoever it is called) explanation

I can imagine a load of override AND overload without any problem...I also have no problem to imagine why people think we are so excited about that. And, finally, I have no problem to imagine how many rants & questions this will bring as well... maybe we can finally get rid of those "WHY my LED do not blink on PORTA" questions?