Closed ajvdw closed 1 year ago
Can someone move this on from "pending" as it is a needed fix. I had the same problem on my project and luckily found this as the correct solution.
The reason for the "pending" state is that Arduino now has a policy that all contributors must sign our Contributor License Agreement (CLA).
@ajvdw can sign the CLA by clicking the "Contributor License Agreement" link in the comment by the @[]()CLAassistant bot above. That will trigger another validation operation by the bot and it should change the state from pending once that check is passing.
Arduino also has a policy that one of the developers must review and approve the proposal before it can be accepted. Since this pull request was opened years before the automated CLA checking system was put in place, the lack of a review and approval is the more fundamental reason why this is not merged. However, it is likely that the pull requests without a passing CLA check will not be given priority for review, since they couldn't be merged even with an approving review.
@ajvdw or any other interested parties could help out with that by providing more detailed information and definitive references (e.g., official datasheets).
Thousands of people have surely used this common library without having such a problem (myself included), otherwise we would have many bug reports about it here and on the forum. Yet I haven't seen them. So what are the specific conditions under which a pulse duration is required that is an order of magnitude longer than the minimum indicated in the comment?
It looks like there is an alternative proposal at https://github.com/arduino-libraries/LiquidCrystal/pull/14 and some related discussion at its original pull request thread.
Hi. I understand the reasons for a CLA but since I am not @ajvdw I wouldn't be able to advance this request. Thousands of people probably don't refresh their LCD display contents enough to see the problem. If you read the Arduino delaymicroseconds() documentation it specifically states "We cannot assure that delayMicroseconds will perform precisely for smaller delay-times", i.e. using delaymicroseconds(1) is not guaranteed to wait for 1 microsecond; it could in fact return instantly. If the latter occurs the LCD communications protocol would then be out of spec - which is why the LCD get completely garbled. This solution solves the issue without causing any side effects as it even retains the same execution duration. (actually in theory it will have a more reliable execution duration since delaymicroseconds() will be operating within its specified parameters). A belated thank you to @ajvdw whereever you are for nailing this one :o)
Memory usage change @ ec31f829207213d17fd0c9b573c5b0a509d28b8f
Board | flash | % | RAM for global variables | % |
---|---|---|---|---|
arduino:avr:leonardo | :small_red_triangle: +28 - +28 | +0.1 - +0.1 | 0 - 0 | 0.0 - 0.0 |
arduino:avr:mega | :small_red_triangle: +28 - +28 | +0.01 - +0.01 | 0 - 0 | 0.0 - 0.0 |
arduino:avr:nano | :small_red_triangle: +28 - +28 | +0.09 - +0.09 | 0 - 0 | 0.0 - 0.0 |
arduino:mbed_nano:nano33ble | 0 - 0 | 0.0 - 0.0 | 0 - 0 | 0.0 - 0.0 |
arduino:mbed_nano:nanorp2040connect | 0 - 0 | 0.0 - 0.0 | 0 - 0 | 0.0 - 0.0 |
arduino:mbed_portenta:envie_m4 | 0 - 0 | 0.0 - 0.0 | 0 - 0 | 0.0 - 0.0 |
arduino:mbed_portenta:envie_m7 | 0 - 0 | 0.0 - 0.0 | 0 - 0 | 0.0 - 0.0 |
arduino:megaavr:nona4809 | :small_red_triangle: +28 - +28 | +0.06 - +0.06 | 0 - 0 | 0.0 - 0.0 |
arduino:sam:arduino_due_x_dbg | 0 - 0 | 0.0 - 0.0 | N/A | N/A |
arduino:samd:mkrzero | 0 - 0 | 0.0 - 0.0 | 0 - 0 | 0.0 - 0.0 |
// Due to inaccurate timing, skipping pulses. Results scrambled screen // (http://arduino.cc/en/Reference/delayMicroseconds)