I think it was already suggested: you need to enable flow-control. Either hardware if you've got the pins setup right on that port or software (xon/xoff) if you don't.
On Tue, Nov 12, 2013 at 4:11 AM, Raju B <raju3...@gmail.com> wrote: > Hi Michael, > > I have tried with baudrate = 9600 and 19200, then it is working fine(i.e > getting data, no overruns). but i want to use high speed(115200). can u > please give any suggestion to over come this. > > Thanks &r Regards, > Raju > > > On Thu, Nov 7, 2013 at 10:06 PM, Michael Durrant <mdurr...@uclinux.org>wrote: > >> Raju, >> >> I would expect data overruns causing lost characters if your CPU >> utilization is high and your kernel >> driver can't get back to servicing the UART IRQ fast enough. Your >> MCF523x part appears to have >> only a small FIFO buffer (a shift register and 3 receiver registers). >> So if the data rate is faster than >> the kernel can remove the data hardware FIFO it is likely you will miss >> data due to overruns. So >> in your case the 10th character was lost (overwritten) by the next >> character. Sounds like you need >> DMA support for the UART you are using or perhaps slow down the incoming >> data or perhaps >> turn hardware flow control on. >> >> Michael >> >> On 11/06/2013 04:40 AM, Raju B wrote: >> >> Hi Michael, >> >> The ColdFire is 523x and using UART serial interface. >> >> Thanks & regards, >> Raju B >> >> >> On Tue, Nov 5, 2013 at 10:47 PM, Michael Durrant >> <mdurr...@uclinux.org>wrote: >> >>> >>> Raj, >>> >>> Which ColdFire are you using? >>> Which serial interface are you seeing this with (UART/SPI/I2C/..)? >>> >>> Michael >>> >>> >>> On 11/05/2013 07:40 AM, Raju B wrote: >>> >>> whenever i am trying to receive data from serial communication >>> continuously in uClinux, I am getting every 10th byte is overwrite by 11 >>> byte and so on.... >>> >>> Iam using freescale coldfire processor. Could you any body please >>> help me to resolve this issue. >>> >>> Thanks & Regards, >>> Raj >>> >>> >>> On Fri, Sep 13, 2013 at 10:16 PM, Lennart Sorensen < >>> lsore...@csclub.uwaterloo.ca> wrote: >>> >>>> On Fri, Sep 13, 2013 at 11:28:52AM -0400, Bair, Richard wrote: >>>> > I have a 4.7MB application that runs on the 2.6.26 kernel (Freescale >>>> BSP) and am working to make it run on the 2.6.38 kernel released in the >>>> ColdFire BSP in Feb 2012. I'm concerned about memory allocation as my >>>> first attempt to run on the 38 kernel appears to be using 2^n memory >>>> allocation vs. allocation that sizes just 1-page over the application. >>>> > >>>> > 1) Can anyone tell me the exact kernel config name that needs to be >>>> adjusted for the 38 kernel to set the default memory allocation? >>>> > - Older posts indicate modules like page_alloc2 or Kmalloc2 >>>> control this so I'm going to investigate these in more detail >>>> > - RTFMing indicate that this might be the area but I don't see >>>> it in the 38 version (LTIB or make menucionfig): >>>> > menuconfig -> kernel settings -> general settings, try >>>> enabling either the "Permit large allocations" setting, or the >>>> "non-power-of-2" >>>> > >>>> > 2) Historically, we use LTIB to create the kernel. Does LTIB expose >>>> most/all settings of the 2.6.38 kernel? Can it be out of sync with the >>>> make menuconfig uClinus kernel? >>>> >>>> Maybe this changed the behaviour you see: >>>> >>>> commit fc4d5c292b68ef02514d2072dcbf82d090c34875 >>>> Author: David Howells <dhowe...@redhat.com> >>>> Date: Wed May 6 16:03:05 2009 -0700 >>>> >>>> nommu: make the initial mmap allocation excess behaviour Kconfig >>>> configurable >>>> >>>> NOMMU mmap() has an option controlled by a sysctl variable that >>>> determines >>>> whether the allocations made by do_mmap_private() should have the >>>> excess >>>> space trimmed off and returned to the allocator. Make the initial >>>> setting >>>> of this variable a Kconfig configuration option. >>>> >>>> The reason there can be excess space is that the allocator only >>>> allocates >>>> in power-of-2 size chunks, but mmap()'s can be made in sizes that >>>> aren't a >>>> power of 2. >>>> >>>> There are two alternatives: >>>> >>>> (1) Keep the excess as dead space. The dead space then remains >>>> unused for the >>>> lifetime of the mapping. Mappings of shared objects such as >>>> libc, ld.so >>>> or busybox's text segment may retain their dead space forever. >>>> >>>> (2) Return the excess to the allocator. This means that the dead >>>> space is >>>> limited to less than a page per mapping, but it means that for >>>> a transient >>>> process, there's more chance of fragmentation as the excess >>>> space may be >>>> reused fairly quickly. >>>> >>>> During the boot process, a lot of transient processes are created, >>>> and >>>> this can cause a lot of fragmentation as the pagecache and various >>>> slabs >>>> grow greatly during this time. >>>> >>>> By turning off the trimming of excess space during boot and >>>> disabling >>>> batching of frees, Coldfire can manage to boot. >>>> >>>> A better way of doing things might be to have /sbin/init turn this >>>> option >>>> off. By that point libc, ld.so and init - which are all >>>> long-duration >>>> processes - have all been loaded and trimmed. >>>> >>>> Reported-by: Lanttor Guo <lanttor....@freescale.com> >>>> Signed-off-by: David Howells <dhowe...@redhat.com> >>>> Tested-by: Lanttor Guo <lanttor....@freescale.com> >>>> Cc: Greg Ungerer <g...@snapgear.com> >>>> Signed-off-by: Andrew Morton <a...@linux-foundation.org> >>>> Signed-off-by: Linus Torvalds <torva...@linux-foundation.org> >>>> >>>> After all before this commit, trimming after allocating was always done. >>>> Now it is only done if you enable this CONFIG, or set the sysctl flag >>>> at runtime, which of course affects behaviour for all allocations after >>>> you change the setting. >>>> >>>> -- >>>> Len Sorensen >>>> _______________________________________________ >>>> uClinux-dev mailing list >>>> uClinux-dev@uclinux.org >>>> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev >>>> This message was resent by uclinux-dev@uclinux.org >>>> To unsubscribe see: >>>> http://mailman.uclinux.org/mailman/options/uclinux-dev >>>> >>> >>> >>> >>> _______________________________________________ >>> uClinux-dev mailing >>> listuClinux-dev@uclinux.orghttp://mailman.uclinux.org/mailman/listinfo/uclinux-dev >>> This message was resent by uclinux-dev@uclinux.org >>> To unsubscribe see:http://mailman.uclinux.org/mailman/options/uclinux-dev >>> >>> >>> >>> _______________________________________________ >>> uClinux-dev mailing list >>> uClinux-dev@uclinux.org >>> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev >>> This message was resent by uclinux-dev@uclinux.org >>> To unsubscribe see: >>> http://mailman.uclinux.org/mailman/options/uclinux-dev >>> >> >> >> >> _______________________________________________ >> uClinux-dev mailing >> listuClinux-dev@uclinux.orghttp://mailman.uclinux.org/mailman/listinfo/uclinux-dev >> This message was resent by uclinux-dev@uclinux.org >> To unsubscribe see:http://mailman.uclinux.org/mailman/options/uclinux-dev >> >> >> >> _______________________________________________ >> uClinux-dev mailing list >> uClinux-dev@uclinux.org >> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev >> This message was resent by uclinux-dev@uclinux.org >> To unsubscribe see: >> http://mailman.uclinux.org/mailman/options/uclinux-dev >> > > > _______________________________________________ > uClinux-dev mailing list > uClinux-dev@uclinux.org > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev > This message was resent by uclinux-dev@uclinux.org > To unsubscribe see: > http://mailman.uclinux.org/mailman/options/uclinux-dev >
_______________________________________________ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
