github.com/mpictor/cfa
Package cfa implements communication with Crystalfontz LCDs such as CFA-631 and CFA-635, without use of CGO. In addition, this package supports keypress events and menus. The following can be found beginning on Pg 34, CFA631_Data_Sheet_Release_2014-11-17.pdf. All packets have the following structure: type is one byte, and identifies the type and function of the packet: data_length specifies the number of bytes that will follow in the data field. The valid range of data_length is 0 to 22. data is the payload of the packet. Each type of packet will have a specified data_length and format for data as well as algorithms for decoding data detailed below. CRC is a standard 16-bit CRC of all the bytes in the packet except the CRC itself. The CRC is sent LSB first. At the port, the CRC immediately follows the last used element of data []. See Sample Algorithms To Calculate The CRC (Pg. 66) for details. The following C definition may be useful for understanding the packet structure. While the documentation can be interpreted as saying the packet size is fixed, it is not; there is never padding between the last valid data byte and the crc, and the packet length is always data_length+4. Crystalfontz claims above that the CRC used is standard, but a bit of googling leads me to the conclusion that there is no such thing. There are myriad variations of 16-bit CRC with different constants, and the sites discussing it tend to disagree on which constants are used by which protocols. Very few standards actually include any test vectors. Crystalfontz' own data sheets for the 631 and 635 include a test vector in one example... but the output listed does not match the value computed by the "crystalfontz linux example", which is able to talk to the LCD. The CFA-631 and XES-635BK-TML-KU work fine, but the XES-635BK-TMF-KU can hang or otherwise lose packets. By far the most effective workaround seems to be to minimize the number of packets sent. Of course, that's not possible beyond a certain point without throwing usability out the window. We have shipped some XES-635BK-TFE-KU. The only difference from the TMF should be the display/backlight color, so those are likely to have the same issues as TMF. Key event reports (and responses to the key poll command) are written to an event channel for async read. Only key releases are considered. Reading key press events or keys being held down (only seen when polling) would not be difficult, but handling them with the menu would complicate things.
Readme
Known to work with CFA631 and CFA635 LCDs; likely to work with others since the command sets have a lot in common. Your kernel will need the appropriate driver(s) - CDC ACM for newer LCDs, usb-serial for older.
Some tests are occasionally flaky, and the test code is rather ugly. I wasn't sure how to fix the ugliness short of removing tests, which doesn't strike me as the best of options.
This is the cfa package that's part of https://github.com/purecloudlabs/gprovision, specifically https://github.com/purecloudlabs/gprovision/tree/master/gopath/src/gprovision/pkg/hw/cfa .
I am duplicating it here to re-write import paths so it's easier to use standalone. Other than the paths, I intend to keep it in sync with upstream - if it diverges, let me know!
FAQs
Package cfa implements communication with Crystalfontz LCDs such as CFA-631 and CFA-635, without use of CGO. In addition, this package supports keypress events and menus. The following can be found beginning on Pg 34, CFA631_Data_Sheet_Release_2014-11-17.pdf. All packets have the following structure: type is one byte, and identifies the type and function of the packet: data_length specifies the number of bytes that will follow in the data field. The valid range of data_length is 0 to 22. data is the payload of the packet. Each type of packet will have a specified data_length and format for data as well as algorithms for decoding data detailed below. CRC is a standard 16-bit CRC of all the bytes in the packet except the CRC itself. The CRC is sent LSB first. At the port, the CRC immediately follows the last used element of data []. See Sample Algorithms To Calculate The CRC (Pg. 66) for details. The following C definition may be useful for understanding the packet structure. While the documentation can be interpreted as saying the packet size is fixed, it is not; there is never padding between the last valid data byte and the crc, and the packet length is always data_length+4. Crystalfontz claims above that the CRC used is standard, but a bit of googling leads me to the conclusion that there is no such thing. There are myriad variations of 16-bit CRC with different constants, and the sites discussing it tend to disagree on which constants are used by which protocols. Very few standards actually include any test vectors. Crystalfontz' own data sheets for the 631 and 635 include a test vector in one example... but the output listed does not match the value computed by the "crystalfontz linux example", which is able to talk to the LCD. The CFA-631 and XES-635BK-TML-KU work fine, but the XES-635BK-TMF-KU can hang or otherwise lose packets. By far the most effective workaround seems to be to minimize the number of packets sent. Of course, that's not possible beyond a certain point without throwing usability out the window. We have shipped some XES-635BK-TFE-KU. The only difference from the TMF should be the display/backlight color, so those are likely to have the same issues as TMF. Key event reports (and responses to the key poll command) are written to an event channel for async read. Only key releases are considered. Reading key press events or keys being held down (only seen when polling) would not be difficult, but handling them with the menu would complicate things.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
Researchers recently demonstrated that the npm Registry is vulnerable to cache poisoning combined with DoS, posing significant risks for package availability.
Security News
The June TC39 meeting wrapped up this week with eight proposals moving on to the next stage. Here's a quick roundup of the features that the committee approved to advance.
Security News
Cyber extortion in the US and Canada hit record levels in 2023, with ransomware attacks surging and median ransom demands skyrocketing, though fewer companies are choosing to pay ransoms.
