On Oct 3, 11:15=A0pm, josephkk <joseph_barr...@sbcglobal.net> wrote:> On Mon, 3 Oct 2011 09:31:04 -0700 (PDT), linnix <m...@linnix.info-for.us> > wrote: > > > > > > >On Oct 3, 4:36=A0am, "Meindert Sprang" <m...@NOJUNKcustomORSPAMware.nl> > >wrote: > >> > I am pumping data from PIC24/Max3232 to PC at 115000 baud. =A0It wor=ks> >> > in burst of 4K blocks. =A0However, after 10K to 30K of data, the > >> > transmitter shutdown momentally. =A0The serial link is still up. =A0=I can> >> > issue a micro reset from the serial link, which is the fastest way t=o> >> > restart the transmission. =A0The average throughput is around 15000 =bps> >> > (bits), including the shutdown/reset cycle. =A0Without the reset cyc=le,> >> > i can probably get up to 25000 bps. > > >> > I am not sure if this is a logic (PIC24) or signal (Max3232) problem=.> >> > My guess is that the transmitter is overwhelming the Max3232 charge > >> > pump, which is running at 5V with 10uF cap on VCC and 1uF cap charge > >> > storages. =A0Would increasing caps help? > > >> First of all: check the signal on the output of the MAX3232 if that sh=uts> >> down. Probably not. > >> Is your baudrate exactly 115200? If not, you HAVE to insert silent per=iods> >> of at least one byte time to let the receiver resync on an idle state.=If> >> you send data over an async line and the baudrates don't match exactly=, you> >> end up with sync problems. > > >> Meindert > > >I am clocking with 12MHz crystal, 96MHz PLL and 32MHz CPU, so timing > >should be OK. =A0I have to insert turn around delay, =A0"put char" -> > >delay -> "get char". > >as well as transmitter empty checking: > >"put char" -> "check transmitter empty" =A0(reverse order will not work) > >to get it to work. > > >So, something is stopping it from running full duplex at full speed. > > Me suspects you never get to the problem without a scope. =A0Hunt places > like Craigs list, eprey, yard sales, surplus outlets for minimal scopes t=o> do the job, maybe real cheap 'bout <local>$10.More like $100 to $200, and another piece of junk, according to my wife. Yes, we would need to scope it piror to productions. The production shops should have the equipments to do so. For now, just looking for easy fix. I am going to try the Max232 (upto 250Kbps) rather than the Max3232 (up to 120Kpbs). We just change the VCC from 3.3V to 5V, so we don't need the Max3232 anyway.
Serial port throughput
Started by ●September 30, 2011
Reply by ●October 4, 20112011-10-04
Reply by ●October 4, 20112011-10-04
On 4.10.11 6:56 , linnix wrote:> On Oct 3, 11:15 pm, josephkk<joseph_barr...@sbcglobal.net> wrote: >> On Mon, 3 Oct 2011 09:31:04 -0700 (PDT), linnix<m...@linnix.info-for.us> >> wrote: >> >> >> >> >> >>> On Oct 3, 4:36 am, "Meindert Sprang"<m...@NOJUNKcustomORSPAMware.nl> >>> wrote: >>>>> I am pumping data from PIC24/Max3232 to PC at 115000 baud. It works >>>>> in burst of 4K blocks. However, after 10K to 30K of data, the >>>>> transmitter shutdown momentally. The serial link is still up. I can >>>>> issue a micro reset from the serial link, which is the fastest way to >>>>> restart the transmission. The average throughput is around 15000 bps >>>>> (bits), including the shutdown/reset cycle. Without the reset cycle, >>>>> i can probably get up to 25000 bps. >> >>>>> I am not sure if this is a logic (PIC24) or signal (Max3232) problem. >>>>> My guess is that the transmitter is overwhelming the Max3232 charge >>>>> pump, which is running at 5V with 10uF cap on VCC and 1uF cap charge >>>>> storages. Would increasing caps help? >> >>>> First of all: check the signal on the output of the MAX3232 if that shuts >>>> down. Probably not. >>>> Is your baudrate exactly 115200? If not, you HAVE to insert silent periods >>>> of at least one byte time to let the receiver resync on an idle state. If >>>> you send data over an async line and the baudrates don't match exactly, you >>>> end up with sync problems. >> >>>> Meindert >> >>> I am clocking with 12MHz crystal, 96MHz PLL and 32MHz CPU, so timing >>> should be OK. I have to insert turn around delay, "put char" -> >>> delay -> "get char". >>> as well as transmitter empty checking: >>> "put char" -> "check transmitter empty" (reverse order will not work) >>> to get it to work. >> >>> So, something is stopping it from running full duplex at full speed. >> >> Me suspects you never get to the problem without a scope. Hunt places >> like Craigs list, eprey, yard sales, surplus outlets for minimal scopes to >> do the job, maybe real cheap 'bout<local>$10. > > More like $100 to $200, and another piece of junk, according to my > wife. > > Yes, we would need to scope it piror to productions. The production > shops should have the equipments to do so. > > For now, just looking for easy fix. I am going to try the Max232 > (upto 250Kbps) rather than the Max3232 (up to 120Kpbs). We just > change the VCC from 3.3V to 5V, so we don't need the Max3232 anyway.You have already lost more time and effort in this mess than a cheap scope costs. In its own weird way, it is interesting to follow how long the guesswork will still last. 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. -- Tauno Voipio, and old and grumpy MSEE
Reply by ●October 4, 20112011-10-04
> 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. There might be a reason why Microchip's sample code test it after writing, not before.
Reply by ●October 4, 20112011-10-04
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. There might be a reason why > Microchip's sample code test it after writing, not before.I am entirely ignorant of Microchip devices... but this suggests a "stupid" question: are you sure that your "transmitter empty" test is using the correct logic sense, and is not a "transmitter not empty" test? -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .
Reply by ●October 4, 20112011-10-04
On Oct 4, 10:50=A0am, 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. =A0There might be a reason why > > Microchip's sample code test it after writing, not before. > > I am entirely ignorant of Microchip devices... but this suggests a > "stupid" question: are you sure that your "transmitter empty" test is > using the correct logic sense, and is not a "transmitter not empty" test?Yes, by flattering (coping) Microchip directly. For PIC32, there is even a NOP before testing. My quess is that they don't want some registers to be touched while transmitting.
Reply by ●October 4, 20112011-10-04
linnix wrote:> > On Oct 3, 11:15 pm, josephkk <joseph_barr...@sbcglobal.net> wrote: > > On Mon, 3 Oct 2011 09:31:04 -0700 (PDT), linnix <m...@linnix.info-for.us> > > wrote: > > > > > > > > > > > > >On Oct 3, 4:36 am, "Meindert Sprang" <m...@NOJUNKcustomORSPAMware.nl> > > >wrote: > > >> > I am pumping data from PIC24/Max3232 to PC at 115000 baud. It works > > >> > in burst of 4K blocks. However, after 10K to 30K of data, the > > >> > transmitter shutdown momentally. The serial link is still up. I can > > >> > issue a micro reset from the serial link, which is the fastest way to > > >> > restart the transmission. The average throughput is around 15000 bps > > >> > (bits), including the shutdown/reset cycle. Without the reset cycle, > > >> > i can probably get up to 25000 bps. > > > > >> > I am not sure if this is a logic (PIC24) or signal (Max3232) problem. > > >> > My guess is that the transmitter is overwhelming the Max3232 charge > > >> > pump, which is running at 5V with 10uF cap on VCC and 1uF cap charge > > >> > storages. Would increasing caps help? > > > > >> First of all: check the signal on the output of the MAX3232 if that shuts > > >> down. Probably not. > > >> Is your baudrate exactly 115200? If not, you HAVE to insert silent periods > > >> of at least one byte time to let the receiver resync on an idle state. If > > >> you send data over an async line and the baudrates don't match exactly, you > > >> end up with sync problems. > > > > >> Meindert > > > > >I am clocking with 12MHz crystal, 96MHz PLL and 32MHz CPU, so timing > > >should be OK. I have to insert turn around delay, "put char" -> > > >delay -> "get char". > > >as well as transmitter empty checking: > > >"put char" -> "check transmitter empty" (reverse order will not work) > > >to get it to work. > > > > >So, something is stopping it from running full duplex at full speed. > > > > Me suspects you never get to the problem without a scope. Hunt places > > like Craigs list, eprey, yard sales, surplus outlets for minimal scopes to > > do the job, maybe real cheap 'bout <local>$10. > > More like $100 to $200, and another piece of junk, according to my > wife.I recently picked up a free scope on Freecycle, along with a lot of other electronics. -- You can't have a sense of humor, if you have no sense.
Reply by ●October 4, 20112011-10-04
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?>>> There might be a reason why >>> Microchip's sample code test it after writing, not before. >> >> I am entirely ignorant of Microchip devices... but this suggests a >> "stupid" question: are you sure that your "transmitter empty" test is >> using the correct logic sense, and is not a "transmitter not empty" test? > > Yes, by flattering (coping) Microchip directly. For PIC32, there is > even a NOP before testing. My quess is that they don't want some > registers to be touched while transmitting.I wouldn't call that "being sure"... rather, "being trusting". It is not unknown for example code to have bugs. 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. HTH, -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .
Reply by ●October 4, 20112011-10-04
On a sunny day (Tue, 4 Oct 2011 11:12:23 -0700 (PDT)) it happened linnix <me@linnix.info-for.us> wrote in <fd12d19e-c1c0-483c-9201-2651576a464b@m37g2000yqc.googlegroups.com>:>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. �There might be a reason why >> > Microchip's sample code test it after writing, not before. >> >> I am entirely ignorant of Microchip devices... but this suggests a >> "stupid" question: are you sure that your "transmitter empty" test is >> using the correct logic sense, and is not a "transmitter not empty" test? > >Yes, by flattering (coping) Microchip directly. For PIC32, there is >even a NOP before testing. My quess is that they don't want some >registers to be touched while transmitting.There is no guarantee that the Microchip examples are correct. I know of at least 2 cases where they are not. And have read of one case that cost somebody a lot of money as they had to bring in a consultant to fix it. There is not even a guarantee the datasheets are correct or complete (examples exist) and no guarantee the hardware is correct, see silicon updates. Never assume, but measure, read those dataheets over and over again... Write test code.
Reply by ●October 4, 20112011-10-04
On Oct 4, 12:23=A0pm, 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 =3D ch; Nop(); while(U1STAbits.TRMT =3D=3D 0); bit 8 TRMT: 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.
Reply by ●October 4, 20112011-10-04
On Oct 4, 1:00=A0pm, linnix <m...@linnix.info-for.us> wrote:> On Oct 4, 12:23=A0pm, 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 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 (bu=t> > 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 ver=y> > sure that the check for register emptiness is done correctly, and is no=t> > inverted. > > =A0 =A0 U1TXREG =3D ch; > =A0 =A0 Nop(); > =A0 =A0 while(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.-The chip lock up if I reverse the test. So, the existing spec and code should be correct.
