 |
 |
| View previous topic :: View next topic |
| Author |
Message |
JackB
Joined: 04 Mar 2016
Posts: 32
Location: Netherlands
|
| SOLVED: Different serial streams - compiler warning |
 Posted: Fri Mar 18, 2016 4:52 pm |
 |
|
Hi,
I use two streams: DMX and STD.
| Code: |
#use rs232(UART1, BAUD=250000,BITS=9,PARITY=N,STOP=1,ERRORS,stream=DMX, LONG_DATA)
#use rs232(uart2, baud=9600, stream=STD) |
When I print to the STD stream, I do this:
| Code: | | fprintf(STD, "Hello there!\r\n"); |
That works, but I get a compiler warning: "Unable to resolve identifier STD.".
How to I solve this warning?
Last edited by JackB on Thu Mar 24, 2016 6:14 am; edited 1 time in total |
|
 |
newguy
Joined: 24 Jun 2004
Posts: 1909
|
|
| Posted: Fri Mar 18, 2016 4:59 pm |
|
|
| What happens if you change STD to STDRD (or anything else, just not STD)? |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Fri Mar 18, 2016 5:01 pm |
|
|
| Always post your PIC and your compiler version. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19551
|
|
| Posted: Sat Mar 19, 2016 3:25 am |
|
|
PCM_programmer pointed out a little while ago, in another thread, that the stream identified has to be completely 'unique'. In this case the user had a subroutine that used the same name. Because of this I've tended to standardise now on using 'informative' names, which then reduce the risk of clashes.
So call streams, 'streams'. So : DMX_STREAM, and STD_STREAM. Then use variable names with codes in to say whether they are strings, floats etc..
As projects get larger this massively helps reduce naming problems.
Agree with Newguy's comment here. |
|
|
JackB
Joined: 04 Mar 2016
Posts: 32
Location: Netherlands
|
|
| Posted: Sat Mar 19, 2016 1:20 pm |
|
|
Now I changed it to DMX_STREAM and STD_STREAM, that makes sense.
But the compiler warnings are still there.
Is there a way to avoid those? |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9246
Location: Greensville,Ontario
|
|
| Posted: Sat Mar 19, 2016 2:00 pm |
|
|
Have to ask if you rename them as
DMX_UNIT_STREAM and STANDARD_STREAM
do you still get the warnings?
I recall in the MSBASIC days than equal lengths variables could cause 'problems',especially if part of them were the same or had 'keywords' embedded in them.
Jay |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Sat Mar 19, 2016 2:59 pm |
|
|
| Quote: | But the compiler warnings are still there.
Is there a way to avoid those? |
Again, post your PIC and your compiler version. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19551
|
|
| Posted: Sat Mar 19, 2016 3:11 pm |
|
|
I'd suspect your #USE lines are not being parsed before your serial code. The sequence in CCS should be:
Processor include
#device statements
#fuse statements
Clock settings
#pin select statements
Then setups for RS232/I2C etc. (#USE).
Only then include other files
Then the rest of the code.
If things are in other files, they must still be read in this order.
What you are describing would happen if you had serial I/O routines being 'included', before the #USE stuff is defined.
The compiler does not use recursion to solve any definition. |
|
|
JackB
Joined: 04 Mar 2016
Posts: 32
Location: Netherlands
|
|
| Posted: Sat Mar 19, 2016 6:31 pm |
|
|
main.c starts with #include "project.h"
project.h:
| Code: |
#ifndef PROJECT_H
#define PROJECT_H
#include <18F67K90.h>
#include "types.h"
#case
#device ADC=12
#fuses MCLR,HSH,NOPLLEN
#use delay(crystal=20mhz)
#use rs232(UART1, BAUD=250000,BITS=9,PARITY=N,STOP=1,ERRORS,stream=DMX_STREAM, LONG_DATA)
#use rs232(uart2, baud=9600, stream=USB_STREAM)
#use i2c(Master,Fast,sda=PIN_C4,scl=PIN_C3)
enum errors { err_range, err_too_far, err_too_many };
#endif /* PROJECT_H */
|
Is this the right order? |
|
|
ezflyr
Joined: 25 Oct 2010
Posts: 1019
Location: Tewksbury, MA
|
|
| Posted: Sat Mar 19, 2016 10:22 pm |
|
|
Hi All,
I say ignore this joker until he posts his compiler version. It may not even be relevant, but he's been asked TWICE to do it and he's ignored the request both times. If no one responds, maybe that will get his attention? Doubtful, but maybe!
_________________
John
If it's worth doing, it's worth doing in real hardware! |
|
|
JackB
Joined: 04 Mar 2016
Posts: 32
Location: Netherlands
|
|
| Posted: Tue Mar 22, 2016 6:29 am |
|
|
Hi John,
my compiler version is CCS PCH C Compiler, Version 5.055. I'm using Linux.
Learning from the other people here, I don't think that changes the PIC18F hardware capabilities, though.
I mentioned the PIC18F67K90 in the code, but maybe that was not obvious enough, I'm sorry.
Hi the others,
Thank you very much for your continued help!
Regards,
Jack (not a joker)
Last edited by JackB on Thu Mar 24, 2016 6:01 am; edited 1 time in total |
|
|
jeremiah
Joined: 20 Jul 2010
Posts: 1357
|
|
| Posted: Tue Mar 22, 2016 8:56 am |
|
|
JackB,
I just tested out a test program in 5.055 with no problems:
| Code: |
#case
#include <18F67K90.h>
#fuses MCLR,HSH,NOPLLEN
#use delay(crystal=20mhz)
#use rs232(UART1, BAUD=250000,BITS=9,PARITY=N,STOP=1,ERRORS,stream=DMX_STREAM, LONG_DATA)
#use rs232(uart2, baud=9600, stream=USB_STREAM)
void main(void) {
fprintf(USB_STREAM,"Hello World\r\n");
fprintf(DMX_STREAM,"Hello World\r\n");
while(TRUE){
if(kbhit(DMX_STREAM)){
fputc(fgetc(DMX_STREAM),USB_STREAM);
}
if(kbhit(USB_STREAM)){
fputc(fgetc(USB_STREAM),DMX_STREAM);
}
}
}
|
No warnings or errors generated (I even tried the same code with STD and no errors/warnings). This means something else in your code is causing the error and the compiler parser is probably just generating an error because it is nearby.
You need to take a step back and start with a small compilable program and slowly add in code until the error occurs. That will help you if all else fails.
Also as a note, you have generated a lot of threads recently (not a bad thing), but you need to consider the forum rules. For things like this they ask that you provide a small program that we can copy paste into a blank project and compile so that we can better help you. You haven't been doing this. It is not only a great debugging tool for you to do it this way, but it helps others help you better. Just as a reference, the forum posting rules are found at: http://www.ccsinfo.com/forum/viewtopic.php?t=47549
In this case I generated one for you, but it is still a good idea for you to do in future threads that you may create.
This is not meant to be rude, so please don't take it that way. I just want to make sure you get the help you need. As you can see, even something as leaving out the compiler version can turn off other users from helping. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19551
|
|
| Posted: Tue Mar 22, 2016 2:04 pm |
|
|
As a comment, I 'worry' about the way the poster here is encapsulating this setup. Now encapsulation of this sort is used in includes, to prevent things being done multiple times. Standard. However the setups involved here, _must_ always be ahead of anything else. As such this encapsulation is then pointless. This could be causing some problems. It's an approach that should not be used for this stuff.
May be part of the problem. |
|
|
JackB
Joined: 04 Mar 2016
Posts: 32
Location: Netherlands
|
|
| Posted: Thu Mar 24, 2016 6:14 am |
|
|
For the moment, I accept the compiler Version 5.055 on Linux can't do without these warnings, I think I tried everything.
But it works just fine.
Thank you again for your help! |
|
|
|
|
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
