Closed freedaun closed 5 years ago
Hi. Arduino is normally embedded. Is there a specific use case you feel should be supported?
Hi Lea, thanks for considering this.
In general browser technologies do not allow access to the local machine, which in practice mostly means that files and ports are not accessible. Besides files, which are essential to almost all applications, access to serial ports in particular is essential to almost all "maker projects".
As most people are familiar with the Arduino, I used that term. I have programmed many Delphi desktop applications, none have ever used any ports other than the serial.
I think it is sufficient to provide access to the data-stream, and to I/Os like DTR. No other functionality would be required (I know some libs allow for parsing the data-stream).
Hope this answers your question. But maybe it didn't. In short I think the maker space is the use case that should be supported. A solution in this space is johny-five+firmata, but it imposes an odd protocol over the serial connection (frontend example: http://johnny-five.io/examples/motor/).
Note that my suggestion gravitates development towards the frontend, because with access to files and serial ports, Go development becomes unnecessary. But I could imagine a system where the emphasis would be on the backend. The frontend would consist of (rather simple) dialogs and visualizations (in a simple vertical stack of elements, all horizontally centered). The backend would process most clicks, update the model in response, and provoke screen updates. The frontend would consist mainly of render functions. This might be even simpler to use, as Go has primitives to easily handle several devices concurrently.
If you can create a list of specific things you feel would help this aim, I'm sure we can look into it!
The best project with similar code I've seen is: https://github.com/johnlauer/serial-port-json-server
In this project all serial port events are packed into JSON, in Wails they need to become a Wails event. The "serial*.go" files in particular are relevant, clarifying all events.
In a Vue example one would be able to:
The data is binary (raw bytes), no encoding. Whenever any of the inputs changes (may need polling), an event must be triggered, notifying the new state (of all pins). No need for individual pin updates (because that's easy to do on the frontend itself).
So I see this API:
A channel.disconnected() can come at any time. If auto-reconnect is supported, disconnected() and connected() events can alternate. Auto-reconnects are desirable as the connection can be suspended by the device, or by the user unplugging a serial port. These events may pass the motive of the break: port unplugged or device disconnected.
Additionally a log data to file feature would be useful (also for debugging), but that's probably better solved by access to the local file-system.
I believe everything you need is supported right now - simply write the Go and use it :-) Arduino would be running Linux right?
Arduino would be running Linux right?
No. Arduino is a placeholder for any device attached to a serial port, typically an Arduino, and Arduinos do not run Linux. Could even be a keyboard, or a MIDI device, anything that complies with the hardware of a serial port interface.
But given you're in the dark about serial ports, I guess you're not the right person to do this. Given time I could do this, I would have to figure out how to create Wails events in Go, for the frontend to consume. Doesn't seem difficult, would be my first Go ever though :)
Thanks.
Hi. Eventing is pretty easy. I recommend you have a look at the Todo tutorial. That's similar to what you want to do: most of the logic is in Go and when system events happen, they trigger application events. Once you get a runtime object, you can emit and listen to any events.
@freedaun Is there anything we need to do to close this now? Thanks.
Wails seems to be the best solution available for makers to add specific functionality and a user interface to their creation.
Arduino compatibility concretely means adding a mechanism to interact with serial ports directly from the frontend, probably enabled through a project configuration option.
A standard in this area means makers probably only need to program the frontend, just as they do now with native dialogs.
In the same vain the ability to use files in the executable folder, directly from the frontend, would be desirable.
With these features most projects, as they are simple, could be done without any Go programming. But when more is needed the capability to do so is there.