dalsgaard/helms-display
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

SignalK now with thread, and updated REAME

Browse Source
This commit is contained in:
Jakob Dalsgaard
2020-06-07 06:53:24 +00:00
parent c111a52156
commit f1d62a5ff4
5 changed files with 522 additions and 17 deletions
Download Patch File Download Diff File Expand all files Collapse all files

5
README.md
View File

@@ -11,7 +11,7 @@ Helms Display
# Software considerations
* It seems like the ili9488 display is very hard to make work as a linux framebuffer device, at least when connected over SPI (this display has this weird feature that 3, 16 and 18 bit colordepth is supported, but only 3 and 18 over SPI -- and these 18 bit must be transferred at 3 bits in three independent bytes. It's very easy to just shove 24 bit pixel at the device and then not care that the lower 2 bits of every color is lost in translation - but it seems to be very hard to make the fbtft stack refrain from sending rgb565 16 bit pixels. After having googled to the very end of the internet trying to make fbtft work with the display, I ended up gathering a bunch of the byte init sequences into a python script and using python spidev I managed to display nice and neat figures on the screen just communicating directly with it.
* It seems like the ili9488 display is very hard to make work as a linux framebuffer device, at least when connected over SPI (this display has this weird feature that 3, 16 and 18 bit colordepth is supported, but only 3 and 18 over SPI -- and these 18 bit must be transferred at 6 bits in three independent bytes. It's very easy to just shove 24 bit pixel at the device and then not care that the lower 2 bits of every color is lost in translation - but it seems to be very hard to make the fbtft stack refrain from sending rgb565 16 bit pixels. After having googled to the very end of the internet trying to make fbtft work with the display, I ended up gathering a bunch of the byte init sequences into a python script and using python spidev I managed to display nice and neat figures on the screen just communicating directly with it.
* Performance and reliability; the python script was working fine, but also spending a fair amount of CPU cycles to just update this darn little display -- whilst easy to work with, something more powerful was surely needed. In comes Rust; primarily for one reason: it's the best.
* It's compiled, thus fast and efficient, and strongly typed; the compiler is very thorough and the LLVM backend is optimizing.
* It's secure, in that strict borrow and bounds checking make usual caveats a thing of the past
@@ -21,7 +21,8 @@ Helms Display
* boat.svg: just a simple boat shape :-)
* cog.svg: Course Over Ground - a blue line ending in the letters: COG -- will be rendered first, i.e. below all other items, and only if signalk has course over ground data
* wind.svg: Yellow inbound arrow -- will be rendered second -- and only if signalk has any wind data
* The text fields are rendered using rusttype and the DejaVu font: https://dejavu-fonts.github.io/ -- freely available truetype font
* The text fields are rendered using rusttype and the DejaVu font: https://dejavu-fonts.github.io/ -- freely available truetype font. There is great room for improvements in the rendering parts, such as the text justification code.
* Tungstenite-rs, https://github.com/snapview/tungstenite-rs, was chosen as the WebSocket crate -- it was chosen over websocket-rs, https://github.com/websockets-rs/rust-websocket, and doing my own implementation over TCPStream as it seems simple enough for my taste; I'm not really interested in making this application use Tokio or friends for being async, when I can just spin up a thread, the throughput of network messaging is considered minimal.