On Tuesday, October 13, 2020 at 8:43:55 AM UTC-4, Richard Damon wrote:> On 10/12/20 10:14 PM, Rick C wrote: > > On Monday, October 12, 2020 at 6:26:51 PM UTC-4, Clifford Heath wrote: > >> On 13/10/20 3:08 am, Rick C wrote: > >>> On Monday, October 12, 2020 at 6:36:35 AM UTC-4, Jim Jackson wrote: > >>>> I've held off from following up, because I'm no expert, but I was hoping > >>>> to learn some stuff. I have written LCD drivers - but just for myself. > >>>> When controlling an LCD directly connected to the SBC, I've used > >>>> checking the operation ocmpleted flag. But when using an I2C connected > >>>> LCD I just used, conservative, timing. Not an option for you. > >>> > >>> Not sure why you say this is not an option for me. That's exactly what I plan to do, use "conservative" timing. > >> > >> It's been over a decade since I wrote a driver for this family of chips > >> and my recollection has faded, but at the time, there were complaints in > >> the forums that the busy flag was unreliable for detecting completion of > >> some operations, and that the actual required time seemed to vary. Also > >> there are various clones of the chip that have different behaviour so > >> unless you know what you've got, you have to just use conservative > >> timing. It was the only real option, and is the one I used. > > > > That's interesting. This is the first I've heard that the busy flag isn't reliable. > > > > I've been pushing numbers around and given the amount of data I need to shove across the interface on every refresh I can't update as fast as I'd like using the Reset command without a significant portion of the time being blank for the last characters in the display. So I'll leave some flexibility and try omitting the Reset. Then it's just writing one char over another and after that it's just writing the same char over the old same char so no dimming, no worry of flicker. > > > > We'll see what I think of it in the morning. Just watched the first half of Monday night football and I want to see if the Saints can win. > > > > First, it is NOT expected that this sort of chip gets 'Reset' for every > update, that is a good way to induce flicker. I would just do the Reset > sequence at first turn on, and maybe at occasional operational points > where you are naturally blanking and redrawing the full screen (so the > blanking isn't noticeable), and at other times just be doing the minimum > to update the screen contents.There will only be flicker if the blanked time is significant in relation to the unblanked time AND the rate of blinking is slow enough. Because the update rate is pretty fast, ~100 Hz, my real concern is dimming of the last written characters, not dimming. I don't wish to add complexity to the design. The only "operational points" are updates. The character data will be pulled from a RAM on each refresh. I have not decided if the commands will also be in the RAM or if they will be hardwired in the FPGA. If in the RAM changing the configuration sequence would require a slow rate timer (long length) to trigger a write to change the sequence and then back after a refresh (lots of messy logic). If the commands are in logic then the same timer can add the command in the logic with less messy logic, but still more than desired. I prefer not to do this if not needed. I'm thinking the reset is not needed if the set address command is used and all the characters are sent each time. Oh, and we are not using the cursor. It would be nice if a good data sheet where available that didn't leave so many half answered questions. -- Rick C. --- Get 1,000 miles of free Supercharging --- Tesla referral code - https://ts.la/richard11209
HD44780 / ST7066U Initialization
Started by ●October 9, 2020
Reply by ●October 13, 20202020-10-13
Reply by ●October 13, 20202020-10-13
On 10/13/20 10:42 AM, Rick C wrote:> On Tuesday, October 13, 2020 at 8:43:55 AM UTC-4, Richard Damon wrote: >> On 10/12/20 10:14 PM, Rick C wrote: >>> On Monday, October 12, 2020 at 6:26:51 PM UTC-4, Clifford Heath wrote: >>>> On 13/10/20 3:08 am, Rick C wrote: >>>>> On Monday, October 12, 2020 at 6:36:35 AM UTC-4, Jim Jackson wrote: >>>>>> I've held off from following up, because I'm no expert, but I was hoping >>>>>> to learn some stuff. I have written LCD drivers - but just for myself. >>>>>> When controlling an LCD directly connected to the SBC, I've used >>>>>> checking the operation ocmpleted flag. But when using an I2C connected >>>>>> LCD I just used, conservative, timing. Not an option for you. >>>>> >>>>> Not sure why you say this is not an option for me. That's exactly what I plan to do, use "conservative" timing. >>>> >>>> It's been over a decade since I wrote a driver for this family of chips >>>> and my recollection has faded, but at the time, there were complaints in >>>> the forums that the busy flag was unreliable for detecting completion of >>>> some operations, and that the actual required time seemed to vary. Also >>>> there are various clones of the chip that have different behaviour so >>>> unless you know what you've got, you have to just use conservative >>>> timing. It was the only real option, and is the one I used. >>> >>> That's interesting. This is the first I've heard that the busy flag isn't reliable. >>> >>> I've been pushing numbers around and given the amount of data I need to shove across the interface on every refresh I can't update as fast as I'd like using the Reset command without a significant portion of the time being blank for the last characters in the display. So I'll leave some flexibility and try omitting the Reset. Then it's just writing one char over another and after that it's just writing the same char over the old same char so no dimming, no worry of flicker. >>> >>> We'll see what I think of it in the morning. Just watched the first half of Monday night football and I want to see if the Saints can win. >>> >> >> First, it is NOT expected that this sort of chip gets 'Reset' for every >> update, that is a good way to induce flicker. I would just do the Reset >> sequence at first turn on, and maybe at occasional operational points >> where you are naturally blanking and redrawing the full screen (so the >> blanking isn't noticeable), and at other times just be doing the minimum >> to update the screen contents. > much you > There will only be flicker if the blanked time is significant in relation to the unblanked time AND the rate of blinking is slow enough. Because the update rate is pretty fast, ~100 Hz, my real concern is dimming of the last written characters, not dimming. > > I don't wish to add complexity to the design. The only "operational points" are updates. The character data will be pulled from a RAM on each refresh. I have not decided if the commands will also be in the RAM or if they will be hardwired in the FPGA. If in the RAM changing the configuration sequence would require a slow rate timer (long length) to trigger a write to change the sequence and then back after a refresh (lots of messy logic). If the commands are in logic then the same timer can add the command in the logic with less messy logic, but still more than desired. I prefer not to do this if not needed. > > I'm thinking the reset is not needed if the set address command is used and all the characters are sent each time. Oh, and we are not using the cursor. > > It would be nice if a good data sheet where available that didn't leave so many half answered questions. >The problem is that if you send a 'Reset' command, at a minimum you interrupt the scan sequence, so regularly doing this will at a minimum say that later parts of the scan will appear less than earlier parts. It also tends to mean you need to resend more initialization data to the chip, much you want to send before turning the display back on, so the display is refreshed less, and maybe even will be perceptibly flashing. (At 100 Hz, most people probably won't perceive flashing, but a small minority may sense a 'something') Much better is to just set the display ram address to the beginning of memory and streaming the array of data for the update, and not do a full reset for the update.
Reply by ●October 14, 20202020-10-14
On Tuesday, October 13, 2020 at 1:34:37 PM UTC-4, Richard Damon wrote:> On 10/13/20 10:42 AM, Rick C wrote: > > On Tuesday, October 13, 2020 at 8:43:55 AM UTC-4, Richard Damon wrote: > >> On 10/12/20 10:14 PM, Rick C wrote: > >>> On Monday, October 12, 2020 at 6:26:51 PM UTC-4, Clifford Heath wrote: > >>>> On 13/10/20 3:08 am, Rick C wrote: > >>>>> On Monday, October 12, 2020 at 6:36:35 AM UTC-4, Jim Jackson wrote: > >>>>>> I've held off from following up, because I'm no expert, but I was hoping > >>>>>> to learn some stuff. I have written LCD drivers - but just for myself. > >>>>>> When controlling an LCD directly connected to the SBC, I've used > >>>>>> checking the operation ocmpleted flag. But when using an I2C connected > >>>>>> LCD I just used, conservative, timing. Not an option for you. > >>>>> > >>>>> Not sure why you say this is not an option for me. That's exactly what I plan to do, use "conservative" timing. > >>>> > >>>> It's been over a decade since I wrote a driver for this family of chips > >>>> and my recollection has faded, but at the time, there were complaints in > >>>> the forums that the busy flag was unreliable for detecting completion of > >>>> some operations, and that the actual required time seemed to vary. Also > >>>> there are various clones of the chip that have different behaviour so > >>>> unless you know what you've got, you have to just use conservative > >>>> timing. It was the only real option, and is the one I used. > >>> > >>> That's interesting. This is the first I've heard that the busy flag isn't reliable. > >>> > >>> I've been pushing numbers around and given the amount of data I need to shove across the interface on every refresh I can't update as fast as I'd like using the Reset command without a significant portion of the time being blank for the last characters in the display. So I'll leave some flexibility and try omitting the Reset. Then it's just writing one char over another and after that it's just writing the same char over the old same char so no dimming, no worry of flicker. > >>> > >>> We'll see what I think of it in the morning. Just watched the first half of Monday night football and I want to see if the Saints can win. > >>> > >> > >> First, it is NOT expected that this sort of chip gets 'Reset' for every > >> update, that is a good way to induce flicker. I would just do the Reset > >> sequence at first turn on, and maybe at occasional operational points > >> where you are naturally blanking and redrawing the full screen (so the > >> blanking isn't noticeable), and at other times just be doing the minimum > >> to update the screen contents. > > much you > > There will only be flicker if the blanked time is significant in relation to the unblanked time AND the rate of blinking is slow enough. Because the update rate is pretty fast, ~100 Hz, my real concern is dimming of the last written characters, not dimming. > > > > I don't wish to add complexity to the design. The only "operational points" are updates. The character data will be pulled from a RAM on each refresh. I have not decided if the commands will also be in the RAM or if they will be hardwired in the FPGA. If in the RAM changing the configuration sequence would require a slow rate timer (long length) to trigger a write to change the sequence and then back after a refresh (lots of messy logic). If the commands are in logic then the same timer can add the command in the logic with less messy logic, but still more than desired. I prefer not to do this if not needed. > > > > I'm thinking the reset is not needed if the set address command is used and all the characters are sent each time. Oh, and we are not using the cursor. > > > > It would be nice if a good data sheet where available that didn't leave so many half answered questions. > > > > The problem is that if you send a 'Reset' command, at a minimum you > interrupt the scan sequence, so regularly doing this will at a minimum > say that later parts of the scan will appear less than earlier parts. It > also tends to mean you need to resend more initialization data to the > chip, much you want to send before turning the display back on, so the > display is refreshed less, and maybe even will be perceptibly flashing. > (At 100 Hz, most people probably won't perceive flashing, but a small > minority may sense a 'something') > > Much better is to just set the display ram address to the beginning of > memory and streaming the array of data for the update, and not do a full > reset for the update.Will omitting the reset command cause any issues? The data sheets are crappy enough that I can't say there is nothing that the reset does that I can't duplicate with other commands. But that's what I'm going to try. The command stream will be from logic and the character data will be from RAM. The character data is updated on a regular basis with simple computation of addresses. I may provide several areas of RAM for the different display modes and fill in all of them, then let the display circuit select the right one for display depending on the mode. Some modes have fixed text and others lots of variables. One block RAM should cover them all. We have two display features that are thermometer displays. Rather than define multiple characters and select the appropriate character in the display RAM, I'm going to pick one CGRAM character each and change the character on the fly. That will only be 16 bytes rather than the full 64 bytes of CGRAM reducing the update time a lot. Not sure about the start of your post. Are you saying the "scanning" of the DDRAM to generate the LCD driver data will be reset by the "Clear display" command? That's the sort of undocumented feature I'm worried about. Have you seen this behavior? -- Rick C. --+ Get 1,000 miles of free Supercharging --+ Tesla referral code - https://ts.la/richard11209
Reply by ●October 14, 20202020-10-14
On 10/14/20 1:07 AM, Rick C wrote:> On Tuesday, October 13, 2020 at 1:34:37 PM UTC-4, Richard Damon wrote: >> On 10/13/20 10:42 AM, Rick C wrote: >>> On Tuesday, October 13, 2020 at 8:43:55 AM UTC-4, Richard Damon wrote: >>>> On 10/12/20 10:14 PM, Rick C wrote: >>>>> On Monday, October 12, 2020 at 6:26:51 PM UTC-4, Clifford Heath wrote: >>>>>> On 13/10/20 3:08 am, Rick C wrote: >>>>>>> On Monday, October 12, 2020 at 6:36:35 AM UTC-4, Jim Jackson wrote: >>>>>>>> I've held off from following up, because I'm no expert, but I was hoping >>>>>>>> to learn some stuff. I have written LCD drivers - but just for myself. >>>>>>>> When controlling an LCD directly connected to the SBC, I've used >>>>>>>> checking the operation ocmpleted flag. But when using an I2C connected >>>>>>>> LCD I just used, conservative, timing. Not an option for you. >>>>>>> >>>>>>> Not sure why you say this is not an option for me. That's exactly what I plan to do, use "conservative" timing. >>>>>> >>>>>> It's been over a decade since I wrote a driver for this family of chips >>>>>> and my recollection has faded, but at the time, there were complaints in >>>>>> the forums that the busy flag was unreliable for detecting completion of >>>>>> some operations, and that the actual required time seemed to vary. Also >>>>>> there are various clones of the chip that have different behaviour so >>>>>> unless you know what you've got, you have to just use conservative >>>>>> timing. It was the only real option, and is the one I used. >>>>> >>>>> That's interesting. This is the first I've heard that the busy flag isn't reliable. >>>>> >>>>> I've been pushing numbers around and given the amount of data I need to shove across the interface on every refresh I can't update as fast as I'd like using the Reset command without a significant portion of the time being blank for the last characters in the display. So I'll leave some flexibility and try omitting the Reset. Then it's just writing one char over another and after that it's just writing the same char over the old same char so no dimming, no worry of flicker. >>>>> >>>>> We'll see what I think of it in the morning. Just watched the first half of Monday night football and I want to see if the Saints can win. >>>>> >>>> >>>> First, it is NOT expected that this sort of chip gets 'Reset' for every >>>> update, that is a good way to induce flicker. I would just do the Reset >>>> sequence at first turn on, and maybe at occasional operational points >>>> where you are naturally blanking and redrawing the full screen (so the >>>> blanking isn't noticeable), and at other times just be doing the minimum >>>> to update the screen contents. >>> much you >>> There will only be flicker if the blanked time is significant in relation to the unblanked time AND the rate of blinking is slow enough. Because the update rate is pretty fast, ~100 Hz, my real concern is dimming of the last written characters, not dimming. >>> >>> I don't wish to add complexity to the design. The only "operational points" are updates. The character data will be pulled from a RAM on each refresh. I have not decided if the commands will also be in the RAM or if they will be hardwired in the FPGA. If in the RAM changing the configuration sequence would require a slow rate timer (long length) to trigger a write to change the sequence and then back after a refresh (lots of messy logic). If the commands are in logic then the same timer can add the command in the logic with less messy logic, but still more than desired. I prefer not to do this if not needed. >>> >>> I'm thinking the reset is not needed if the set address command is used and all the characters are sent each time. Oh, and we are not using the cursor. >>> >>> It would be nice if a good data sheet where available that didn't leave so many half answered questions. >>> >> >> The problem is that if you send a 'Reset' command, at a minimum you >> interrupt the scan sequence, so regularly doing this will at a minimum >> say that later parts of the scan will appear less than earlier parts. It >> also tends to mean you need to resend more initialization data to the >> chip, much you want to send before turning the display back on, so the >> display is refreshed less, and maybe even will be perceptibly flashing. >> (At 100 Hz, most people probably won't perceive flashing, but a small >> minority may sense a 'something') >> >> Much better is to just set the display ram address to the beginning of >> memory and streaming the array of data for the update, and not do a full >> reset for the update. > > Will omitting the reset command cause any issues? The data sheets are crappy enough that I can't say there is nothing that the reset does that I can't duplicate with other commands. > > But that's what I'm going to try. The command stream will be from logic and the character data will be from RAM. The character data is updated on a regular basis with simple computation of addresses. I may provide several areas of RAM for the different display modes and fill in all of them, then let the display circuit select the right one for display depending on the mode. Some modes have fixed text and others lots of variables. One block RAM should cover them all. > > We have two display features that are thermometer displays. Rather than define multiple characters and select the appropriate character in the display RAM, I'm going to pick one CGRAM character each and change the character on the fly. That will only be 16 bytes rather than the full 64 bytes of CGRAM reducing the update time a lot. > > Not sure about the start of your post. Are you saying the "scanning" of the DDRAM to generate the LCD driver data will be reset by the "Clear display" command? That's the sort of undocumented feature I'm worried about. Have you seen this behavior? >I don't know that particular chip well enough to know if it has some internal state that really needs a reset. Most chips needs some form of reset to initialize, but often then can get that by internally generating a Power On Reset. It might be good enough to just have a capacitor on the Reset line to force a Reset at power on. That does say you will need to wait a certain period of time after power on, (so the chip comes out of reset) and then send the initial config sequence. What I was talking about is the way the controller actually works, it doesn't control all the bits of the display at once, as that would take a LOT of connections, but these sorts of chips divide the display into rows and columns (that might not match the physical display, the HD44780 has 40 columns of up to 16 rows) and at any given instant in time are driving one column of pixels, and cycle through the columns at a fast rate, so it appears always on. Cheaper devices tend to go slower, as it is it is a bit easier to do. If you even had a device that the display seemed to flicker likely was scanning just a bit too slow. The problem with doing a reset (or even a periodic blank/update/unblank pattern) is that if you stop this scanning in the middle, the last columns will have one less update than the first, and appear dimmer. This will be a lot more noticeable if you do this at a small multiple of the scan time (as 3/4 is a lot smaller than 999/1000, and 0/1 is REALLY noticeable). Reading the data sheet, the scan time from the device is a function of its configuration, but it looks like in all cases it is over 10 ms, so doing a reset pattern at 100 Hz (10 ms) would be bad, and some of the display never shown. In fact, even updating the display at 100 Hz has some potential problems as 'fast' motion might become jerky.
Reply by ●October 14, 20202020-10-14
On Wednesday, October 14, 2020 at 8:51:33 AM UTC-4, Richard Damon wrote:> On 10/14/20 1:07 AM, Rick C wrote: > > On Tuesday, October 13, 2020 at 1:34:37 PM UTC-4, Richard Damon wrote: > >> On 10/13/20 10:42 AM, Rick C wrote: > >>> On Tuesday, October 13, 2020 at 8:43:55 AM UTC-4, Richard Damon wrote: > >>>> On 10/12/20 10:14 PM, Rick C wrote: > >>>>> On Monday, October 12, 2020 at 6:26:51 PM UTC-4, Clifford Heath wrote: > >>>>>> On 13/10/20 3:08 am, Rick C wrote: > >>>>>>> On Monday, October 12, 2020 at 6:36:35 AM UTC-4, Jim Jackson wrote: > >>>>>>>> I've held off from following up, because I'm no expert, but I was hoping > >>>>>>>> to learn some stuff. I have written LCD drivers - but just for myself. > >>>>>>>> When controlling an LCD directly connected to the SBC, I've used > >>>>>>>> checking the operation ocmpleted flag. But when using an I2C connected > >>>>>>>> LCD I just used, conservative, timing. Not an option for you. > >>>>>>> > >>>>>>> Not sure why you say this is not an option for me. That's exactly what I plan to do, use "conservative" timing. > >>>>>> > >>>>>> It's been over a decade since I wrote a driver for this family of chips > >>>>>> and my recollection has faded, but at the time, there were complaints in > >>>>>> the forums that the busy flag was unreliable for detecting completion of > >>>>>> some operations, and that the actual required time seemed to vary. Also > >>>>>> there are various clones of the chip that have different behaviour so > >>>>>> unless you know what you've got, you have to just use conservative > >>>>>> timing. It was the only real option, and is the one I used. > >>>>> > >>>>> That's interesting. This is the first I've heard that the busy flag isn't reliable. > >>>>> > >>>>> I've been pushing numbers around and given the amount of data I need to shove across the interface on every refresh I can't update as fast as I'd like using the Reset command without a significant portion of the time being blank for the last characters in the display. So I'll leave some flexibility and try omitting the Reset. Then it's just writing one char over another and after that it's just writing the same char over the old same char so no dimming, no worry of flicker. > >>>>> > >>>>> We'll see what I think of it in the morning. Just watched the first half of Monday night football and I want to see if the Saints can win. > >>>>> > >>>> > >>>> First, it is NOT expected that this sort of chip gets 'Reset' for every > >>>> update, that is a good way to induce flicker. I would just do the Reset > >>>> sequence at first turn on, and maybe at occasional operational points > >>>> where you are naturally blanking and redrawing the full screen (so the > >>>> blanking isn't noticeable), and at other times just be doing the minimum > >>>> to update the screen contents. > >>> much you > >>> There will only be flicker if the blanked time is significant in relation to the unblanked time AND the rate of blinking is slow enough. Because the update rate is pretty fast, ~100 Hz, my real concern is dimming of the last written characters, not dimming. > >>> > >>> I don't wish to add complexity to the design. The only "operational points" are updates. The character data will be pulled from a RAM on each refresh. I have not decided if the commands will also be in the RAM or if they will be hardwired in the FPGA. If in the RAM changing the configuration sequence would require a slow rate timer (long length) to trigger a write to change the sequence and then back after a refresh (lots of messy logic). If the commands are in logic then the same timer can add the command in the logic with less messy logic, but still more than desired. I prefer not to do this if not needed. > >>> > >>> I'm thinking the reset is not needed if the set address command is used and all the characters are sent each time. Oh, and we are not using the cursor. > >>> > >>> It would be nice if a good data sheet where available that didn't leave so many half answered questions. > >>> > >> > >> The problem is that if you send a 'Reset' command, at a minimum you > >> interrupt the scan sequence, so regularly doing this will at a minimum > >> say that later parts of the scan will appear less than earlier parts. It > >> also tends to mean you need to resend more initialization data to the > >> chip, much you want to send before turning the display back on, so the > >> display is refreshed less, and maybe even will be perceptibly flashing. > >> (At 100 Hz, most people probably won't perceive flashing, but a small > >> minority may sense a 'something') > >> > >> Much better is to just set the display ram address to the beginning of > >> memory and streaming the array of data for the update, and not do a full > >> reset for the update. > > > > Will omitting the reset command cause any issues? The data sheets are crappy enough that I can't say there is nothing that the reset does that I can't duplicate with other commands. > > > > But that's what I'm going to try. The command stream will be from logic and the character data will be from RAM. The character data is updated on a regular basis with simple computation of addresses. I may provide several areas of RAM for the different display modes and fill in all of them, then let the display circuit select the right one for display depending on the mode. Some modes have fixed text and others lots of variables. One block RAM should cover them all. > > > > We have two display features that are thermometer displays. Rather than define multiple characters and select the appropriate character in the display RAM, I'm going to pick one CGRAM character each and change the character on the fly. That will only be 16 bytes rather than the full 64 bytes of CGRAM reducing the update time a lot. > > > > Not sure about the start of your post. Are you saying the "scanning" of the DDRAM to generate the LCD driver data will be reset by the "Clear display" command? That's the sort of undocumented feature I'm worried about. Have you seen this behavior? > > > > I don't know that particular chip well enough to know if it has some > internal state that really needs a reset. Most chips needs some form of > reset to initialize, but often then can get that by internally > generating a Power On Reset. It might be good enough to just have a > capacitor on the Reset line to force a Reset at power on. That does say > you will need to wait a certain period of time after power on, (so the > chip comes out of reset) and then send the initial config sequence. > > What I was talking about is the way the controller actually works, it > doesn't control all the bits of the display at once, as that would take > a LOT of connections, but these sorts of chips divide the display into > rows and columns (that might not match the physical display, the HD44780 > has 40 columns of up to 16 rows) and at any given instant in time are > driving one column of pixels, and cycle through the columns at a fast > rate, so it appears always on. Cheaper devices tend to go slower, as it > is it is a bit easier to do. If you even had a device that the display > seemed to flicker likely was scanning just a bit too slow. The problem > with doing a reset (or even a periodic blank/update/unblank pattern) is > that if you stop this scanning in the middle, the last columns will have > one less update than the first, and appear dimmer. This will be a lot > more noticeable if you do this at a small multiple of the scan time (as > 3/4 is a lot smaller than 999/1000, and 0/1 is REALLY noticeable).Yes, I know what you are talking about. I think you are assuming the "Clear display" command is an actual global reset of some sort which I'm pretty sure it is not. The commands on this device take a minimum of 10 clock cycles to execute. The Clear display and Return home commands take 1.52 ms or 182 clock cycles. That says to me it is a state machine executing something like a script rather than anything like a reset. So it is unlikely the display timing would be interrupted.> Reading the data sheet, the scan time from the device is a function of > its configuration, but it looks like in all cases it is over 10 ms, so > doing a reset pattern at 100 Hz (10 ms) would be bad, and some of the > display never shown. In fact, even updating the display at 100 Hz has > some potential problems as 'fast' motion might become jerky.All based on the assumption the display timing is impacted in any way by the Clear Display command. I don't have a unit I can test, but I'll ask one of the software guys if they can check this out for me. -- Rick C. -+- Get 1,000 miles of free Supercharging -+- Tesla referral code - https://ts.la/richard11209
