On 4.10.11 11:00 , linnix wrote:> On Oct 4, 12:23 pm, Niklas Holsti<niklas.hol...@tidorum.invalid> > wrote: >> On 11-10-04 20:12 , linnix wrote: >> >>> On Oct 4, 10:50 am, Niklas Holsti<niklas.hol...@tidorum.invalid> >>> wrote: >>>> On 11-10-04 19:24 , linnix wrote: >> >>>>>> Methinks that you should start with putting the transmitter empty >>>>>> test before writing to the UART, to put the horse before the >>>>>> cart and not the other way round. >> >>>>> It stops all output immediately. >> >> Is some output received? Or is there no output at all? > > No output at all. The chip seems to lock up. > >> ... >> If you test UART register status after writing, and your test is really >> "is the register full", it will usually work, because you have just >> written to the register, so it is full. Your code then fetches the next >> byte to be sent, from wherever it is stored, and if that usually takes >> longer than the time the UART needs to transmit a byte, the register >> will have cleared in time, the next byte will go off correctly, and it >> will all seem to work. >> >> The fact is, your app does not work; so there is an error somewhere (but >> of course perhaps not in the SW). The fact that your app works >> differently when you test UART register emptiness before writing to the >> register, and after writing to the register, is fishy. I would make very >> sure that the check for register emptiness is done correctly, and is not >> inverted. >> > > U1TXREG = ch; > Nop(); > while(U1STAbits.TRMT == 0); > > bit 8 TRMT: Transmit Shift Register Empty > 0 = Transmit Shift Register is not empty, a transmission is in > progress or queued. > > unless the spec and sample codes are both wrong. > > I'll try reversing the test and see what happens.You're looking at the wrong bit. You should look at the UTXBF bit and wait until it is zero. The TRMT bit is intended for code controlling TX enable in line driver for e.g. RS-485. -- Tauno Voipio
Serial port throughput
Started by ●September 30, 2011
Reply by ●October 4, 20112011-10-04
Reply by ●October 4, 20112011-10-04
On Oct 4, 1:12=A0pm, Tauno Voipio <tauno.voi...@notused.fi.invalid> wrote:> On 4.10.11 11:00 , linnix wrote: > > > > > > > On Oct 4, 12:23 pm, Niklas Holsti<niklas.hol...@tidorum.invalid> > > wrote: > >> On 11-10-04 20:12 , linnix wrote: > > >>> On Oct 4, 10:50 am, Niklas Holsti<niklas.hol...@tidorum.invalid> > >>> wrote: > >>>> On 11-10-04 19:24 , linnix wrote: > > >>>>>> Methinks that you should start with putting the transmitter empty > >>>>>> test before writing to the UART, to put the horse before the > >>>>>> cart and not the other way round. > > >>>>> It stops all output immediately. > > >> Is some output received? Or is there no output at all? > > > No output at all. =A0The chip seems to lock up. > > >> ... > >> If you test UART register status after writing, and your test is reall=y> >> "is the register full", it will usually work, because you have just > >> written to the register, so it is full. Your code then fetches the nex=t> >> byte to be sent, from wherever it is stored, and if that usually takes > >> longer than the time the UART needs to transmit a byte, the register > >> will have cleared in time, the next byte will go off correctly, and it > >> will all seem to work. > > >> The fact is, your app does not work; so there is an error somewhere (b=ut> >> of course perhaps not in the SW). The fact that your app works > >> differently when you test UART register emptiness before writing to th=e> >> register, and after writing to the register, is fishy. I would make ve=ry> >> sure that the check for register emptiness is done correctly, and is n=ot> >> inverted. > > > =A0 =A0 =A0U1TXREG =3D ch; > > =A0 =A0 =A0Nop(); > > =A0 =A0 =A0while(U1STAbits.TRMT =3D=3D 0); > > > bit 8 =A0TRMT: Transmit Shift Register Empty > > 0 =3D Transmit Shift Register is not empty, a transmission is in > > progress or queued. > > > unless the spec and sample codes are both wrong. > > > I'll try reversing the test and see what happens. > > You're looking at the wrong bit. You should look at the UTXBF bit > and wait until it is zero. > > The TRMT bit is intended for code controlling TX enable in > line driver for e.g. RS-485. >OK, will try it. If that's the case, Microchip is putting out wrong demo code for every serial appt for PIC18,24 and 32.
Reply by ●October 4, 20112011-10-04
On Oct 4, 1:12=A0pm, Tauno Voipio <tauno.voi...@notused.fi.invalid> wrote:> On 4.10.11 11:00 , linnix wrote: > > > > > > > On Oct 4, 12:23 pm, Niklas Holsti<niklas.hol...@tidorum.invalid> > > wrote: > >> On 11-10-04 20:12 , linnix wrote: > > >>> On Oct 4, 10:50 am, Niklas Holsti<niklas.hol...@tidorum.invalid> > >>> wrote: > >>>> On 11-10-04 19:24 , linnix wrote: > > >>>>>> Methinks that you should start with putting the transmitter empty > >>>>>> test before writing to the UART, to put the horse before the > >>>>>> cart and not the other way round. > > >>>>> It stops all output immediately. > > >> Is some output received? Or is there no output at all? > > > No output at all. =A0The chip seems to lock up. > > >> ... > >> If you test UART register status after writing, and your test is reall=y> >> "is the register full", it will usually work, because you have just > >> written to the register, so it is full. Your code then fetches the nex=t> >> byte to be sent, from wherever it is stored, and if that usually takes > >> longer than the time the UART needs to transmit a byte, the register > >> will have cleared in time, the next byte will go off correctly, and it > >> will all seem to work. > > >> The fact is, your app does not work; so there is an error somewhere (b=ut> >> of course perhaps not in the SW). The fact that your app works > >> differently when you test UART register emptiness before writing to th=e> >> register, and after writing to the register, is fishy. I would make ve=ry> >> sure that the check for register emptiness is done correctly, and is n=ot> >> inverted. > > > =A0 =A0 =A0U1TXREG =3D ch; > > =A0 =A0 =A0Nop(); > > =A0 =A0 =A0while(U1STAbits.TRMT =3D=3D 0); > > > bit 8 =A0TRMT: Transmit Shift Register Empty > > 0 =3D Transmit Shift Register is not empty, a transmission is in > > progress or queued. > > > unless the spec and sample codes are both wrong. > > > I'll try reversing the test and see what happens. > > You're looking at the wrong bit. You should look at the UTXBF bit > and wait until it is zero. > > The TRMT bit is intended for code controlling TX enable in > line driver for e.g. RS-485. >Checking TRMT bypass the transmitter buffer. Checking UTXBF should be correct. However, it garbles the first few characters upon reset. Will try two sets of routines and see if it works.
Reply by ●October 5, 20112011-10-05
On 2011-10-03, linnix <me@linnix.info-for.us> wrote:> > The flow control lines are not assigned to any pins, so they should be > off by default. > I just added the line to disable flow control, but make no difference. >Oh well, so much for that idea. :-)> PIC24: > #define BAUDRATE2 115200UL > #define BRG_DIV2 4 > #define BRGH2 1 > #define BAUDRATEREG2 (((GetSystemClock()/2)+ > (BRG_DIV2/2*BAUDRATE2))/BRG_DIV2/BAUDRATE2-1) > U1BRG = BAUDRATEREG2; > U1MODE = 0; > U1MODEbits.BRGH = BRGH2; > U1STA = 0; > U1MODEbits.RTSMD= 1; // disable flow control > U1MODEbits.UARTEN = 1; > U1STAbits.UTXEN = 1; > 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 ? 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. 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). Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world
Reply by ●October 5, 20112011-10-05
On Oct 5, 4:37=A0am, Simon Clubley <clubley@remove_me.eisner.decus.org- Earth.UFP> wrote:> On 2011-10-03, linnix <m...@linnix.info-for.us> wrote: > > > > > The flow control lines are not assigned to any pins, so they should be > > off by default. > > I just added the line to disable flow control, but make no difference. > > Oh well, so much for that idea. :-) > > > PIC24 (uart init): > > =A0#define BAUDRATE2 =A0 =A0 =A0 115200UL > > =A0#define BRG_DIV2 =A0 =A0 =A0 =A04 > > =A0#define BRGH2 =A0 =A0 =A0 =A0 =A0 1 > > =A0#define BAUDRATEREG2 =A0 =A0 =A0 =A0(((GetSystemClock()/2)+ > > (BRG_DIV2/2*BAUDRATE2))/BRG_DIV2/BAUDRATE2-1) > > =A0U1BRG =3D BAUDRATEREG2; > > =A0U1MODE =3D 0; > > =A0U1MODEbits.BRGH =3D BRGH2; > > =A0U1STA =3D 0; > > =A0U1MODEbits.RTSMD=3D 1; =A0 =A0 =A0// disable flow control > > =A0U1MODEbits.UARTEN =3D 1; > > =A0U1STAbits.UTXEN =3D 1; > > =A0IFS0bits.U1RXIF =3D 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.> > 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.> > 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 !=3D 0); U1TXREG =3D ch; for(i=3D0; i<400; i++) // 25 usec Nop(); //while(U1STAbits.TRMT =3D=3D 0);
Reply by ●October 5, 20112011-10-05
On 2011-10-05, linnix <me@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 = BAUDRATEREG2; >> > �U1MODE = 0; >> > �U1MODEbits.BRGH = BRGH2; >> > �U1STA = 0; >> > �U1MODEbits.RTSMD= 1; � � �// disable flow control >> > �U1MODEbits.UARTEN = 1; >> > �U1STAbits.UTXEN = 1; >> > �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
Reply by ●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�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 = BAUDRATEREG2; > >> > �U1MODE = 0; > >> > �U1MODEbits.BRGH = BRGH2; > >> > �U1STA = 0; > >> > �U1MODEbits.RTSMD= 1; � � �// disable flow control > >> > �U1MODEbits.UARTEN = 1; > >> > �U1STAbits.UTXEN = 1; > >> > �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 ●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 ●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,.L38Mel.
Reply by ●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?
