On Wed, 7 Sep 2022, Sergiu.Moga@xxxxxxxxxxxxx wrote: > On 07.09.2022 12:36, Ilpo Järvinen wrote: > > On Tue, 6 Sep 2022, Sergiu Moga wrote: > > > >> Previously, the atmel serial driver did not take into account the > >> possibility of using the more customizable generic clock as its > >> baudrate generator. Unless there is a Fractional Part available to > >> increase accuracy, there is a high chance that we may be able to > >> generate a baudrate closer to the desired one by using the GCLK as the > >> clock source. Now, depending on the error rate between > >> the desired baudrate and the actual baudrate, the serial driver will > >> fallback on the generic clock. The generic clock must be provided > >> in the DT node of the serial that may need a more flexible clock source. > >> > >> Signed-off-by: Sergiu Moga <sergiu.moga@xxxxxxxxxxxxx> > >> --- > > Is percent accurate enough or would you perhaps want something slightly > > more accurate? > > > > > It is accurate enough for the all the baudrates I have tested. It > usually taps into the GCLK whenever high baudrates such as 921600 are > used. For 115200 for example, the error rate was slightly better in the > case of the peripheral clock and it acted accordingly, choosing the > latter as its baudrate source clock. I do not think that a higher > accuracy than this would be needed though. Say that using percent > accuracy yields that the error rates are equal, but the gclk would have > been better in this case by, say, a few 10 ^ -4, but the code logic does > not see it so it proceeds using the peripheral clock. In that case, the > error rate of the peripheral clock would still be low enough relative to > the desired baudrate for the communication to function properly. > > The higher the baudrate, the lower the error rate must be in order for > things to go smoothly. For example, for a baudrate of 57600 I noticed > that even an error rate as big as 6% is still enough for the > communication to work properly, while in the case of 921600 anything > bigger than 2% and things do not go smoothly anymore. So I guess that it > would be safe to say that, unless you go for baudrates as high as tens > of millions, things should work well with just percent accuracy. A > higher accuracy always definetely helps, but I believe it is not needed > in this case. > > > > Given you've abs() at the caller side, the error rate could be > > underestimated, is underestimating OK? > > > > > Yes, this should be fine. While (both empirically and after looking > stuff up) I noticed that in the case of negative error rates, their > absolute value needs to be smaller than the one of positive error rates, > it must be so by a very small margin that is negligible when estimating > through percent accuracy. OK. Thanks for checking. -- i.
