On Fri, Oct 24, 2014 at 2:16 PM, Daniel Gutson <daniel.gut...@tallertechnologies.com> wrote: > On Fri, Oct 24, 2014 at 2:33 AM, Sebastian Huber > <sebastian.hu...@embedded-brains.de> wrote: >> On 23/10/14 18:12, Daniel Gutson wrote: >>> >>> On Thu, Oct 23, 2014 at 5:47 AM, Sebastian Huber >>> <sebastian.hu...@embedded-brains.de> wrote: >>>> >>>> >Hello Daniel, >>> >>> Hi Sebastian, >>> >>>> > >>>> >I never notice a problem with this driver. It should only write to the >>>> > FIFO >>>> >in case it is completely empty. Did you observe problems? >>> >>> no, I didn't (actually I found this while looking for a serial bug >>> which turned out to be due >>> to a different cause). >>> However, I notice that this isn't like what the polling write does (of >>> course I'm not talking >>> about the polling/interrput difference, but when writing byte-per-byte >>> to the FIFO, I think >>> both methods should do the same). >>> IOW, what happens if the 'for' loop is too fast for the device? Will >>> the latter be able to >>> put the char in the FIFO and be ready for the next one? Isn't >>> SP_LSR_THOLD exactly >>> to tell whether the device' FIFO is ready to accept the next byte? >>> Writing to the FIFO when it's completely empty is not the problem I >>> see since it is >>> guaranteed by the interrupt. My concern is different: it's whether the >>> FIFO is filled too fast >>> for the device. >>> >>> >> >> Its not clear to me from the documentation if this is really necessary. I >> never noticed problems on several targets with this driver.
FWIW, we asked TI about this: http://e2e.ti.com/support/arm/sitara_arm/f/791/p/378177/1331822.aspx#1331822 In short: they explained that the register is not needed when in FIFO mode, which is the case (but it is needed when writing byte-per-byte). Daniel. > > Ok. > >> >> >> -- >> Sebastian Huber, embedded brains GmbH >> >> Address : Dornierstr. 4, D-82178 Puchheim, Germany >> Phone : +49 89 189 47 41-16 >> Fax : +49 89 189 47 41-09 >> E-Mail : sebastian.hu...@embedded-brains.de >> PGP : Public key available on request. >> >> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. > > > > -- > > Daniel F. Gutson > Chief Engineering Officer, SPD > > > San Lorenzo 47, 3rd Floor, Office 5 > > Córdoba, Argentina > > > Phone: +54 351 4217888 / +54 351 4218211 > > Skype: dgutson -- Daniel F. Gutson Chief Engineering Officer, SPD San Lorenzo 47, 3rd Floor, Office 5 Córdoba, Argentina Phone: +54 351 4217888 / +54 351 4218211 Skype: dgutson _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
