Hi William Although node-serialport did not work for me, in retrospect I can't blame the library. My application required control over the handshaking signals so I needed something capable of that. At the time, node-serialport did not have this feature but pyserial did. So I went with pyserial which caused everything else to be in python as well. I'm happy with the outcome though.
best regards, keyvan On Sun, Mar 15, 2015 at 4:20 PM, William Hermans <yyrk...@gmail.com> wrote: > 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 a topic in the > Google Groups "BeagleBoard" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/beagleboard/dTKvTB0ZhCk/unsubscribe. > To unsubscribe from this group and all its topics, 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.
