Keyvan, Hey there. I am curious as to why you think serial is broken in Nodejs ? A serial port *is / can be* a file just like anything else in Linux. Since Nodejs has file methods provided as stock I would think it would / could be a no-brainer . . .
That said, obviously I do not know everything, so what am I missing ? I've toyed with Nodejs quite a bit, but never really dug into sending data out / reading data in over the serial port. *YET*. On Sun, Mar 15, 2015 at 5:00 AM, Keyvan Fatehi <keyvanfat...@gmail.com> wrote: > This is a really interesting thread, I haven't learned so much so quickly > in awhile! > > Hi Chilli > > I am also in a position where I'm developing a BBB with a touchscreen. I > chose python. I hardly ever used python previous to this project and > usually choose node.js or ruby which I know pretty deeply through years of > web development experience. > > I chose python because > * it has great support for the serial port which I needed fine control > over (node-serialport failed, it was my first attempt, I was sad about this > because I have to later refactor my python code in a "tickless" or > event-driven style when I have time -- I would have "got this for free" if > I had been able to use Node.js. Also with Node.js, if my project is a > success, I can find an abundance of coders that can wield it, but same can > be said for python) > * it has a fine webserver built in, cherrypy, this is serving my HTML and > Javascript for the "kiosk" > * it has a fine websockets library, ws4py, which provides the connection > between the python and the kiosk (which uses Chromium's HTML5 WebSocket) > > So far this working very well for me as my screen is doing normal things, > nothing crazy to require OpenGL or SDL or things like that which are more > foreign to me. My kiosk is using the following libraries: > > * Backbone.js (for its minimalism and modularity, although I tend not to > use this anymore in "normal" web app development [I tend to write normal > web apps in Meteor these days]) > > In your case you could easily do something like this and the protocol you > develop on the websocket wire (or a superset therein) can be (re)used for > non-local connections. The same HTML/JS can be reused (and extended) for > those non-local connections. > > best regards, > keyvan > > > On Wednesday, March 11, 2015 at 7:01:23 AM UTC-7, Stephan Mulacz wrote: >> >> >> Somehow we came a bit of topic. >> Since the thread is already starving I can maybe resurrect it just to >> highjack it a bit... >> I'm in a similar situation. I want to implement a program on the BBB with >> graphics and touch screen. But in the future there should be also a web >> interface for remote control. >> So I'm still a bit undecided if to implement first a local solution and >> add remote support later or if it is better to make only one common GUI >> that covers both. >> In first case I would very likely make a full featured local GUI with a >> c/c++ graphics library and a restricted web GUI later on (maybe with >> Mongoose or other web servers). >> In latter case (one full featuered GUI) I would probably use another >> language. Maybe html5/javascript with library (fabric, knietic, paper...)? >> >> What would you use if you had to support both, local and web interface? >> >> Chilli >> >> >> -- > For more options, visit http://beagleboard.org/discuss > --- > You received this message because you are subscribed to the Google Groups > "BeagleBoard" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to beagleboard+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
