programming BBB - choice of language

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

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

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.

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

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.

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

Hi Curt

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

appreciate your taking the time to help
richard

Hi Harvey

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

regards
richard

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

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

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

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

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

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

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

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

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

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

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

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,