programming BBB - choice of language

[richard.leverton]

Hello All

I'm starting to design a commercial project which will use a number of networked BBB's as process controllers.  While I"m an experienced DP guy, I"m an absolute newbie with the BBB hardware and software.

I'm at the point of choosing a language in which the applications will be written.  The main application will be a no-user, stand-alone, repetitive data-processing application, so I want a language with the following characteristics :

1. high level
2. procedural
3. modular - high cohesion and low coupling
   
4. non-object oriented
5. strong array processing
6. runs under Linux
7. compilable
   

My research tells me that Python is the most-used high-level language within the BBB community, but it fails ( at least somewhat ) on several of the above requirements.

My research tells me that XBasic ( which satisfies all of the above ) doesn't seem to be much used within the BBB community.

My Questions, therefore are :

A - XBasic is said to run under Linux - does anyone know of a reason why it would not work on the BBB  ?

B - am I missing something profoundly wrong with XBasic which precludes its use ?

thanks very much for taking your time to help me out

richard

[Stephan Mulacz]

It's a bit of an contradiction for me that you ask for modularity but don't want an object based language.
Development of XBasic seems to have stopped about 2002. The community that could help you will be rather small.
Much of the documentation is not available anymore. I can only assume that this is an interpreter language as most of the basic dialects (although sourceforge category is 'compiler').  This means you would need to compile the interpreter sourcecode for the ARM before you can use it.
I would recommend a more recent language with a bigger community. I never needed any other language than C++. Here and than I thought I need to learn java, but than I never needed it.
C++ is probably the best supported language on Linux systems. If you don't want objects you don't need to use them.

Chilli

[William Hermans]

It's probably time for you to embrace modern technology, and forgo some ( or all ) the restrictions you're placing on yourself. Past that. these restrictions are not reasonable. A programing language is a tool, and every took has its intended use,

C for example could possibly work very well for your situation, but really depends how important the above restrictions are, restriction #1 would have to go, and restrictions 3 & 5 may fit the bill, depending on your definitions on each. C is very modular in the context that you can compartmentalize your code, and strong array processing . . . would depend on you, your ability to find a good library, and / or using regular expression.

Another consideration would be what exactly are you building ? Some languages are better suited for different types of projects. Not necessarily the languages in of themselves, but the libraries, or quality of libraries available to the given languages. No one in their right mind would deny that you *could* write a web UI backend using C, or even ASM. But something like Nodejs ( javascript ) may very well make more sense in the long run.

--
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...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Richard Leverton]

hi William

thanks very much for replying

you are absolutely right that a programming language is a tool, and a metaphor that resonates with me since I"m also a woodworker.  I know that I can use a jackknife or an axe to shape a board, but a saw and plane do the job better and with less work, so I always use the tool that is appropriate.

You've clearly spotted the fact that i'm an old-timer, but i'll take an old-timer's perogative to give you my point of view - the 'restrictions' you think I should forgo are not restrictions I place on myself, but the design considerations required by a mindset that goes back to the old days when it was unthinkable to release a piece of code with even one error in it.  By consciously selecting the tools that will produce the best job, I actually free myself ( and the coders i hire ) from endless recoding and patching.  however, enough of my rant  :-)

you're also right to ask what I"m building and relating it to the language I use - since the product will NOT be an end user product, it doesn't need slick web dodads or gui interfaces.  what the product will be is process control code applying a patented logic through a network of microprocessors which control an industrial process through hundreds of sensors and relays. what it needs is perfect code, easily written and easily maintained that will run 24/7 unattended without fail.  That is why my list of requirements is what it is. The only thing 'new' in what i'm doing is the BeagleBone black microprocessors which weren't available in the 'old days'.  Sadly, the modern software technology ( and i daresay the modern software coders' mindset ) is responsible for the shoddy and error-ridden code i see almost everywhere.  I'm hoping to avoid that trap.

Your tip about good libraries is also a very good one, and one that I am actively pursuing ( but of course, I need to choose a language in order to use the library, don't I   :-)   )

not sure what you mean by 'regular expression'

anyway, I really appreciate your taking the time to offer your advice, and I hope my ranting hasn't been discourteous.

regards
richard

[Curt Carpenter]

I'd suggest taking a look at Free Pascal.  It's well supported and can be compiled and cross-compiled on a number of different platforms including the BBB.   It also enjoys a wide range of libraries and a good and active support forum.  You can get an idea of capabilities by visiting the Lazarus website:   http://www.lazarus-ide.org .  Lazarus supports rapid application development and is built on top of free pascal.  Free pascal itself can be run in a command line mode that disposes of all of the overhead that goes with an elaborate GUI.   This makes it well suited to applications that don't require a lot of man-machine interaction.

Array handling is not integral to the Pascal language, but you will find a broad assortment of math libraries, some more optimized than others, that are written in the language.

Both the Free Pascal Compiler and Lazarus are open-source and available for free download on the internet.    I've used both on an RPi, but have been using C++ for now on my BBB.  C++ has the advantage of being supported by the the Eclipse IDE.  You can use C++, of course, without exploiting it's OOP capabilities.


 
 

[richard.leverton]

Hi Curt

thanks very much for your reply, I'll certainly take a look at Pascal

appreciate your taking the time to help
richard

[Harvey White]

On Mon, 9 Mar 2015 16:48:04 -0700 (PDT), you wrote:

>I'd suggest taking a look at Free Pascal. It's well supported and can be
>compiled and cross-compiled on a number of different platforms including
>the BBB. It also enjoys a wide range of libraries and a good and active
>support forum. You can get an idea of capabilities by visiting the Lazarus
>website: http://www.lazarus-ide.org . Lazarus supports rapid application

>development and is built *on top* of free pascal. Free pascal itself can

>be run in a command line mode that disposes of all of the overhead that
>goes with an elaborate GUI. This makes it well suited to applications
>that don't require a lot of man-machine interaction.

Lazarus also provides a GUI.

>
>Array handling is not integral to the Pascal language, but you will find a
>broad assortment of math libraries, some more optimized than others, that
>are written in the language.
>
>Both the Free Pascal Compiler and Lazarus are open-source and available for
>free download on the internet. I've used both on an RPi, but have been
>using C++ for now on my BBB. C++ has the advantage of being supported by
>the the Eclipse IDE. You can use C++, of course, without exploiting it's
>OOP capabilities.
>

I thought that the support for the cross compiled environment that we
need for the BBB was lacking in Lazarus, good to hear that it is not.

Had you made GUI applications with Lazarus? It would be good to know.
Then there's still the library support for the hardware, though, but
Pascal can call C++ routines, IIRC.

Harvey

>
>
>

[richard.leverton]

Hi Harvey

thanks for the tip, and thanks for taking the time to help me

regards
richard

[William Hermans]

Richard, I can not state it any better than wikipedia ( regular expression ).

http://en.wikipedia.org/wiki/Regular_expression

Basically like wildcards, but much more powerful. Now as to whether or not just using "regex" represents "strong array handling" . . . again that depends on your definition.

When I mentioned a web UI backend above that was just an example, but what you're describing seems to fit C very closely, No, C is not high level, but as long as C has been around, you can almost guarantee you'll be able to find a library that will work for you. An executable compiled from C can also be very compact, and super fast.

Now for sure, an inexperienced developer can write bad code in C, however this is true of any language. Possibly more so with C, since it is a very powerful language. A language that also demands you understand what your code does. But again . . . this is true for all programing languages out there.

Easy to maintain ? Bug free code ? This is all the responsibility of the developer(s) using any language.

I would also consider how much bloat many of these high level languages add to an executable when compiled.

With all the above said, one other language did come to mind after thinking about it a bit. FreeBasic, but I've never used it. So I have no idea what the BCL ( base class library ) is like, and no idea how many libraries exist for it. It is one of the few languages I hear of now and again, but have never looked in to. Mostly because I try to distance myself from any form of basic when possible. Funny that back in the  early 90's the first languages I started with was quickbasic . . .

[William Hermans]

I might also mention Perl, except that it is not exactly a compilable language. Compilers do exist, but may not exist for armhf yet.

Perl is very well known for its string manipulation as well as it's very ugly syntax . . .

[Harvey White]

On Mon, 9 Mar 2015 17:32:55 -0700 (PDT), you wrote:

>Hi Harvey
>
>thanks for the tip, and thanks for taking the time to help me

Sure. However, I'm not sure how well Lazarus supports processors like
the BBB. All I've used it on is the PC, where it's reasonably
compatible with old Delphi code. I was not convinced that they really
had done a good job on the language yet....


For embedded programming (Xmega), I use embedded C (GNU-AVR).

Harvey

[Stephan Mulacz]

Sadly, the modern software technology ( and i daresay the modern software coders' mindset ) is responsible for the shoddy and error-ridden code i see almost everywhere.

I can only partitally follow you. The problem is not the tool. The problem is the people using it!! The more sophisticated the tool the more ways to use it wrong. The more automatisation in the tool the more likely that some fools use it w/o knowing what they do. And in big projects with many people involved you will have a combination of both...

But I know what you mean with mindset. eg. introducing a garbage collection... my mindest is that my code produces no garbage! ;-).

Nevertheless high reliability is less a matter of the programming language than of the SW concept! And of OS.

Anyway I get the feeling you are more concerned about crashes caused by the OS than caused by your program.

Maybe the correct order to start would be

 

1) Choose OS (Startup time? Latency? GUI? long term support? supporting community?)

2) Define needed supporting functionallity (math, graph, I/O, protocols...)

3) Think about programming language available for 1), able to interface 2)

 

I'm not sure if you have covered all points from 1), yet.

If you talk about process control I would immediately opt for an RT OS. But since you want to replace an old hardware Debian is very, very likely fast enough w/o any RT patches -see toyooka_LCJ2014_v10.pdf . Nevertheless, you should think about RT OS: I would expect that RT OSs are not only built for low latency but also for highest reliability -but I'm no expert on that.

 

Chilli

 

 

[pietersyd...@gmail.com]

Look at Golang.org

I just finished a html5 webserver running on the BBB built in Golang and cross compiled from Ubuntu for ARM.

The performance gains with Golang's concurrency model is huge and it's rather new with many functional improvements over C/C++.

It's easy to pick-up and get going with,but don't take my word for it, check it out at http://www.golang.org

Pieter

[Harvey White]

On Tue, 10 Mar 2015 01:45:18 -0700 (PDT), you wrote:

>
>>
>> Sadly, the modern software technology ( and i daresay the modern software
>> coders' mindset ) is responsible for the shoddy and error-ridden code i see
>> almost everywhere.

In software, you either look for the errors yourself and protect
against them by coding, or you let the compiler/runtime find them
(error checking, bounds checking, bad pointers).

We won't even go into good testing methodology, which can take a
substantial fraction of the time it takes to develop the code itself.

>>
>I can only partitally follow you. The problem is not the tool. The problem
>is the people using it!! The more sophisticated the tool the more ways to
>use it wrong. The more automatisation in the tool the more likely that some
>fools use it w/o knowing what they do. And in big projects with many people
>involved you will have a combination of both...
>But I know what you mean with mindset. eg. introducing a garbage
>collection... my mindest is that my code produces no garbage! ;-).
>Nevertheless high reliability is less a matter of the programming language
>than of the SW concept! And of OS.

If the language has no error checking built in, and permits escaping
from every structure there is, then you have more of chance of
generating and not finding errors (and writing structurally bad code),
than if the language has the tools and structure to either enforce
writing good code, or do error checking itself during runtime.

You pay for some of that with increased code size, complexity, and
slower performance.

Compare C against Pascal, for instance.

>Anyway I get the feeling you are more concerned about crashes caused by the
>OS than caused by your program.
>Maybe the correct order to start would be
>
>1) Choose OS (Startup time? Latency? GUI? long term support? supporting
>community?)

add hardware support for your processor and/or OS.

>2) Define needed supporting functionallity (math, graph, I/O, protocols...)


>3) Think about programming language available for 1), able to interface 2)

And the same things that influence the OS support also influence the
language support.

>
>I'm not sure if you have covered all points from 1), yet.
>If you talk about process control I would immediately opt for an RT OS. But
>since you want to replace an old hardware Debian is very, very likely fast
>enough w/o any RT patches -see toyooka_LCJ2014_v10.pdf

><http://events.linuxfoundation.org/sites/events/files/slides/toyooka_LCJ2014_v10.pdf> .

>Nevertheless, you should think about RT OS: I would expect that RT OSs are
>not only built for low latency but also for highest reliability -but I'm no
>expert on that.
>

An RT OS has a maximum defined time from an event to responding to it.
Nowhere is it defined how much that time is, but that it is a maximum.
FreeRTOS is available for the BBB processor, should you need to
consider it. It also comes in a high reliability version. An RT OS
is no guarantee of reliability, one way or another.

Note that in terms of latency, if you want millisecond responses,
that's one thing. If your application is to log data every 10
seconds, then an RT OS needs to take less than 10 seconds to do all of
its stuff. Clearly not the same thing, but it fits the definition.

Harvey

>Chilli
>
>

[Graham]

Richard:

I am going to talk about a question you didn't ask.

What is the life of a BBB in continuous operation, such as a commercial process controller?

The BBB is a teaching, learning and experimenting platform.  It is powerful and an amazing value for the cost in this application.

It will last more than long enough to get the students graduated and eventually become technologically obsolete.

However, the (low cost) eMMC on the BBB is a life limited part.  It may or may not become an issue in a heavily used, continuous service application that is expected to run for 15 or 20 years, that is typical of an industrial environment.

The life limit is the number of writes. And it has write leveling built-in, so that heavily written areas of the eMMC memory will get remapped and distributed around the physical memory space.  How long it will last depends on how much of the memory space you are using, how much you leave free for memory leveling, how many times you write to the eMMC, and the size of the executing program in RAM, and the resulting page swapping activity.

You may get a longer life product by not using the eMMC and instead using a very large (high quality, with good leveling algorithms) microSD card, so that there is a tremendous amount of unused memory space for memory leveling.

Just saying ...

--- Graham

==

[richard.leverton]

Hi William

thanks again for responding - I"m very grateful for all the advice you and the others are offering

thanks for the clarification about regular expression

I keep hearing C over and over, and have to admit that I have an ingrained dislike for C ( probably irrational , so I should put that aside and take another look ).  thanks

You're ( largely ) right about the bloat caused by high level languages, BUT I think that concern is less important now (with today's fast processors with huge memory) than it was in the old days ( when everything was slow, huge, and expensive ).  Even 40 years ago we realized that the advantages in codability and maintainablility more than outweighed the value of saving a few processing cycles or bytes of memory/storage.  So, I feel it's even more inportant now than before because the cost of coders greatly outweighs the cost of memory and/or processing, so I"ll keep hoping for a high-level language that can be used with the BBB.

You're absolutely right about bad coders writing bad code regardless of the language.

It's interesting that you talk about FreeBasic  I happen to think that Basic is a good language.  the old QuickBasic was the closest PC language that I ever found to get close to mainframe PL/1 ( which in my opinion was the best language ever. The last major project I led generated a system that was about 15million lines of code which was still running about 30 years later ( last I heard ) and it was written in PL/1.  I'm still hoping to find something that good in the 'new world'.

again, I appreciate your help and respect your viewpoint
richard

[richard.leverton]

Hi Chili

you are mostly right - the problem is not solely the tool - it is mostly the people. Sadly, however, many of the 'modern' tools are equally flawed for exactly the same reason - very few people today do real design - they just code away until something sort of works.

I'm concerned about crashes of any kind ( hardware, OS, code ), and your selection order makes sense.  However , I have started one step earlier by selecting BBB as the hardware, and that somewhat limits the choice of OS which further limits the choice of language.

I'm very impressed with the level of advice I've been getting in this discussion, and I"m sure it will eventually help me make the right choice.

thanks again
richard

[richard.leverton]

Thanks, Pieter

I've never heard of Go and had not idea it was running on the BBB.  I'll check it out.

regards
richard

[richard.leverton]

Hi Graham

you make a very valid point about the expected lifetime of the hardware.  I fully expect some of the BBB's will fail over years, but since the project is a highly distributed system, no one failure is critical and is within the error reporting mandate.

you also make a very good point about using the biggest and best SD card.

thanks for the help

richard

[Robert Nelson]

On Tue, Mar 10, 2015 at 11:06 AM, richard.leverton
<richard....@sympatico.ca> wrote:
> Hi Graham
>
> you make a very valid point about the expected lifetime of the hardware. I
> fully expect some of the BBB's will fail over years, but since the project
> is a highly distributed system, no one failure is critical and is within the
> error reporting mandate.
>
> you also make a very good point about using the biggest and best SD card.

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 Nelson
http://www.rcn-ee.com/

[Stephan Mulacz]

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

 

 

[Graham Haddock]

> 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

==

[Robert Nelson]

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...

[Graham Haddock]

Thanks for the reference.

--- Graham

==

--
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...@googlegroups.com.

[William Hermans]

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.

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...@googlegroups.com.

[Robert Nelson]

On Tue, Mar 10, 2015 at 2:18 PM, William Hermans <yyr...@gmail.com> wrote:
> 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 ?

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..

[Stephan Mulacz]

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

[Keyvan Fatehi]

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

[William Hermans]

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*.

[Keyvan Fatehi]

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

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...@googlegroups.com.

[Stephan Mulacz]

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