Reply by linnix October 11, 20112011-10-11
On Oct 6, 3:06=A0pm, linnix <m...@linnix.info-for.us> wrote:
> On Oct 6, 2:45=A0pm, Mark Borgerson <mborger...@comcast.net> wrote: > > > > > > > In article <4bc92b5f-9485-4594-8f46-527f42b62913@ > > 20g2000yqq.googlegroups.com>, m...@linnix.info-for.us says... > > > > Microchip assembler codes are very difficult to read, but here it is: > > > If you get rid of all the junk put in there by the compiler for > > its own housekeeping, the actual assembly isn't all that > > difficult to understand. =A0I'm not entirely clear on the > > relationship between WREG and w0 in the two lines > > after .L38: =A0 =A0That is due to my ignorance of the > > architecture of this particular PIC chip. =A0 On other > > chips, I would guess that the code is loading into > > one register, then checking another. =A0But then it is > > possible that one of those deleted directives is > > telling us that WREG is really wO. > > > It looks like the character to be sent arrives in w0 > > > > _UART1PutChar: > > > =A0 =A0mov.b =A0 w0,w1 > > > .L38: > > > =A0 =A0mov.b =A0 _U1STAbits+1,WREG > > > =A0 =A0btst =A0 =A0w0,#1 > > > =A0 =A0bra =A0 =A0 nz,.L38 > > > =A0 =A0se =A0 =A0 =A0w1,w0 > > > =A0 =A0mov =A0 =A0 w0,_U1TXREG > > > =A0 =A0mov =A0 =A0 #400,w0 > > > .L40: > > > =A0 =A0nop > > > =A0 =A0dec =A0 =A0 w0,w0 > > > =A0 =A0bra =A0 =A0 nz,.L40 > > > =A0 =A0return > > > The remaining questions are: > > > is bit #1 =A0of the register at =A0_U1STAbits+1 =A0the proper bit > > to be testing? =A0You should verify this with the data sheet. > > Bit 9 of U1StA or bit 1 of U1STA+1. =A0It is the transmitter buffer > empty flag when 0
Just got some TI max232. Running without delay now. while(U1STAbits.UTXBF !=3D 0); U1TXREG =3D ch; I have to conclude that TI max3232 does not meet the spec. Thank everyone for responding to this issue.
Reply by linnix October 6, 20112011-10-06
On Oct 6, 2:45=A0pm, Mark Borgerson <mborger...@comcast.net> wrote:
> In article <4bc92b5f-9485-4594-8f46-527f42b62913@ > 20g2000yqq.googlegroups.com>, m...@linnix.info-for.us says... > > > Microchip assembler codes are very difficult to read, but here it is: > > If you get rid of all the junk put in there by the compiler for > its own housekeeping, the actual assembly isn't all that > difficult to understand. =A0I'm not entirely clear on the > relationship between WREG and w0 in the two lines > after .L38: =A0 =A0That is due to my ignorance of the > architecture of this particular PIC chip. =A0 On other > chips, I would guess that the code is loading into > one register, then checking another. =A0But then it is > possible that one of those deleted directives is > telling us that WREG is really wO. > > It looks like the character to be sent arrives in w0 > > > _UART1PutChar: > > =A0 =A0mov.b =A0 w0,w1 > > .L38: > > =A0 =A0mov.b =A0 _U1STAbits+1,WREG > > =A0 =A0btst =A0 =A0w0,#1 > > =A0 =A0bra =A0 =A0 nz,.L38 > > =A0 =A0se =A0 =A0 =A0w1,w0 > > =A0 =A0mov =A0 =A0 w0,_U1TXREG > > =A0 =A0mov =A0 =A0 #400,w0 > > .L40: > > =A0 =A0nop > > =A0 =A0dec =A0 =A0 w0,w0 > > =A0 =A0bra =A0 =A0 nz,.L40 > > =A0 =A0return > > The remaining questions are: > > is bit #1 =A0of the register at =A0_U1STAbits+1 =A0the proper bit > to be testing? =A0You should verify this with the data sheet.
Bit 9 of U1StA or bit 1 of U1STA+1. It is the transmitter buffer empty flag when 0.
Reply by linnix October 6, 20112011-10-06
On Oct 6, 9:46=A0am, Rocky <robertg...@gmail.com> wrote:
> On Oct 1, 5:27=A0pm, linnix <m...@linnix.info-for.us> wrote: > > > > > On Sep 30, 11:32=A0pm, Rocky <robertg...@gmail.com> wrote: > > > > On Sep 30, 7:59=A0pm, linnix <m...@linnix.info-for.us> wrote: > > > > > On Sep 30, 10:46=A0am, Rocky <robertg...@gmail.com> wrote: > > > > > > On Sep 30, 6:56=A0pm, linnix <m...@linnix.info-for.us> wrote: > > > > > > > I am pumping data from PIC24/Max3232 to PC at 115000 baud. =A0I=
t works
> > > > > > in burst of 4K blocks. =A0However, after 10K to 30K of data, th=
e
> > > > > > transmitter shutdown momentally. =A0The serial link is still up=
. =A0I can
> > > > > > issue a micro reset from the serial link, which is the fastest =
way to
> > > > > > restart the transmission. =A0The average throughput is around 1=
5000 bps
> > > > > > (bits), including the shutdown/reset cycle. =A0Without the rese=
t cycle,
> > > > > > i can probably get up to 25000 bps. > > > > > > > I am not sure if this is a logic (PIC24) or signal (Max3232) pr=
oblem.
> > > > > > My guess is that the transmitter is overwhelming the Max3232 ch=
arge
> > > > > > pump, which is running at 5V with 10uF cap on VCC and 1uF cap c=
harge
> > > > > > storages. =A0Would increasing caps help? > > > > > > I presume you're using a circular buffer - putch or suchlike to i=
nsert
> > > > > characters and the interrupt extracts them. > > > > > > Do you have BufOp (the interrupt output pointer) declared as vola=
tile?
> > > > > Check that every time you add a character to the buffer that you > > > > > enable the TX interrupt and that you ONLY extract characters in t=
he
> > > > > interrupt routine and don't try and output a character directly i=
f the
> > > > > UART is currently not busy. You should be getting throughtput of > > > > > closer to 90kbps. > > > > > It's not interrupt driven. =A0Actually, i am using the Microchip sa=
mple
> > > > code to slow down the port: > > > > > =A0 =A0 U1TXREG =3D ch; > > > > =A0 =A0 Nop(); > > > > =A0 =A0 while(U1STAbits.TRMT =3D=3D 0); > > > > Which particular PIC24? > > > PIC24FJ256DA206 > > To which pins do you have the UART mapped? Did you lock the IO after > mapping?-
RP26 for RX and RP10 for TX.
Reply by Mark Borgerson October 6, 20112011-10-06
In article <4bc92b5f-9485-4594-8f46-527f42b62913@
20g2000yqq.googlegroups.com>, me@linnix.info-for.us says...

> Microchip assembler codes are very difficult to read, but here it is:
If you get rid of all the junk put in there by the compiler for its own housekeeping, the actual assembly isn't all that difficult to understand. I'm not entirely clear on the relationship between WREG and w0 in the two lines after .L38: That is due to my ignorance of the architecture of this particular PIC chip. On other chips, I would guess that the code is loading into one register, then checking another. But then it is possible that one of those deleted directives is telling us that WREG is really wO. It looks like the character to be sent arrives in w0
> _UART1PutChar: > mov.b w0,w1 > .L38: > mov.b _U1STAbits+1,WREG > btst w0,#1 > bra nz,.L38 > se w1,w0 > mov w0,_U1TXREG > mov #400,w0 > .L40: > nop > dec w0,w0 > bra nz,.L40 > return
The remaining questions are: is bit #1 of the register at _U1STAbits+1 the proper bit to be testing? You should verify this with the data sheet. Is that bit 1 when there is still data being transmitted? It doesn't look like the register loads are being skipped--- something that you can see if the registers aren't defined properly as volatile. Mark Borgerson
Reply by Rocky October 6, 20112011-10-06
On Oct 1, 5:27=A0pm, linnix <m...@linnix.info-for.us> wrote:
> On Sep 30, 11:32=A0pm, Rocky <robertg...@gmail.com> wrote: > > > > > > > On Sep 30, 7:59=A0pm, linnix <m...@linnix.info-for.us> wrote: > > > > On Sep 30, 10:46=A0am, Rocky <robertg...@gmail.com> wrote: > > > > > On Sep 30, 6:56=A0pm, linnix <m...@linnix.info-for.us> wrote: > > > > > > I am pumping data from PIC24/Max3232 to PC at 115000 baud. =A0It =
works
> > > > > in burst of 4K blocks. =A0However, after 10K to 30K of data, the > > > > > transmitter shutdown momentally. =A0The serial link is still up. =
=A0I can
> > > > > issue a micro reset from the serial link, which is the fastest wa=
y to
> > > > > restart the transmission. =A0The average throughput is around 150=
00 bps
> > > > > (bits), including the shutdown/reset cycle. =A0Without the reset =
cycle,
> > > > > i can probably get up to 25000 bps. > > > > > > I am not sure if this is a logic (PIC24) or signal (Max3232) prob=
lem.
> > > > > My guess is that the transmitter is overwhelming the Max3232 char=
ge
> > > > > pump, which is running at 5V with 10uF cap on VCC and 1uF cap cha=
rge
> > > > > storages. =A0Would increasing caps help? > > > > > I presume you're using a circular buffer - putch or suchlike to ins=
ert
> > > > characters and the interrupt extracts them. > > > > > Do you have BufOp (the interrupt output pointer) declared as volati=
le?
> > > > Check that every time you add a character to the buffer that you > > > > enable the TX interrupt and that you ONLY extract characters in the > > > > interrupt routine and don't try and output a character directly if =
the
> > > > UART is currently not busy. You should be getting throughtput of > > > > closer to 90kbps. > > > > It's not interrupt driven. =A0Actually, i am using the Microchip samp=
le
> > > code to slow down the port: > > > > =A0 =A0 U1TXREG =3D ch; > > > =A0 =A0 Nop(); > > > =A0 =A0 while(U1STAbits.TRMT =3D=3D 0); > > > Which particular PIC24? > > PIC24FJ256DA206 >
To which pins do you have the UART mapped? Did you lock the IO after mapping?
Reply by Rocky October 6, 20112011-10-06
On Oct 1, 5:27=A0pm, linnix <m...@linnix.info-for.us> wrote:
> On Sep 30, 11:32=A0pm, Rocky <robertg...@gmail.com> wrote: > > > > > > > On Sep 30, 7:59=A0pm, linnix <m...@linnix.info-for.us> wrote: > > > > On Sep 30, 10:46=A0am, Rocky <robertg...@gmail.com> wrote: > > > > > On Sep 30, 6:56=A0pm, linnix <m...@linnix.info-for.us> wrote: > > > > > > I am pumping data from PIC24/Max3232 to PC at 115000 baud. =A0It =
works
> > > > > in burst of 4K blocks. =A0However, after 10K to 30K of data, the > > > > > transmitter shutdown momentally. =A0The serial link is still up. =
=A0I can
> > > > > issue a micro reset from the serial link, which is the fastest wa=
y to
> > > > > restart the transmission. =A0The average throughput is around 150=
00 bps
> > > > > (bits), including the shutdown/reset cycle. =A0Without the reset =
cycle,
> > > > > i can probably get up to 25000 bps. > > > > > > I am not sure if this is a logic (PIC24) or signal (Max3232) prob=
lem.
> > > > > My guess is that the transmitter is overwhelming the Max3232 char=
ge
> > > > > pump, which is running at 5V with 10uF cap on VCC and 1uF cap cha=
rge
> > > > > storages. =A0Would increasing caps help? > > > > > I presume you're using a circular buffer - putch or suchlike to ins=
ert
> > > > characters and the interrupt extracts them. > > > > > Do you have BufOp (the interrupt output pointer) declared as volati=
le?
> > > > Check that every time you add a character to the buffer that you > > > > enable the TX interrupt and that you ONLY extract characters in the > > > > interrupt routine and don't try and output a character directly if =
the
> > > > UART is currently not busy. You should be getting throughtput of > > > > closer to 90kbps. > > > > It's not interrupt driven. =A0Actually, i am using the Microchip samp=
le
> > > code to slow down the port: > > > > =A0 =A0 U1TXREG =3D ch; > > > =A0 =A0 Nop(); > > > =A0 =A0 while(U1STAbits.TRMT =3D=3D 0); > > > Which particular PIC24? > > PIC24FJ256DA206 >
To which pins did you map the UART? And did you lock the IO mapping afterwards?
Reply by Mel October 5, 20112011-10-05
linnix wrote:

> On Oct 5, 2:48 pm, Mark Borgerson <mborger...@comcast.net> wrote: >> It would be interesting to see what code the compiler is actually >> generating for >> >> while(U1STAbits.UTXBF != 0); >> >> How does it translate the element of the status bits structure?
So this would be it, then?
> mov.b _U1STAbits+1,WREG > btst w0,#1 > .set ___BP___,89 > bra nz,.L38
Mel.
Reply by linnix October 5, 20112011-10-05
On Oct 5, 2:48=A0pm, Mark Borgerson <mborger...@comcast.net> wrote:
> In article <j6id3i$ac...@dont-email.me>, > clubley@remove_me.eisner.decus.org-Earth.UFP says... > > > > > > > > > On 2011-10-05, linnix <m...@linnix.info-for.us> wrote: > > > On Oct 5, 4:37 am, Simon Clubley <clubley@remove_me.eisner.decus.org- > > > Earth.UFP> wrote: > > >> On 2011-10-03, linnix <m...@linnix.info-for.us> wrote: > > > >> > PIC24 (uart init): > > >> > #define BAUDRATE2 115200UL > > >> > #define BRG_DIV2 4 > > >> > #define BRGH2 1 > > >> > #define BAUDRATEREG2 (((GetSystemClock()/2)+ > > >> > (BRG_DIV2/2*BAUDRATE2))/BRG_DIV2/BAUDRATE2-1) > > >> > U1BRG =3D BAUDRATEREG2; > > >> > U1MODE =3D 0; > > >> > U1MODEbits.BRGH =3D BRGH2; > > >> > U1STA =3D 0; > > >> > U1MODEbits.RTSMD=3D 1; // disable flow control > > >> > U1MODEbits.UARTEN =3D 1; > > >> > U1STAbits.UTXEN =3D 1; > > >> > IFS0bits.U1RXIF =3D 0; > > > >> There are two questionable areas about the above code which I see. O=
nce
> > >> again, I have not used this architecture and I am going purely by wh=
at is
> > >> written in the PIC24F familiy reference manual. > > > >> 1) You write U1BRG before writing BRGH. Given that writing U1BRG has > > >> immediate effects, is this a problem ? > > > > Should not be a problem. =A0We are not doing I/O yet. > > > I was thinking of this comment in section 21.3 of the PIC24F Family > > Reference Manual when I wrote that: > > > |Writing a new value to the UxBRG register causes the BRG timer to be r=
eset
> > |(cleared). This ensures the BRG does not wait for a timer overflow bef=
ore
> > |generating the new baud rate. > > > Writing the U1BRG register is the trigger for resetting the timer. Howe=
ver,
> > when you do this, BRGH is still 0 so the value will be misinterpreted. > > > What the reference manual does not say is what happens when these field=
s
> > are written while the UART is disabled. > > > I noticed in another message you said you were getting junk for the fir=
st
> > few characters. I wonder if this is why. > > > >> 2) The BAUDRATEREG2 calculation has a baudrate related term for the =
clock
> > >> speed which does not appear in the reference manual. However, when y=
ou
> > >> do the calculation manually, it's does not appear to be a large enou=
gh
> > >> value (when using bc) to make a difference in the final result. > > > > GetSystemClock() is just a macro returning 32000000. =A0PIC24 needs 2 > > > clock cycle per instruction. > > > I was thinking the extra term after GetSystemClock(), but having had > > another look, I realise it's to make the calculation round instead of > > truncate. > > > >> BTW, are you turning off the transmitter between characters before > > >> turning it back on to transmit the next character ? I've been caught > > >> by a MCU which can lose characters when you do that (if the previous > > >> character is still been transmitted). > > > > No, I am not touching the UART registers outside init, get and put. > > > > Still need a 25usec delay after transmitting. > > > > =A0 =A0 // check UTXBF until it is zero. > > > =A0 =A0 while(U1STAbits.UTXBF !=3D 0); > > > =A0 =A0 U1TXREG =3D ch; > > > =A0 =A0 for(i=3D0; i<400; i++) =A0 // 25 usec > > > =A0 =A0 =A0 Nop(); > > > =A0 =A0 //while(U1STAbits.TRMT =3D=3D 0); > > > Ok, that is strange. I assume all the relevant variables are declared > > as volatile ? > > It would be interesting to see what code the compiler is actually > generating for > > =A0 =A0while(U1STAbits.UTXBF !=3D 0); > > How does it translate the element of the status bits structure?
Microchip assembler codes are very difficult to read, but here it is: .def _UART1PutChar .val _UART1PutChar .scl 2 .type 041 .endef .global _UART1PutChar ; export _UART1PutChar: .def .bf .val . .scl 101 .line 290 .endef .def _ch .val 1 .scl 17 .type 02 .endef .def .bb .val . .scl 100 .line 290 .endef .set ___PA___,1 mov.b w0,w1 .def ___FP .val 15 .scl 4 .type 4 .endef .L38: .ln 294 mov.b _U1STAbits+1,WREG btst w0,#1 .set ___BP___,89 bra nz,.L38 .ln 295 se w1,w0 mov w0,_U1TXREG mov #400,w0 .L40: .ln 297 nop dec w0,w0 .ln 296 .set ___BP___,99 bra nz,.L40 .ln 299 return .set ___PA___,0 .def .eb .val . .scl 100 .line 299 .endef .def .ef .val . .scl 101 .line 299 .endef .def _UART1PutChar .val . .scl -1 .endef
Reply by Mark Borgerson October 5, 20112011-10-05
In article <j6id3i$acm$1@dont-email.me>, 
clubley@remove_me.eisner.decus.org-Earth.UFP says...
> > On 2011-10-05, linnix <me@linnix.info-for.us> wrote: > > On Oct 5, 4:37&#4294967295;am, Simon Clubley <clubley@remove_me.eisner.decus.org- > > Earth.UFP> wrote: > >> On 2011-10-03, linnix <m...@linnix.info-for.us> wrote: > >> > >> > PIC24 (uart init): > >> > &#4294967295;#define BAUDRATE2 &#4294967295; &#4294967295; &#4294967295; 115200UL > >> > &#4294967295;#define BRG_DIV2 &#4294967295; &#4294967295; &#4294967295; &#4294967295;4 > >> > &#4294967295;#define BRGH2 &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; 1 > >> > &#4294967295;#define BAUDRATEREG2 &#4294967295; &#4294967295; &#4294967295; &#4294967295;(((GetSystemClock()/2)+ > >> > (BRG_DIV2/2*BAUDRATE2))/BRG_DIV2/BAUDRATE2-1) > >> > &#4294967295;U1BRG = BAUDRATEREG2; > >> > &#4294967295;U1MODE = 0; > >> > &#4294967295;U1MODEbits.BRGH = BRGH2; > >> > &#4294967295;U1STA = 0; > >> > &#4294967295;U1MODEbits.RTSMD= 1; &#4294967295; &#4294967295; &#4294967295;// disable flow control > >> > &#4294967295;U1MODEbits.UARTEN = 1; > >> > &#4294967295;U1STAbits.UTXEN = 1; > >> > &#4294967295;IFS0bits.U1RXIF = 0; > >> > >> There are two questionable areas about the above code which I see. Once > >> again, I have not used this architecture and I am going purely by what is > >> written in the PIC24F familiy reference manual. > >> > >> 1) You write U1BRG before writing BRGH. Given that writing U1BRG has > >> immediate effects, is this a problem ? > > > > Should not be a problem. We are not doing I/O yet. > > > > I was thinking of this comment in section 21.3 of the PIC24F Family > Reference Manual when I wrote that: > > |Writing a new value to the UxBRG register causes the BRG timer to be reset > |(cleared). This ensures the BRG does not wait for a timer overflow before > |generating the new baud rate. > > Writing the U1BRG register is the trigger for resetting the timer. However, > when you do this, BRGH is still 0 so the value will be misinterpreted. > > What the reference manual does not say is what happens when these fields > are written while the UART is disabled. > > I noticed in another message you said you were getting junk for the first > few characters. I wonder if this is why. > > >> > >> 2) The BAUDRATEREG2 calculation has a baudrate related term for the clock > >> speed which does not appear in the reference manual. However, when you > >> do the calculation manually, it's does not appear to be a large enough > >> value (when using bc) to make a difference in the final result. > > > > GetSystemClock() is just a macro returning 32000000. PIC24 needs 2 > > clock cycle per instruction. > > > > I was thinking the extra term after GetSystemClock(), but having had > another look, I realise it's to make the calculation round instead of > truncate. > > >> > >> BTW, are you turning off the transmitter between characters before > >> turning it back on to transmit the next character ? I've been caught > >> by a MCU which can lose characters when you do that (if the previous > >> character is still been transmitted). > > > > No, I am not touching the UART registers outside init, get and put. > > > > Still need a 25usec delay after transmitting. > > > > // check UTXBF until it is zero. > > while(U1STAbits.UTXBF != 0); > > U1TXREG = ch; > > for(i=0; i<400; i++) // 25 usec > > Nop(); > > //while(U1STAbits.TRMT == 0); > > Ok, that is strange. I assume all the relevant variables are declared > as volatile ? >
It would be interesting to see what code the compiler is actually generating for while(U1STAbits.UTXBF != 0); How does it translate the element of the status bits structure?
> Apart from that, since I have not actually used this architecture, I have > no more ideas. > > Simon.
Mark Borgerson
Reply by Simon Clubley October 5, 20112011-10-05
On 2011-10-05, linnix <me@linnix.info-for.us> wrote:
> On Oct 5, 4:37&#4294967295;am, Simon Clubley <clubley@remove_me.eisner.decus.org- > Earth.UFP> wrote: >> On 2011-10-03, linnix <m...@linnix.info-for.us> wrote: >> >> > PIC24 (uart init): >> > &#4294967295;#define BAUDRATE2 &#4294967295; &#4294967295; &#4294967295; 115200UL >> > &#4294967295;#define BRG_DIV2 &#4294967295; &#4294967295; &#4294967295; &#4294967295;4 >> > &#4294967295;#define BRGH2 &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; 1 >> > &#4294967295;#define BAUDRATEREG2 &#4294967295; &#4294967295; &#4294967295; &#4294967295;(((GetSystemClock()/2)+ >> > (BRG_DIV2/2*BAUDRATE2))/BRG_DIV2/BAUDRATE2-1) >> > &#4294967295;U1BRG = BAUDRATEREG2; >> > &#4294967295;U1MODE = 0; >> > &#4294967295;U1MODEbits.BRGH = BRGH2; >> > &#4294967295;U1STA = 0; >> > &#4294967295;U1MODEbits.RTSMD= 1; &#4294967295; &#4294967295; &#4294967295;// disable flow control >> > &#4294967295;U1MODEbits.UARTEN = 1; >> > &#4294967295;U1STAbits.UTXEN = 1; >> > &#4294967295;IFS0bits.U1RXIF = 0; >> >> There are two questionable areas about the above code which I see. Once >> again, I have not used this architecture and I am going purely by what is >> written in the PIC24F familiy reference manual. >> >> 1) You write U1BRG before writing BRGH. Given that writing U1BRG has >> immediate effects, is this a problem ? > > Should not be a problem. We are not doing I/O yet. >
I was thinking of this comment in section 21.3 of the PIC24F Family Reference Manual when I wrote that: |Writing a new value to the UxBRG register causes the BRG timer to be reset |(cleared). This ensures the BRG does not wait for a timer overflow before |generating the new baud rate. Writing the U1BRG register is the trigger for resetting the timer. However, when you do this, BRGH is still 0 so the value will be misinterpreted. What the reference manual does not say is what happens when these fields are written while the UART is disabled. I noticed in another message you said you were getting junk for the first few characters. I wonder if this is why.
>> >> 2) The BAUDRATEREG2 calculation has a baudrate related term for the clock >> speed which does not appear in the reference manual. However, when you >> do the calculation manually, it's does not appear to be a large enough >> value (when using bc) to make a difference in the final result. > > GetSystemClock() is just a macro returning 32000000. PIC24 needs 2 > clock cycle per instruction. >
I was thinking the extra term after GetSystemClock(), but having had another look, I realise it's to make the calculation round instead of truncate.
>> >> BTW, are you turning off the transmitter between characters before >> turning it back on to transmit the next character ? I've been caught >> by a MCU which can lose characters when you do that (if the previous >> character is still been transmitted). > > No, I am not touching the UART registers outside init, get and put. > > Still need a 25usec delay after transmitting. > > // check UTXBF until it is zero. > while(U1STAbits.UTXBF != 0); > U1TXREG = ch; > for(i=0; i<400; i++) // 25 usec > Nop(); > //while(U1STAbits.TRMT == 0);
Ok, that is strange. I assume all the relevant variables are declared as volatile ? Apart from that, since I have not actually used this architecture, I have no more ideas. Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world