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
