-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Similar project and might be some useful code #1
Comments
Thanks for bringing this up. I will try to utilize code/design from this, but there are a few differences:
With all this it is very interesting and similar but different design goals. Perhaps we can mutually benefit from certain similar functions. |
For me LVGL was really fast. It does need some tuning, giving proper buffer sizes, etc. But widgets quality and quality of fonts is awesome. I’d highly recommend LVGL over lower level libraries. It solves many problems which you otherwise have to solve somehow differently. Touchscreen or buttons doesn’t make much difference from coding perspective. It’s event driven. In my code UI, network, data parsing, and data storage are quite clearly separated. Boat data model is also separate code. So it’s easy to modify code and use it in some server type of application instead of UI. LVGL is also possible to use over frame buffer on Linux. So the app can be ported from esp32 to Linux. I have made a first release of BBN for CoreMP135 from m5stack. It runs pypilot and SignalK. And its plug and play device with NMEA 0183, 2000, pypilot IMU and motor controller are plug and play on it too. A bit slow on restarts. But its Debian. The code is here: https://github.com/bareboat-necessities/lysmarine_gen/tree/coremp135_bookworm About CoreMP135 https://docs.m5stack.com/en/core/M5CoreMP135 It’s $75. 2-can bus interface, i2c, uart, rs-485, 512MB ram, 2 usb 2.0, hdmi, arm based processor. Linux, small touchscreen. |
I think coremp135 can be a good platform for pypilot. I’ll post more thoughts here: |
I am supporting monochrome displays which lvgl is not really suitable. These displays have the lowest power consumption for daylight visible. To be clear, lvgl isnt too slow it is the esp32. I have a color display with resolution of 800x480. the esp32 literally isnt fast enough to push the framebuffer at anything more than 8bpp, because the LCD clock must be 25mhz. That is using the parallel interface and 8bpp, it just doesnt have the memory to store the framebuffer in normal ram, and the psram is too slow. Technically it can work at 16bpp with octal psram but it would have issues when doing other things. Using octal ram and 8bpp seems to be the best method for this screen. So my issue is using lvgl with low color. It can't be a palette because doing that in a hardware interrupt is also too slow. It has to be rgb232 with the last bit shared for red and blue to give 8 greys, 8 greens, 4 reds and 4 blues and so forth. https://forum.lvgl.io/t/v9-lv-color-depth-8-l8-support/14924 They are talking about maybe supporting 256 greys, but basically lvgl doesnt work for less than 16bpp right now, and even if they make it work, it wont support rgb232 +1 color format. That is the biggest issue there are others. As far as collaborating. We should keep checking each other's projects and understand the different intentions as the projects move along. If we could somehow share the ais code, or other bits that might be useful to avoid duplicated effort. It would be cool to somehow share data parsing for nmea, signalk, pypilot etc so that would be the starting point anyway. |
I have SignalK over TCP (instead of web sockets) parser, I also have Victron MQTT parser (partial) There is module for deriving data like wind, sunset/sunrise, going from magnetic to true based on wmm2020 for esp32. I think those can be of interest to you too. |
There is no good complete NMEA 0183 parser that I know of for esp32. and making good test cases. I think gpsd code has plenty and some other projects too. |
There is a lot of efforts done in another similar project https://github.com/norbert-walter/esp32-nmea2000-obp60/ I think we should try to make it modular. I think boat data can be made a shared library too. (storage of all boat sensors, etc) In my project I tried to define it in a single structure. Then all parsers could write into that. |
I propose making a separate GitHub project just for data model of ship data, with write access for me, you and someone from open boat projects. Start version can be this: It can be header .h only library. Then we kind of have shared data model. So all parsers would use it. and UI components could use it. It will improve code re-use between 3 projects. |
Here is one more project which https://github.com/philseeley/boatinstrument related issue: |
I've written some code to detect i2c devices. It checks their known addresses on i2c bus and also checks whoami registers response. So it can help you with making i2c devices plug and play |
I’ve done a similar project.
You might find some code useful and re-usable in yours. :)
UI is LVGL.
and various protocol parsers.
pypilot tcp, Victron MQTT, SignalK tcp,
NMEA 0183. MDNS discovery.
https://github.com/bareboat-necessities/bbn-m5stack-tough
Cheers
The text was updated successfully, but these errors were encountered: