| View previous topic :: View next topic |
| Author |
Message |
ING.remco
Joined: 07 Nov 2015
Posts: 9
|
| Not working software UART |
 Posted: Wed Apr 20, 2016 11:20 am |
 |
|
Hi guys or [spam],
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: 19546
|
|
| Posted: Wed Apr 20, 2016 2:33 pm |
|
|
| 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: 9245
Location: Greensville,Ontario
|
|
| Posted: Wed Apr 20, 2016 2:40 pm |
|
|
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
|
|
| Posted: Thu Apr 21, 2016 12:03 pm |
|
|
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: 2128
Location: albany ny
|
|
| Posted: Thu Apr 21, 2016 4:57 pm |
|
|
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: 21708
|
|
| Posted: Thu Apr 21, 2016 7:21 pm |
|
|
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: 19546
|
|
| Posted: Fri Apr 22, 2016 1:38 am |
|
|
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: 9245
Location: Greensville,Ontario
|
|
| Posted: Fri Apr 22, 2016 5:38 am |
|
|
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: 2128
Location: albany ny
|
|
| Posted: Fri Apr 22, 2016 7:48 pm |
|
|
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  |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19546
|
|
| Posted: Sat Apr 23, 2016 12:55 am |
|
|
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. 
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
|
|
| Posted: Sat Apr 23, 2016 11:24 am |
|
|
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: 9245
Location: Greensville,Ontario
|
|
| Posted: Sat Apr 23, 2016 2:44 pm |
|
|
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: 19546
|
|
| Posted: Mon Apr 25, 2016 12:30 am |
|
|
The key point is one made by PCM_programmer.
If you are not defining fuses, you _must_ check them.
Assumptions are always dangerous. |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
