 |
 |
| View previous topic :: View next topic |
| Author |
Message |
meereck
Joined: 09 Nov 2006
Posts: 173
|
| issue: RS-485 and enable in #rs232 statement |
 Posted: Wed Jul 08, 2009 7:03 am |
 |
|
hello everyone,
I recompiled my old source code in compiler version 4.088, and i came across an issue in manual driving the enable pin of MAX485 chip.
OLD SRC:
| Code: |
#use rs232(baud=9600,parity=N,xmit=PIN_B2,rcv=PIN_B1,bits=8,stream=SER,errors)
output_high(MAX_WRITE);
fprintf(SER,"init\r\n");
output_low(MAX_WRITE);
|
Issue with the newer compiler: \r\n characters are not sent!
However, the following works well now
| Code: |
#use rs232(baud=9600,parity=N,xmit=PIN_B2,rcv=PIN_B1,bits=8,stream=SER,errors,enable=MAX_WRITE)
fprintf(SER,"init\r\n");
|
Therefore, in the first source code, it looks as if fprintf function returns before last two characters are written to the serial line, and the write pin of the MAX485 is therefore shut down too early.
Here is the proof - the following works well:
| Code: |
output_high(MAX_WRITE);
fprintf(SER,"init\r\n");
delay_ms(50);
output_low(MAX_WRITE);
|
It should be noted that it used to work without any problems with previous version of the compiler (For sure, it used to work with v3).
The reason why I want to control the MAX485 write pin manually is that I use fputc function within some functions, and I want the RS-485 line to be driven during processing all of those functions.
Has anyone of you experienced the same issue?
cheers,
Meereck |
|
 |
Ttelmah
Guest
|
|
| Posted: Wed Jul 08, 2009 8:28 am |
|
|
You don't say what chip is involved, but assuming that it has a hardware UART on pins B2/B1, the original code, should not work in _any_ CCS version......
The hardware UART, has two characters of hardware buffering. As shown, the line will go high before these are sent.
It suggests your old version was faulty, and using a software UART to send the characters, not the hardware one.
The correst way to do this, if you want to control the line manually, is to identify the bit in the chip's registers, that is 'TRMT' for the UART. Then your code needs to be:
| Code: |
#bit TRMT = 0xxx.n //address of TRMT bit here
output_high(MAX_WRITE);
fprintf(SER,"init\r\n");
while (TRMT==0);
output_low(MAX_WRITE);
|
The TRMT bit goes high, when the internal shift register for the UART empties, reflecting the data having been actually 'sent'.
Best Wishes |
|
|
meereck
Joined: 09 Nov 2006
Posts: 173
|
|
| Posted: Wed Jul 08, 2009 2:45 pm |
|
|
Ttelmah, thanks for clarification, I was thinking that would be the cause.
My source code was about 2 years old, I modified it few weeks ago, and recompiled with the new compiler version. Since that time, the issue had occured.
Unfortunately, I don't have the old firmware version so I cant say what was different, however, I just made minor changes.
The only reason (as I think), why the issue occured only now, is that it used to run on SW UART, and because of some weird reasons (have no clue why), it switched to HW UART - and the issue appeared.
Cheers,
Meereck |
|
|
Ttelmah
Guest
|
|
| Posted: Wed Jul 08, 2009 3:13 pm |
|
|
The 'timescale', possibly suggests a reasonably early 'working' V4 compiler (as opposed to the really early versions that probably would not give working code). So I'd not be at all surprised if it was using a software UART by mistake. If you give the chip version, somebody should be able to confirm if this was faulty on older compilers. However it sounds 100% as if this was the case.
Best Wishes |
|
|
meereck
Joined: 09 Nov 2006
Posts: 173
|
|
| Posted: Wed Jul 08, 2009 3:27 pm |
|
|
Right, I forgot to mention the model - 16F628A.
Originally, the code used to get compiled in version 3.242, not any v4.
But never mind, I am glad it has been solved. |
|
|
|
|
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
