I was looking for a device with HDMI output, real AD inputs (no abused touchpad or PMIC inputs), interrupt support, basic graphic support and what I consider state of the art RAM and flash.
Compared to the general single board computers my requirements narrowed down the matches amazingly (like 4 left out of 122).
Than I was going for support and a bit for reliability of manufacturer. That’s how I came to BBB.
But all the single board computers on my shortlist supported more or less the same OS. So at least in my case ‘I should have considered OS before buying BBB’ does not apply.
When you do want to sell your solution it might also be neccessary to think about functional safety, if applicable. Regulations might have become more strict since your initial design.
In opposite to Richard Grahams considerations lifetime of BBB is not so relevant in my case. Everything is modular. If BBB dies in 5 years, I plug it out and put a new one in.
hmmm maybe we should consider long term availability of the boards… or put some boards in our storage… 
Chilli
With a specially tweaked file system, (read only root..) and correctly
using tmpfs on ram for your application, you can remove most of the
failures from even the crappiest SD cards. Along with extending the
life of the system, where power is not 100% stable.
Regards, Robert
Robert:
Could you expand on your comments, or point me at some references?
This is getting interesting.
Thanks,
--- Graham
https://wiki.debian.org/ReadonlyRoot
It takes some tunning to get right and depends on which packages you
are using... So there's no conrete example...
Regards,
Thanks for the reference.
— Graham
Robert, those beagleboard XM(s) you talked about a year or more ago that take pictures etc, and run off an SD card have been going how long ? I only mention this so everyone else can get an idea of how long a read only system can last. They also run Debian ?
@ Everyone else
Another way that you could fix the media write issue would be to load your rootfs from network or USB. Granted, this will use more power, and is far more elaborate. So not really for everyone.
Yeap, it's still taking pictures, haven't logged into the board in
ages, but it still uploaded today. It's running Debian Squeeze, with
some 2.6.xx/3.0.x kernel...
http://connectivity.digikey.com/outside.jpg
Last update as March 10, 2015 2:38PM
Probally should go up there and clean off the plastic box, as it's a
little hazy..
It's been running since "July 2010"-ish... Same Sd card... Just read
only root... with the camera storing the picture in ram/tmpfs before
uploading via ftp..
The Solar -> backup batteries design needs a rework, so it really only
works on bright days..
Regards,
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
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
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.
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
I thought that C++ plugins can be used in node.js. This would probably have been the way if had chosen if I wanted to include ultimate series port control.
To be honest I never though about Phyton. I know that the networking capability is good. But the second thing that comes into my mind is easy text processing. But not easy graphics control. I have to look into this because I probably just missed the developlment of the last decade ;-).
I’m looking for an easy graphic interface like javascript/html5 where you can just create window, load carnavas, place carnavas. Load image, place image, animate image, handle event. But I found this drop in approach only for interpreter languages.
Most libraries I found for C++ have the “painting philosophy” making everything more complicated (although I was used to this).
If I look at QT quick it says ‘QML is based on CSS and JavaScript’, ‘similarity to CSS and JavaScript’, … It starts to sound like it’s a javascript copy but I don’t see the advantage on using that copy.
I’ve learned that I don’t need OpenGL (I was mistaken on that in the beginning). But the majority of the elements that I’m gonna display is animated. So 2D hardware support for sprite position transitions and animiations would be a grat. Otherwise the BBB will spend considerable processing time on handling the graphics.
The most feasible approach in the moment seems to make the “worker thread” in C/C++ including a server (just because I know the language well and many potential future porblems might already have C solutions). And to make the GUI in javascript/html5. Than I have one common GUI. But I don’t know a way how javascipt uses HW graphic support on BBB.
I’m still in the conception phase. Web interface is a nice to have. Priority has ofcourse the local implementation. It could well be that I discard the whole web interface if it blows up the effort and log in on BBB via X window if needed.
Chilli