 |
 |
| View previous topic :: View next topic |
| Author |
Message |
Storic
Joined: 03 Dec 2005
Posts: 182
Location: Australia SA
|
| not able to interrupt on received data on a 25J10 micro |
 Posted: Sun Jul 22, 2007 1:04 am |
 |
|
Hi,
with the example program EX_STWC, I have change the fuses to suit the 25J10 micro
| Code: | #include <18F25J10.h>
#device ADC=10
#FUSES NOWDT //No Watch Dog Timer
#FUSES NOPROTECT //Code not protected from reading
#FUSES WDT128 //Watch Dog Timer uses 1:128 Postscale
#FUSES H4_SW //High speed osc with SW enabled 4x PLL
//#FUSES NODEBUG //No Debug mode for ICD
//#FUSES NOXINST //Extended set extension and Indexed Addressing mode enabled
//#FUSES STVREN //Stack full/underflow will cause reset
//#FUSES FCMEN //Fail-safe clock monitor enabled
//#FUSES IESO //Internal External Switch Over mode enabled
//#FUSES PRIMARY //Primary clock is system clock when scs=00
//#FUSES RESERVED //Used to set the reserved FUSE bits
#use delay(clock=20000000)
#use rs232(baud=38400, xmit=PIN_C6, rcv=PIN_C7) |
however I can not received data from the PC Keyboard.
I am using a max13488 RS485 device with auto LAN direction sensing, I can send to the PC onto windows(hyper terminal) OK. however not back to the micro.
Using a cro, I can see the data from the PC via the MAX13488 RS485 chip onto the 18F25J10 micro PIN. (I even tried to reverse the TX/RX pin, but then I got nothing at all)
Has any one had a 18F25J10 micro Transmitting and receiving between the micro and the PC, if so is there an additional setting required for receiving correctly  
Using 4.045
_________________
What has been learnt if you make the same mistake?  |
|
 |
Ttelmah
Guest
|
|
| Posted: Sun Jul 22, 2007 2:28 am |
|
|
So, you hve the pull up loading on A, and pull down on B, and are actually seeing the data on the C7 input?.
What compiler version are you using?. (there have been quite a few problems with the 'J' chips on some of the compilers...).
Which example???
You talk about STWC, but the example for serial receive ISR driven, is SISR, whilethe one for transmit is STISR. I don't see, or know of a STWC example?.
Best Wishes |
|
|
Storic
Joined: 03 Dec 2005
Posts: 182
Location: Australia SA
|
|
| Posted: Sun Jul 22, 2007 3:34 am |
|
|
Compiler version 4.045
micro 18F25J10
on Hyper terminal screen
using SISR.C
| Quote: | Overall length:
Running...
Buffered data => __________________12312312312332112___________
Running...
Buffered data => ______________________________________________
Running...
(another Serial Prog)
(received)#0D#0ARunning...#0D#0A
(sent)Abcdefghijklmnopq rstuvwxyz
(received)#0D#0ABuffered data => ÿÿÿÿÿÿÿÿÿÿÿÿÿÿAbcdefghijklmnopqÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
|
I was depressing the numbers and get as above
I did get something, on the first run, however other event get nothing?
Just when I need to be able to RX data to do changed 
"did not know how to post a BMP file" the "_" are house shaped characters that did not transpose onto the post"
I was using the example program to test the micro in my PCB
I have 6 analog input and 4 Digital O/P on my PCB
4 x Port A have selectable Pu ups/down via a 10K resistor onto Port B 4,5,6,7. Port B no pull ups,
C6 and C7 into a MAX13488 (RS485)
_________________
What has been learnt if you make the same mistake?
Last edited by Storic on Sun Jul 22, 2007 5:00 am; edited 1 time in total |
|
|
Storic
Joined: 03 Dec 2005
Posts: 182
Location: Australia SA
|
|
| Posted: Sun Jul 22, 2007 4:07 am |
|
|
In looking at the microchip website for the errata I found 
| Quote: | 2.Module:EUSART
In asynchronous duplex communication, the
reception can get corrupted if any bit of the TXSTA
register is modified during a reception.
Work around
The CSRC (TXSTA<7>) bit should not be set.
Though this is a “don’t care” bit in Asynchronous
mode, make sure that this bit is not set.
3.Module:EUSART
In Synchronous mode, EUSART baud rates using
SPBRG values of ‘0’ and ‘1’ may not function
correctly.
Work around
Use another baud rate configuration to generate
the desired baud rate.
4.Module:EUSART
After the last received byte has been read from the
EUSART receive buffer, RCREG, the value is no
longer valid for subsequent read operations. The
RCREG register should only be read once for each
byte received.
Work around
After each byte is received from the EUSART,
store the byte into a user variable. To determine
when a byte is available to read from RCREG, poll
the RCIDL (BAUDCON<6>) bit for a low-to-high
transition, or use the EUSART Receive Interrupt
Flag, RCIF (PIR1<5>).
5.Module:EUSART
In 9-Bit Asynchronous, Full-Duplex, Receive
mode, received data may be corrupted if the TX9D
bit (TXSTA<0>) is not modified immediately after
RCIDL (BAUDCON<6>) is set.
Work around
Only write to TX9D when a reception is not in
progress (RCIDL = 1). No interrupt is associated
with RCIDL, therefore, it must be polled in software
to determine when TX9D can be updated. |
direct extract from 80269c.pdf 
_________________
What has been learnt if you make the same mistake? |
|
|
Ttelmah
Guest
|
|
| Posted: Sun Jul 22, 2007 6:13 am |
|
|
The data you are showing, suggests the PIC is continuously receiving data whan the bus is 'idle'. This is because the RS485 bus is not properly biased/terminated. Basically, on 485, there is no specification of what the bus should do, when it is not driven. The normal practice is to bias the bus, so the when not driven, the receivers _will_ see the bus as idle. This is _required_ by the Maxim chip you are using, if using the active turnroun mode. Bottom of page 12 of the data sheet. The normal practice, for a 100R bus termination, is to have 1K2R from +5v to A, then 120R from A to B, then 1K2R from B to 0V. This gives a termination impedance of 1/(1/120 + 1/1200 + 1/1200) = 100R, and gives A biased to 238mV above B, which correctly gives the required 'idle' voltage.
Best Wishes |
|
|
Storic
Joined: 03 Dec 2005
Posts: 182
Location: Australia SA
|
|
| Posted: Sun Jul 22, 2007 7:51 am |
|
|
Thanks,
I will try this out tomorrow. I look at that section you referred to however I went for a standard 10K pull up/ pull down just to hold however did not look at the bias factor "it is the first time I used these RS485 chips" 
_________________
What has been learnt if you make the same mistake? |
|
|
Storic
Joined: 03 Dec 2005
Posts: 182
Location: Australia SA
|
|
| Posted: Mon Jul 23, 2007 5:48 pm |
|
|
yes,
there is some sort of bias needed, (I am still to do)
I ended up removing the rs485 chip and driven via a rs232 chip. All works OK I wanted to prove the micro is OK fist then I can work on the rs485 chip.
I will now do the bias as suggested. Thanks you your help
_________________
What has been learnt if you make the same mistake? |
|
|
Storic
Joined: 03 Dec 2005
Posts: 182
Location: Australia SA
|
|
| Posted: Wed Aug 01, 2007 7:24 pm |
|
|
Well after exhausting several different RS485 Chips from different suppliers, sorting out levels between the J series micro, and the 5V RS485 chip. I finaly got it to work.
I was using 4.046 with the fault present, turns out I had upgraded to 4.047 and with out realizing it, It began to work. this is the final code I used to test
| Code: | #include <18F25J10.h>
#device adc=8
#FUSES NOWDT //No Watch Dog Timer
#FUSES WDT128 //Watch Dog Timer uses 1:128 Postscale
#FUSES H4_SW //High speed osc with SW enabled 4x PLL
#FUSES NODEBUG //No Debug mode for ICD
//#FUSES NOXINST //Extended set extension and Indexed Addressing mode enabled
#FUSES STVREN //Stack full/underflow will cause reset
#FUSES NOPROTECT //Code not protected from reading
#FUSES FCMEN //Fail-safe clock monitor enabled
#FUSES IESO //Internal External Switch Over mode enabled
#FUSES PRIMARY //Primary clock is system clock when scs=00
#FUSES RESERVED //Used to set the reserved FUSE bits
#use delay(clock=20000000)
//#use rs232(baud=38400,parity=N,xmit=PIN_C6,rcv=PIN_C7,bits=8,ERRORS)
#use rs232(stream=PC, baud=115200, xmit=PIN_C6, rcv=PIN_C7,enable = PIN_C1, ERRORS)
/*******************************INTERRUPT SUBROUTINE***************************/
//This interrupt occurs whenever Receive Pin of RS232 port receive any data
#INT_RDA
void Data_Receive()
{
int8 data;
data = fgetc(PC);
fputc(data, PC);
}
/**********************************MAIN FUNCTION*******************************/
void main()
{
enable_interrupts(INT_RDA);
enable_interrupts(GLOBAL);
while(true)
{
}
}
|
I did not keep a copy of V 4.046 so I was unable to verified that the fault was within the version (4.046), I only know it all works now, With the original "max13488 RS485 LAN device" and with the 10K pull up and Pull down.
Not happy with the time I spend working on this however learnt not to assume the compiler is OK, to be included when Looking at every avenue to resolve the fault in question.
_________________
What has been learnt if you make the same mistake? |
|
|
Ttelmah
Guest
|
|
| Posted: Thu Aug 02, 2007 2:26 am |
|
|
Please don't do this...
10k pullup, is _not_ a legitimate basing for RS485. You are effectively destroying the ability of the RS485 chip to give high speed long distance communication with reasonable data reliability, making it pointless to use these drivers. If you are only going point to point, over short distances, and want to avoid using the higher voltages of RS232, then use RS422 or RS423 instead.
At the moment you are being 'lucky' if this works, there is no guarantee that this will work on other batches of even the same chip.
RS485, is designed to drive a bus, with typically 100R characteristic impedance. It requires this bus to be terminated at each end, or you _will_ get ringing problems at higher rates as the bus gets longer.
For sort runs, higher impedances, and termination at the receiver only will work.
Look at application note 723 on the Maxim site. Note particularly the following paragraph 'Fail safe':
| Code: |
Deciding whether you need a termination resistor or not is only part of the problem in implementing an RS-485 system. Normally, an RS-485 receiver output is "1" if A > B by +200mV or more, and "0" if B > A by 200mV or more. In a half-duplex RS-485 network, the master transceiver tri-states the bus after transmitting a message to the slaves. Then, with no signal driving the bus, the receiver's output state is undefined, as the difference between A and B tends towards 0V. If the receiver output, RO, is "0," the slaves interpret it as a new start bit and attempt to read the following byte. The result is a framing error because the stop bit never occurs. The bus goes unclaimed, and the network stalls.
Unfortunately, different runs of chips can produce different output signals on RO for a 0V differential input. The prototype can work perfectly, however, certain nodes will fail in a later production run. To solve this problem, bias the bus as shown in Figure 7 under Multidrop/Fail-Safe Termination. Biasing the bus ensures that the receiver output remains "1" when the bus is tri-stated. Alternatively, you can use "true fail-safe" receivers like those of the MAX3080 (5V) and MAX3070 (3V) families. These devices ensure an RO output of "1" in response to a 0V differential input by changing the receiver's threshold to -50mV.
|
Note the comments about chip batches. You _must_ properly bias the RS485 bus, or use receivers designed to treat a floating bus as legitimate.
Best Wishes |
|
|
Storic
Joined: 03 Dec 2005
Posts: 182
Location: Australia SA
|
|
| Posted: Thu Aug 02, 2007 3:28 am |
|
|
I was only showing from another board that I have not modified to the as suggested biasing, It was able to work with the same program,
Sorry if I implied that the 10K was correct. I will be doing as you suggested and to the application note.
I was only glad it is working now 
_________________
What has been learnt if you make the same mistake? |
|
|
Storic
Joined: 03 Dec 2005
Posts: 182
Location: Australia SA
|
|
|
|
|
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
