keirf
OSD display input/output via USART1
To be able to prep for the new FloppyMeister design without on board OSD I'd like to have input commands and display output status via the existing USART1. See this post.
I suggest something simple like char/string commands sent from the external device, and FF sending new screen updates when available. If debug info is in the way maybe either can be turned on or off in the config, or keep it running at the same time.
Commands and screen-data replies can be marked with say an '#' character at the start of the line to differentiate, and '##' to signify the start of a new screen.
example:
external device sends:
#L
FF code does a 'left key' command and returns the new screen:
## first line of screen
# 2nd line
..
# nth line
Suggested commands:
#p - previous item (left button)
#n - next item (right button)
#s - select (third / rotary click)
#u - request screen update
What about also adding a minimal Unix like shell ? ls for the list of files cd pwd for directory traversal mount/umount for the current image
then you aren’t just limited to Gotek style hardware usage paradigms
Is the usage scenario really "logging in" interactively, requioring plain-text commands, character echo, etc? Anyway, this ticket in this general form would be a dupe of #180
In the specific case of OSD interaction we already have a serial protocol (I2C).
So unless there's a motivating reason why we need UART in addition to I2C, for OSD I/O, this ticket makes no sense.
This ticket is not about logging in or implementing more commands but if it's not in the way I'm fine with expanding the API. I'm just interested in the control keys and display response though remotely unmouting and deciding what to mount next by name (without scrolling though a list) could have interesting possibilities.
So unless there's a motivating reason why we need UART in addition to I2C, for OSD I/O, this ticket makes no sense.
It does, like I explained in #440 where this ticket comes from. It is more open and interfacable with what's out there (and in any case the reverse argument can be said too for I2C vs UART1). #180 is also still open:
That would enable me (and others) to maybe stick it on another controller that I already have/is available, or split screen and input to separate devices, or build an IR remote, hook it up to a PC or whatever without being tied to an I2C source, the blue pill or its firmware.
Sounds reasonable indeed.
Issue #38 also request input control/output over U(S)ART for an external display device Any resolve on this?
I have a use case for this, at least for the output part. I was going to open a new request but then noticed this one.
This could be useful for the visually-impaired. I have a friend who has a Gotek on which I put FF. What he would like to do is have the Amiga "say" the name of the image while he's moving through them so that the visually impaired have a hint of what image they are selecting. Having the Amiga and Gotek connected through serial is the easiest thing I could think of. He is a developer so he would look into the Amiga software part.
He would still use the current means for image navigation, so this does not require the implementation of input commands.
I also have a use case for opening up a serial api on the rotary encoder pins. I've been working on an ESP32 bluetooth android controller as seen on the FF Facebook group. I have the app fully functioning as a controller but would love to be able to talk directly to the STM32 via a serial interface. I envision being able to populate the android app with the current image list, move to indexes directly, increment and decrement by one, reset to 0, and eject at least initially. If the serial api was taken far enough it would be great to eventually get read/write access to the USB stick.
I'm perfectly willing to write the ESP32 and Android side of things. In fact it already exists for the most part. I just haven't taken it any further as it's somewhat limited just simulating button presses at the moment.
Cheers...
