CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug Reports on this forum. Send them to support@ccsinfo.com

Not working software UART

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
ING.remco



Joined: 07 Nov 2015
Posts: 9

View user's profile Send private message

Not working software UART
PostPosted: Wed Apr 20, 2016 11:20 am     Reply with quote

Hi guys or girls,

It's me again.

I have a problem with my software UART. I have had it working but i don't receive anything anymore on my terminal program.
I have tested the product that i am using to read out the UART and that works.
I also know that the programming is running on the uc because i have flashing light in the specified interval.

Is there something wrong with my code or is it a malfunction on the uc?

Below is the code that i'm currently running.

Code:

#include <16F726.h>
#include <stdlib.h>
#fuses NOMCLR,NOWDT
#use delay(internal=16000000)
#use FIXED_IO(B_outputs=PIN_B4,PIN_B2,PIN_B0 )
#define GSM_LOCK   PIN_B0
#define PWR_IND   PIN_B2
#define GPS_LOCK   PIN_B4
#define GSM_RING   PIN_C0
//#use rs232(UART1,BAUD=9600,ERRORS,STREAM=GPS,PARITY=N,BITS=8,STOP=1,errors)//UART FOR the PC
//#use rs232(baud=9600,parity=N,xmit=PIN_C2,rcv=PIN_C1,bits=8,stream=GSM,errors,FORCE_SW)
#use rs232(BAUD=9600,XMIT=PIN_B7,RCV=PIN_B6,FORCE_SW)


void main()
{
   //unsigned int i;

      //delay_ms(10000);
      while(TRUE)
      {
            printf("programma loopt.\n\r");
            delay_ms(1000);
            output_high(GSM_LOCK);
            output_high(PWR_IND);
            output_high(GPS_LOCK);
            delay_ms(1000);
            output_low(GSM_LOCK);
            output_low(PWR_IND);
            output_low(GPS_LOCK);
      }
}


Compler version is V5.007
Programming and debugging (UART) with PicKit2.

Thanks in advance,

With kind regards,

Remco

BTW, i'm sending the data via the programming pin, and can still program it. And if i select a different PIN software UART will work again. I think that is strange.
Ttelmah



Joined: 11 Mar 2010
Posts: 13658

View user's profile Send private message

PostPosted: Wed Apr 20, 2016 2:33 pm     Reply with quote

You are using fixed_io. This overrides the compiler's automatic TRIS handling. Then you are not setting the xmit pin on the port as output.....
temtronic



Joined: 01 Jul 2010
Posts: 6287
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Wed Apr 20, 2016 2:40 pm     Reply with quote

Mr T is right again !!

Unless you're under a very, very tight time restrain or super low in code space, forget about using 'fixed_io()', let the compiler handle it AUTOMATICALLY for you!!
I'll bet 99.999999% of all code presented here does not need 'fixed_io'.

Jay
ING.remco



Joined: 07 Nov 2015
Posts: 9

View user's profile Send private message

PostPosted: Thu Apr 21, 2016 12:03 pm     Reply with quote

You are totally right MR Ttelmah.

I really didn't know that, that would have had an effect on the rest of the back for PORT B.

Just learned something know, Thnx.

And yeah you are right temtronic. I don't use fixed_io in any of my code, but why it was present in this one i really don't know.

But thanks.

Kind regards,

Remco
asmboy



Joined: 20 Nov 2007
Posts: 2116
Location: albany ny

View user's profile Send private message AIM Address

PostPosted: Thu Apr 21, 2016 4:57 pm     Reply with quote

as a comment to this and so many other similar posts.
am i the only one who specifies a complete set of fuses and leaves nothing to chance in that department?
A lack of complete fuse specs and proper compiler directives seems so sketchy as to be suspect.
and is hallmark of student projects IMHO.
PCM programmer



Joined: 06 Sep 2003
Posts: 20399

View user's profile Send private message

PostPosted: Thu Apr 21, 2016 7:21 pm     Reply with quote

Actually I would say it's the opposite. But tastes vary. In my case,
I know the default behavior of the fuses. I look at the end of the .LST
file to see the default fuses for the ones that I don't specify. I review
them and I'm satisfied.

I'd say it's better for a newbie to leave most fuses at the default setting.
Otherwise, they'll try to guess what is best and end up setting XINST
because they think it will improve things.
Ttelmah



Joined: 11 Mar 2010
Posts: 13658

View user's profile Send private message

PostPosted: Fri Apr 22, 2016 1:38 am     Reply with quote

The downside with 'not specifying', is that the default does change.

This happened a while ago, when CCS used to default to actually 'setting' fuses to what they thought they should be, and then changed to leaving them at the MicroChip defaults. Now fuses default to what they do in the erased state.

PCM_programmer's approach of 'check the list file', is actually the safest way to go anyway, since it is terribly easy when switching chips, to find there is a new fuse that you had forgotten about.

The code posted actually does set most of the essential fuses. Remember that selecting 'internal' for the clock, should automatically select 'INTRC_IO' for the clock fuse (though this is one it is vital the check, since in some cases it will only select INTRC...). It also enables the PLL (since this is the only way to get the specified speed). Then NOWDT, and NOMCLR are set. NODEBUG is the default in just about all chips (have never seen one where it isn't), and NOPROTECT is also the default. So the only fuses on this chip left 'variable', are PUT (which doesn't matter when using the internal oscillator), BROWNOUT, and the VCAP setting. The latter is one that I'd be very careful to verify is how you want it. Will default to '11' so NOVCAP.
temtronic



Joined: 01 Jul 2010
Posts: 6287
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Fri Apr 22, 2016 5:38 am     Reply with quote

re: fuses

Seems PICs have MORE fuses than instructions these days and WHO says the 'default' is the correct one for YOU !
What works for me is to create a file called 'PICtype_fuses.c' and put them ALL in there. It allows me to see them, when required, yet it's only one line in the main program. Now if you need a different set of fuses for another project, simply copy the first one to say 'Project_name_PICtype_fuses.c'. The 'trick' is to always have a complete set of fuse you KNOW lets the PIC do the 1Hz LED and 'Hello PC' basic programs.

Jay
asmboy



Joined: 20 Nov 2007
Posts: 2116
Location: albany ny

View user's profile Send private message AIM Address

PostPosted: Fri Apr 22, 2016 7:48 pm     Reply with quote

To all: i posted what i did because i got burned when i trusted fuses not to change from old 4.x compiles in 5.xxx land .
some posts here are SO lacking in fuse data - those make me wonder a lot...... especially in the context of the code that goes with the post... FYI Very Happy Very Happy Very Happy Very Happy
Ttelmah



Joined: 11 Mar 2010
Posts: 13658

View user's profile Send private message

PostPosted: Sat Apr 23, 2016 12:55 am     Reply with quote

It was in the transition from V4 to V5, that CCS changed their approach, and stopped setting any fuses themselves (except when things like 'internal' are used in the clock), instead leaving them at the chip erased state (as in the data sheet).
I'm just glad to see a poster actually showing their fuses. Smile
The ones that cause real annoyance are the posts with these omitted, where tiny changes in the fuses will cause the very problem being asked about!...
ING.remco



Joined: 07 Nov 2015
Posts: 9

View user's profile Send private message

PostPosted: Sat Apr 23, 2016 11:24 am     Reply with quote

Thank you for your remark Ttelmah (learned already a lot qua posting ;)).

But setting all the fuses depends on what kind project I'm using and how familiar I'm with the compiler and micro-controller. And with this one I'm kind of familiar so i know whichh fuses must be set to be operating under the circumstances that i want. Otherwise you would see a longer list.
temtronic



Joined: 01 Jul 2010
Posts: 6287
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Sat Apr 23, 2016 2:44 pm     Reply with quote

If you do it the way I suggested a few posts ago, you never see the list unless you specifically open the 'fuse file'!
I typically have a 'basic fuses that work' file for each PIC type, then if need be, copy THEN edit one for a 'project'. This way I can always load the original, basic 'fusefile' KNOWING that the PIC should work.
I do not trust 'default' setups,Wizards or 'other people' who 'think' they know what I need.

Jay
Ttelmah



Joined: 11 Mar 2010
Posts: 13658

View user's profile Send private message

PostPosted: Mon Apr 25, 2016 12:30 am     Reply with quote

The key point is one made by PCM_programmer.

If you are not defining fuses, you _must_ check them.

Assumptions are always dangerous.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group