Dummy C18 question re using header files

Hopefully someone can point me in the right direction without too much mirth......

I'm using an generic 4x16 LCD with a Pic + MPLAB + C18 free compiler.

I need to use the xlcd.h header file.

The xlcd.h file is supplied with the C18 package and seems to be where pins for the LCD control etc are defined.

Do I simply copy this file into the project directory and edit it?

It would seem foolish to edit the supplied xlcd.h file and leave it in the the MCC18/h folder right?

Reply to
DTJ
Loading thread data ...

Why do you want to edit it? Are the definitions contained therein inappropriate to your design? Or, do you want to *augment* them?

Yes. Unless you have found a problem in the "original", best bet is to leave it pristine.

If you *have* found a problem (i.e., error), then that would be the right place to correct it. But, do so in a manner that preserves the original "error" as a commentary with suitable documentation to indicate why *your* fix is correct.

Also, report it to the Microchip folks (who may take the opportunity to correct you on YOUR correction! :> )

Reply to
Don Y

Below is a sample from the C18 xlcd.h file:

Looking at it I figured I had to edit the file to change the pin allocations etc.

Can I avoid this by using the following definitions for the data port and RW lines etc after the include for the xlcd.h?

#define DATA_PORT PORTn //

Reply to
DTJ

DTJ, your puzzlement is well-founded. Let me try to help...

Microchip's headers and software stacks for various devices are not at all like libraries most software engineers expect. They do not have clear inter faces, nor well-encapsulated configuration parameters. Those subsystems whe re they've attempted to provide encapsulation for easy integration into dif fering chips and configurations don't do so consistently.

For example: The USB stack needs configuration for port, pins, hardware fea tures implemented - but does not provide any consistency of naming, nor doe s it parameterize things like buffer size for CDC character buffers.

So... You'll usually need to make copies of the provided (just-for-guidance claims the manufacturer) software and edit it. And heaven help you when th e next release shows up with bug-fixes you'll want.

This state of affairs is not unique to Microchip ;-( Because of the extreme non-regularity of peripheral interfaces, it is hard to make this stuff eas ily parameterizable. Quick - where are the bits controlling interrupts for serial port 3? Sorry, no relation to those for serial port 2. Good luck mak ing simply parameterized driver code.

Really, you're not losing your mind, its rather a muddle you're wading into ...

Hope that helps! Best Regards, Dave

Reply to
Dave Nadler

Yes. This is not describing something *intrinsic* to a particular MCU. E.g., if there was a port that had specific hardware capabilities (like an A/DC, for example) then the constants used to define and access it would be invariant across all "applications" using that MCU.

In this case, they are just showing an example of how you *could* connect a particular device (LCD in this case) to some *generic* port on the MCU. As such, if you choose to attach the LCD in YOUR design to some other port, then obviously the definitions that they have settled upon would not apply.

In this case, you should make a copy of the original file -- in some *local* directory (specific to your application) -- and modify it to reflect the hardware configuration that you have settled upon.

Leaving the original in its original form and location allows any examples built with *those* assumptions to remain intact.

Just use a copy of the original as a *template*. Then, be sure to specify YOUR "local" xlcd.h (perhaps "mylcd.h") to ensure the compiler doesn't silently drag in the ORIGINAL file, instead! In which case, you would be left scratching your head wondering why your code doesn't work (unless you were REALLY observant and looked at the actual code being executed to determine that the "wrong" port was being accessed -- i.e., avoid debugging your sources unless you know that the object truly reflects them... and not what you *think*!)

You would adjust these values ("PORTC" and "TRISC") to reflect the actual port onto whcih you have hung YOUR device.

In your LOCAL copy of this file!

------------------------------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Similarly.

You might find it helpful to add some textual commentary at the start of this file wherein you explain (in casual language) what the hardware looks like: "pin 7 (Read/Write) of the LCD is connected to pin 23 (PortB.7) of the MCU. It indicates the direction of data transfered." So, if you encounter problems with the hardware appearing unresponsive, you can go back and double check your schematic against the notes; and, the notes against your #define's. Typos always seem to slip in despite your best intentions.

Reply to
Don Y

Dave Nadler wrote in news: snipped-for-privacy@googlegroups.com:

Its worse than that for the XLCD files. The pin allocations are compiled into the library so you either have to modify the original xlcd.h and rebuild the library every time you change the hardware or copy all the XLCD source and header files into your project and patch all of them to use the xlcd.h from your project folder.

There's an open topic at the moment on the Microchip forum for XLCD with Xc8: The situation with C18 will be similar, but the details of what must be done to avoid having to duplicate everything will differ.

Reply to
Ian Malcolm

Right - Change all function names and globals to something distinct (add a prefix), to avoid anything in the library getting dragged in. Actually best if you completely avoid their libraries other than RTL. Staggering lack of software development understanding over there... Don't bother to complain; they'll just tell you these software components are only for illustration.

Other manufacturers aren't much better. I'll spare you the current crop of villains on my desk!

One notable GOOD implementation of support software I've used is drivers built into ROM in NXP's M0 devices; used without the slightest excitement. Now if only they'd document things like:

- Are these functions thread-safe?

- Reentrant?

- Interrupt-safe? Dream on I guess...

Hope all this helps, Best Regards, Dave

Reply to
Dave Nadler

Many thanks for the reply and suggestions Don.

Reply to
DTJ

Many thanks for your suggestions Dave and Ian.

The microchip forum thread makes interesting reading.

It sounds like there are issues with the 4 bit mode (which I'm trying to use). It might be worth bit-banging it all myself.

Cheers gentlemen.

Reply to
DTJ

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.