May 14, 2018 at 1:47 AM #21605
I’d like to see some kind of serial port on the next revision of the OSSC for remote control/programming from another device. It would also be nice to know if this is something that could be retrofitted to <=1.6 OSSCs as well.
One example of usage could be using a PC to program profiles using a PC app, similarly to what’s been proposed for preconfiguring profiles that get established during a firmware upgrade, where the app would directly program the OSSC via USB serial console, rather than write them to an SD card image. Backing up profiles could also be possible, and perhaps even a firmware upgrade function that backs up the existing config, performs the update, and restores what it can from the backup.
Another example could be remote-controlling an OSSC based on input from other hardware. A secondary computer, like a Raspberry Pi, could be connected to the EXT port of a gcompsw and/or gscartsw and be programmed to know a) which console is connected to which port and b) what parameters to use for that console. When a given console on the gcompsw/gscartsw becomes active, the EXT port would tell the secondary computer which console was made active, and, based on that, the secondary computer could then automatically switch the input on the OSSC and either load the appropriate profile or perform reconfiguration on the fly.
Theoretically, the second example should already be possible using an IR blaster, but implementation would be way more straightforward, and the software could be tweaked to be version-specific, if there was something like a USB mini-B connector available to provide serial access.May 15, 2018 at 5:24 PM #21648
Technically there is already UART available via JTAG port, but it is currently used only for printfs in debug build. Additional functionality can be considered once a replacement for current soft-CPU has been integrated.July 25, 2018 at 9:21 PM #22600
@marcs Could you explain that a little more in detail? Would that mean that a HW-update is required for that kind functionality? (UART would be fine for me. USB would not be necessary)August 6, 2018 at 6:37 PM #22709
I didn’t mean HW upgrade – UART via JTAG is technically supported but until current Nios2 soft-core running control tasks (which would also handle high-level UART communication) is replaced with a more resource-efficient one, there’s simply no code space to use for UART features.June 5, 2019 at 9:22 PM #26522
@marqs, any update on this?
Being to send commands (and receive status updates) over UART would be incredibly useful. You could then see the current OSSC status without needing to see the small LCD screen. It would also be extremely helpful in home automation setups.June 17, 2019 at 5:58 PM #26684
Second this, it would allow me to hook it up with any SoC like a RaspberryPi or just a simple ESP and implement a REST API around it so I can control it through a web interface or any home automation software like Home-Assistant or OpenHAB. This way it could even be integrated with any voice hub like the Echo, Google Home or the Apple Homepod. So many possibilities!June 18, 2019 at 12:06 AM #26686
It’d be easy to map current user I/O functionality to UART, i.e. treating a received char as remote control key and printing out same data that is output on character display. I’m not sure how useful that’d be, though. A more fancy interface supporting direct access to settings and status would require more logic which would consume some of the remaining little memory.June 18, 2019 at 1:20 AM #26687
Direct access to settings and status is what I was asking for in my original request, and I think it’s the ideal interface for those asking for that type of functionality. I’d also hope it would include common functions, like loading and saving profiles and resetting the current profile to defaults without saving.
Being able to essentially accept remote control inputs over serial would be nice to have, but would require any configuration utility or remote-control application to navigate the menus as if it were doing it manually with a remote, which I imagine would require a more complicated scripting process that is aware of the OSSC’s menu structure.
You must be logged in to reply to this topic.