 |
 |
| View previous topic :: View next topic |
| Author |
Message |
ftoffolon
Joined: 01 Jul 2016
Posts: 8
|
| problem with uart |
 Posted: Fri Jul 01, 2016 7:24 am |
 |
|
Hi,
I'm using PIC16F18325 and CCS C 5.060.
I want to use HW UART but, despite no warnings or errors from compiler, it doesn't work. No frames go out and the interrupt isn't called if I try to send something to microcontroller. Tracing with debugger (MPLAB X), it seems serial is not configured : SP1BRGH and SP1BRGL are both zero !
Thanks in advance for any help.
Below my code:
| Code: |
#include <16F18325.h>
#pragma fuses MCLR, NOCLKOUT, PUT, BROWNOUT
#pragma fuses LPBOR, BORV27, NOLVP,
#pragma fuses NOEXTOSC, RSTOSC_HFINTRC_PLL, NOWDT
#pragma fuses NOPPS1WAY
#pragma use delay(internal = 8M)
#pragma pin_select U1TX=PIN_C4
#pragma pin_select U1RX=PIN_C5
#pragma use RS232(baud=38400, bits=8, stop=1, parity=N)
#pragma zero_ram
void main(void) {
enable_interrupts(INT_RDA);
while(1) {
delay_ms(1000);
printf("hello\r");
}
}
#pragma INT_RDA
void uart_rx_isr(void) {
char c;
clear_interrupt(INT_RDA);
c = getc();
} |
|
|
 |
Ttelmah
Joined: 11 Mar 2010
Posts: 19552
|
|
| Posted: Fri Jul 01, 2016 8:16 am |
|
|
| Code: |
#include <16F18325.h>
#fuses MCLR, NOCLKOUT, PUT, BROWNOUT
#fuses LPBOR, BORV27, NOLVP
#fuses NOEXTOSC, RSTOSC_HFINTRC_PLL, NOWDT
#fuses NOPPS1WAY
#use delay(internal = 8M)
#pin_select U1TX=PIN_C4
#pin_select U1RX=PIN_C5
#use RS232(UART1, baud=38400, bits=8, stop=1, parity=N)
#zero_ram
#INT_RDA
void uart_rx_isr(void)
{
char c;
c = getc();
}
void main(void)
{
enable_interrupts(INT_RDA);
while(1)
{
delay_ms(1000);
printf("hello\r");
}
}
|
Recoded into CCS.
First, PRAGMA does nothing in CCS. Removed.
PRAGMA is a pre-processor directive, to say 'handle this before anything else'. CCS doesn't actually 'have' a pre-processor as such, and things are handled sequentially with all #directives being handled before parsing the code, in the order they occur.
Second, you have to tell USE_RS232 what UART you want to use (if using the hardware), or what pins to use (if using software). Fixed.
Third, the INT_RDA handler has to either be before the main, or prototyped before the main. Fixed. Currently it does nothing, since the main does not get told that a character has been received, and the character is local to the handler (not stored into anything the main can access).
INT_RDA won't actually be called, since you have not enabled the global interrupt bit, so all interrupts are still disabled.
For an example of an INT_RDA handler, look at ex_sisr.c |
|
|
ezflyr
Joined: 25 Oct 2010
Posts: 1019
Location: Tewksbury, MA
|
|
| Posted: Fri Jul 01, 2016 1:34 pm |
|
|
Hi,
In addition to everything that's already been mentioned, you'll need to add this to main() as well:
| Code: |
enable_interrupts(global);
|
This code should ideally be placed just below the code that enables the int rda interrupt.
Of course, as written, although the serial interrupt will now fire, there still will not be any user indication that this is happening. To test the interrupt you could toggle an LED each time the interrupt fires or something like that!
_________________
John
If it's worth doing, it's worth doing in real hardware! |
|
|
ftoffolon
Joined: 01 Jul 2016
Posts: 8
|
|
| Posted: Fri Jul 08, 2016 12:45 am |
|
|
Thanks for support.
Example from Ttelmah works but also with #pragma. I use it because with IDE (Eclipse CDT) otherwise it propts errors.
My fault was not declaring UART1 as first parameter of #use RS232. Compiler should raise an error for this.
Regards |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19552
|
|
| Posted: Fri Jul 08, 2016 12:59 am |
|
|
#pragma, doesn't 'matter', it just doesn't actually do anything.... 
On a lot of multi pass compilers, it is needed to ensure things are handled in the correct order. It sounds as if your IDE 'thinks' this is the case.
Not declaring UART1 (or pins), is legal, It creates a 'null UART'. Can be a useful way of disabling the serial out. It basically says 'send this to nowhere'. However it is not a way of generating actual serial. |
|
|
gpsmikey
Joined: 16 Nov 2010
Posts: 588
Location: Kirkland, WA
|
|
| Posted: Sun Jul 10, 2016 9:27 am |
|
|
I would at least expect it to generate a warning to the effect of "no uart selected" or something. While a null uart may be helpful in some cases, it is not overly user friendly to not at least let the user know they may have made a mistake.
mikey
_________________
mikey
-- you can't have too many gadgets or too much disk space !
old engineering saying: 1+1 = 3 for sufficiently large values of 1 or small values of 3 |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19552
|
|
| Posted: Sun Jul 10, 2016 11:39 am |
|
|
Not really.
It's a basic error, like multiplying by 2, when you mean to add. Syntactically perfectly legal, but very different results.
The lesson is always _think_ about your setups. My 'head of program', will contain each line setting peripherals up, with notes of what pins are used, what hardware is involved etc. etc..
If you had a note saying where you wanted the data to 'go', then it'd be immediately obvious that this is not contained in the setup line.... |
|
|
RF_Developer
Joined: 07 Feb 2011
Posts: 839
|
|
| Posted: Mon Jul 11, 2016 1:57 am |
|
|
| gpsmikey wrote: | | While a null uart may be helpful in some cases, it is not overly user friendly to not at least let the user know they may have made a mistake. |
The compiler can't read minds, and it can not work out what you intended to do when you did something else. In some cases it may be able to raise a warning when you do something silly, otherwise, if that's what you tell it to do, and it's syntacially correct, then it will do it, regardless of how "unintended" it is. A lot of pointer errors go into that class too! |
|
|
gpsmikey
Joined: 16 Nov 2010
Posts: 588
Location: Kirkland, WA
|
|
| Posted: Mon Jul 11, 2016 3:37 pm |
|
|
Yes, I realize that, but a warning would be nice as it would cause the user (hopefully) to think about it. Granted, there are a whole bunch of things like accidentally putting a semicolon at the end of an "if" statement so it only is one line instead of the block of code following between the {} (yes, that one can take a while to find ... sigh), but it would be nice if it flagged it as "questionable". The C language is very good at not only hanging you but providing the rope to do it quite cheerfully 
mikey
_________________
mikey
-- you can't have too many gadgets or too much disk space !
old engineering saying: 1+1 = 3 for sufficiently large values of 1 or small values of 3 |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19552
|
|
| Posted: Mon Jul 11, 2016 11:35 pm |
|
|
If you look at C in Unix, it too will not find any form of potential problem like this.
Instead what you do, is use a separate 'pre-scanner', like Lint. This is designed to pick up the 'bits of fluff', and warn you about things that are syntactically fine, but look possibly faulty.
Problem is that if you make the warnings too complete, they will flag lots of things that are fine (one of the powers of C is just what you 'can' do), making them too intrusive for use all the time. As a separate tool though they can help you to find potential problems.
Some time ago (well out of date now), I did do a version of PC-Lint, setup with CCS syntax rules, and this worked quite reasonably (this was used for a commercial job though).
I'd suggest if you want this type of checking, get a copy of a free Windows Lint, and customise the rule set for CCS. |
|
|
|
|
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
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
