stopping USART setup

[tcbcats]

I have been using the on board USART on a 18F2X part and now need figure out how to get it turned off so I can use the pins for serin and out.

It seems that the USART is always connected. even when It is not defined and no other include is used.

Is there some INI or something that is setting the UART up by default?
How do I get Pins C6 and C7 to do regular I/O?

I assume that pin C6 and 7 can be used for other I/O functions.

I want to use serout2 and in on these pins.
It works on the other A abd B pins with no problem

tcbcats

[Melanie]

Looks like everyone's given up reading Datasheets today. If you go into the USART section, therein you'd discover that the SPEN bit (Serial Port ENable) of the RCSTA register enables and disables the USART. When disabled, it can be used for regular I/O.

[tcbcats]

Thanks for the help……. I found the problem

I was trying to set the RCSTA SPEN bit before I posted the question…… My problem is that for some unknown reason it did not disconnect the internal USART from pins C6 and C7. …several hours of getting nowhere here…

It acted like something was setting up the USART to C6 and 7 even though I did not define it to be that way.

I just tried to do it again today and it worked….. I found this… Before, I still had calls to HSERIN and HSEROUT ( but not in line to be executed ) and the USART setup was removed. I then called RCSTA bit 7 to be 0. This did not disconnect the USART from C6 and 7 as stated in the data sheet.
I had to remove all references to HSERIN and OUT in my code before the RCSTA command would work.

The raw PIC at power up should not be setting up C6 and 7 to be USART pins. They should be I/O and be set to inputs as stated in the data sheet. This is the safe mode so that no pin will drive any external load until told to do so. Without this, a lot of PIC’s could do strange things to connected hardware if fired up un-programmed.

With little more poking around I found a PBP file (PBPPIC18.LIB)…..

It looks like it sets up the USART to be on by default when the HSERXXX command is found anywhere in your code.…. As well as a lot of other stuff like the LCDOUT pin assignments….. perhaps because the development boards use C6 and 7 only for the USART.

(Kind of like Windows setting things up for you in the background and not telling you) Sometimes this is OK but at other times it can mess you up when you don’t understand the rules..

If my assumptions are true, then defining any of this stuff in my code will override the PBPPIC18.LIB file with some exceptions.

I must also assume that settings in any of the .LIB files are PBP only defaults and not what the raw PIC will do by default.

If this is the way it works, that’s cool, but the manual should state this. ..especially if just including the text for a command and not actually using it could pre set a register or pin with some setting other than the Microchip power up default.

On page 76 of the PBP manual the second paragraph tells me that the settings indicated are “defaults”. This lets the user know that the settings are already set somewhere and that if you don’t want it that way that you can change it as indicated or by going to the data sheet

Under the HSERIN command on page 75. for example, the actual HSERIN command and pins are not indicated to be setup as a default when only the command is present in your code.…. I assumed that I had to also define the USART setup in my program or include another .bas include that set up the USART or it would not work…. Not true, just calling HSEROUT in your code invokes the default to be set up at compile time… again I am guessing on how this works based on my testing.

If the manual stated that “ Using the HSEROUT command anywhere your program will configure pins C6 and C7 (PIC pins that can be set as USART I/O) to be connected to the internal USART. If you are not using the internal USART and you want to use pins C6 and C7 for other I/O, you must set the RCSTA SPEN bit to disconnect the internal USART. and not reference or use the command anywhere in your program”

I am still a Newbie with the PBP product so understanding how and when something gets set as a default or needs to be set to work is part of the learning process.

In the case of the USART, I would prefer the user be required to set it up in code for it to work and that pins C6 and C7 be set to regular I/O and inputs.

It looks like the compiler looks for command words to invoke the setup in the INI file. Just including the command in you code sets up the default and also change the pin function if needed. You must not use the command anywhere in your code before you can override the command default settings…. at lease for The USART… cause that’s all I am working with for now…. Learning more every day….

tcbcats

[Melanie]

Unless you analyse the compiled assembler listing you don't always know how high-level commands affect the hardware. If you've got such commands, it's always a good idea to initialise the ports and registers that you need to use (in your case TRISC and RCSTA) immediately prior to your use for another purpose. That way there's no possbile error or interaction from pervious command usage. But don't forget to set them the way they were prior to using HSERIN/OUT again as those commands may well assume that the registers are in the same state they left them last. This is just good housekeeping practice.

[tcbcats]

Yes, I understand that changing a PBP preset default in line and not putting it back after use could mess up other commands.

Working with the A/D now.
I just set the registers manually when I need the A/D done and then return the port A pin back to the normal state when finished.

If I never call the command for ADCIN then the port A pins will only be in a state that I set.... at least I think that's the way it works.
I suspect that one of the other defaults may set the A port to analog along the way or at power up so I will watch for that too

I am using A0 and A1 for analog and the other A ports for digital

Even though I do not understand all the little settings that PBP does for me, I write this so that others with similar problems can find this information with a forum search

tcbcats

[languer]

tcbcats.

In my short experience with PICs (or any MCU) I've found the following. Trust nobody, specially any high level compiler. As Melanie said, read the datasheets and take them to heart. See, the most current information will come from the manufacturer (most of the times), and the compilers will play catch-up with any errata. So just because of this I learned to initialize everything I need. Understand, PBP is great - heck it saves tons of time but it initializes the PIC to what somebody thinks it is the most widely used configuration (the manufacturer has a lot to do with this many times). Do you consider yourself among the most widely use group? The beauty about MCUs is that you can use them for thousands of applications, really the limit is set by the users imagination. So how do you define the most widely used configuration. You can't, unless you buy thousands (maybe 100k's) to establish yourself the most widely used config.

Enough rambling, the point (to make it short) is to know all the configurations and which ones you need and when. Look at the PBP configuration files and study them. Then initialize the PIC on power-up to do what you want (and nothing else). Understand that, if there is a feature that you don't understand but you surely don't need leave it out. Even if you think it may not affect you good old Murphy says it will.

Good luck.