You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@WasabiFan I am going to experiment with David’s Micropython Display code. Maybe this will be like the buttons where we can add this without a ton of effort :)
The major issue I see here is that most of our current display API is really just exposing the PILlow drawing object. I think we do still have wrapper methods around it though, so maybe we can fill in some holes there and then have the PIL object only available on CPython.
Okay. Just in case anyone is watching this space... You can display and position text on the LCD screen using escape code sequences supported by the EV3DEV console driver (appears to support the VT100 sequences). Here are some code snippets that'll get you started:
def set_cursor(on=False):
# use escape code to turn cursor on or off
if on:
print("\x1b[?25h", end='')
else:
print("\x1b[?25l", end='')
def clear_screen():
print("\x1b[2J\x1b[H", end='')
set_cursor(False)
def text_at(row, col, text='', reverse=False):
if reverse:
text = "\x1b[7m%s\x1b[m" % (text)
print("\x1b[%d;%dH%s" % (row, col, text), end='')
def enable_big_text(font="Lat15-TerminusBold24x12"):
"""
Set the LCD console font larger so we can SEE IT!
`font` the name of the font to use
"""
# Font choices:
# Lat15-Terminus12x6 Lat15-Terminus14 Lat15-Terminus16 Lat15-Terminus20x10 Lat15-Terminus22x11 Lat15-Terminus24x12 Lat15-Terminus28x14 Lat15-Terminus32x16
# Lat15-TerminusBold12x6 Lat15-TerminusBold14 Lat15-TerminusBold16 Lat15-TerminusBold20x10 Lat15-TerminusBold22x11 Lat15-TerminusBold24x12 Lat15-TerminusBold28x14 Lat15-TerminusBold32x16
# Lat15-Courier13 Lat15-Courier14 Lat15-Courier15 Lat15-Courier16
# Lat15-CourierBold13 Lat15-CourierBold14 Lat15-CourierBold15
# Lat15-Fixed13 Lat15-Fixed14 Lat15-Fixed15 Lat15-Fixed16 Lat15-Fixed18 Lat15-Fixed24x12
# Lat15-FixedBold13 Lat15-FixedBold14 Lat15-FixedBold15 Lat15-FixedBold16 Lat15-FixedBold18 Lat15-FixedBold24x12
# Lat15-Lucid12 Lat15-Lucid13 Lat15-Lucid15 Lat15-Lucid16 Lat15-Lucid22x12 Lat15-Lucid29x16
# Lat15-LucidBold11 Lat15-LucidBold13 Lat15-LucidBold15 Lat15-LucidBold16 Lat15-LucidBold22x12 Lat15-LucidBold29x16
os.system("setfont %s" % (font))
clear_screen()
@bpmerkel that is awesome, nice work!! :) Would you be interested in taking on this ticket? Basically just take what you have above and stick it in a Display class that is only used when is_micropython() is True, else use the Display class that we have today.
Looking at the Display() class, it's pretty embedded with the FrameBuffer-based logic (it subclasses FbMem). Instead of spaghetti if is_micopython() paths, what do you think about creating a new Console() class within display.py, that simply offers the VT helper functions for the LCD panel console/tty (and would work in both python3 and micropython)?
We've tried to keep the API the same for the python vs micropython equivalents of the same class so even though it is a little if/else spaghettish it does make it easier to take a program and jump back and forth between python/micropython. For the micropython implementation of Display text_grid() would be the only method you would really implement, for all of the others I would just have the log a "not supported in micropython" message.
I think it makes sense to have a distinct text and graphics modes for the display. Startup time of programs could be greatly improved if they don't want to use graphics mode and just display text.
I agree with David here — I think the text mode functionality would be best suited for its own class and API. It's useful, but it isn't a replacement for true drawing and isn't used in the same way.
Okay. Plan B. I submitted a PR for Display() with is_micropython and layered the ANSI code logic into the Display() API as best it could (minus the Image and text_pixels functionality). Let me make another fork and build a Console() class (for both Python and micropython). I'll submit a second PR and let the keepers review for applicability. :-)
@WasabiFan any objections to closing this now that we have the Console class? Pulling off Display in micropython doesn’t feel like it would add enough given the amount of work it would take.
I think we should leave it open even though it's deprioritized. This is always available if someone wants to take it on and is useful to reference what is/isn't implemented.
Activity
dwalton76 commentedon May 25, 2019
@WasabiFan I am going to experiment with David’s Micropython Display code. Maybe this will be like the buttons where we can add this without a ton of effort :)
WasabiFan commentedon May 25, 2019
The major issue I see here is that most of our current display API is really just exposing the PILlow drawing object. I think we do still have wrapper methods around it though, so maybe we can fill in some holes there and then have the PIL object only available on CPython.
dwalton76 commentedon May 25, 2019
I think if we could get just text to the display working that would be worth committing. Drawing shapes, etc could all come later if needed.
Am doing my work here if you want to give it a try. I can't actually get anything to display though (using
Display.text_pixels)...not sure why yethttps://github.com/dwalton76/ev3dev-lang-python/tree/micropython-display
dwalton76 commentedon Jun 8, 2019
Hmm this looks interesting
https://docs.micropython.org/en/latest/library/framebuf.html
dwalton76 commentedon Jun 8, 2019
oh wait David's code was already using that...doh!!
bpmerkel commentedon Jul 19, 2019
Okay. Just in case anyone is watching this space... You can display and position text on the LCD screen using escape code sequences supported by the EV3DEV console driver (appears to support the VT100 sequences). Here are some code snippets that'll get you started:
dwalton76 commentedon Jul 19, 2019
@bpmerkel that is awesome, nice work!! :) Would you be interested in taking on this ticket? Basically just take what you have above and stick it in a
Displayclass that is only used whenis_micropython()is True, else use the Display class that we have today.bpmerkel commentedon Jul 19, 2019
Looking at the Display() class, it's pretty embedded with the FrameBuffer-based logic (it subclasses FbMem). Instead of spaghetti
if is_micopython()paths, what do you think about creating a newConsole()class within display.py, that simply offers the VT helper functions for the LCD panel console/tty (and would work in both python3 and micropython)?dwalton76 commentedon Jul 19, 2019
We've tried to keep the API the same for the python vs micropython equivalents of the same class so even though it is a little if/else spaghettish it does make it easier to take a program and jump back and forth between python/micropython. For the micropython implementation of Display text_grid() would be the only method you would really implement, for all of the others I would just have the log a "not supported in micropython" message.
dlech commentedon Jul 19, 2019
I think it makes sense to have a distinct text and graphics modes for the display. Startup time of programs could be greatly improved if they don't want to use graphics mode and just display text.
WasabiFan commentedon Jul 21, 2019
I agree with David here — I think the text mode functionality would be best suited for its own class and API. It's useful, but it isn't a replacement for true drawing and isn't used in the same way.
bpmerkel commentedon Jul 21, 2019
Okay. Plan B. I submitted a PR for Display() with is_micropython and layered the ANSI code logic into the Display() API as best it could (minus the Image and text_pixels functionality). Let me make another fork and build a Console() class (for both Python and micropython). I'll submit a second PR and let the keepers review for applicability. :-)
WasabiFan commentedon Jul 21, 2019
That sounds excellent. Thanks!
Apologies for being slow to respond; my internet connection is two tin cans and some string at the moment so I'm not checking GitHub very often.
dwalton76 commentedon Jul 21, 2019
A separate Console class sounds cool to me. Will take a look at PR this evening.
Console() implementation (#649)
dwalton76 commentedon Dec 26, 2019
@WasabiFan any objections to closing this now that we have the Console class? Pulling off Display in micropython doesn’t feel like it would add enough given the amount of work it would take.
WasabiFan commentedon Dec 28, 2019
I think we should leave it open even though it's deprioritized. This is always available if someone wants to take it on and is useful to reference what is/isn't implemented.