Getting started in Embedded Linux

[yashrk]

  Hey Friends,
          I am soon going to work on a project at my work in which we will be replacing a PLC-based system with one based on a processor board running Linux. The system I am working on will have few temperature & pressure sensors and few PID loops to control motors and valves. I have a good background in C C++ and have worked and made things using microcontrollers. I have a limited exposure to the embedded Linux side of things, occasionally using Raspberry Pi etc.
          I have already started reading up on things and managed to write basic programs, getting used to Linux & it's terminal, communicated with Raspberry Pi over SSH and also recently successfully tried socket programming for Ethernet communication.

I currently am having multiple questions, let us break it down:-

          1. A good industrial SBC vendor. I have to select a vendor for my applications (as it won't be right to use a raspberry pi for an Industrial application) and I am having a hard time finding the right one. I have looked at Digi, Eurotech, Advantech, Embest tech and boundary devices. Is there any other big player I am missing? and In your experience which is a good vendor who might have a good support & documentation with the availability of boards in future.

          2. I am trying to find information on accessing GPIOs using C in Linux and I am having a hard time doing it. It is obviously easy to do it on Raspberry Pi (due to wiring pi library) but on any other SBC, I have not found enough documentation, am I missing something obvious? 

          3. How do, we do basic operations done on Microcontrollers like generating PWM signals, serial communication, timers, etc on a microprocessor/SBC?

          4. And lastly, any recommendation on books, online video or even paid trainings in India.

Thank You,
Yash RK

[rhb]

You might want to start by reading up on the *many* embedded Linux distros.  TI promotes the Beagle line for it's GPIO.  The PocketBeagle is $25 from Mouser, so not a big investment of money.  The design files are available which means if it is discontinued you can have some made very easily.  That might be better than trying to guess who will still be in business and selling a suitable board in 10 years.

I'm wandering into the  same middle ground between Unix and MCUs after many years of heavy Unix and assorted dabbling with MCUs.  TI has committed a lot of resources to ARM & Linux under the Beagle banner but with more of a working professional slant than the Pi. 

More than that I don't yet know.  I have a BeagleBoard X15 on order which should arrive midweek.  I'm getting it as a stepping stone and aid for  work with the Zynq based Zybo Z7-20.  With luck I should have it in a box and running by next week,

For what you describe I would think an STM32F4 would be a better choice.  Why do you need Linux? 

[agehall]

Why do you need Linux?

This is a very good question. Linux is nice and all, but it also brings in a lot of complexity which in my book is a huge trade-off. Maybe you have some other needs where Linux would really help you but from what you describe, I would personally take a long hard look at just doing bare metal programming with som MCU-board.

[yashrk]

Why do you need Linux?

This is a very good question. Linux is nice and all, but it also brings in a lot of complexity which in my book is a huge trade-off. Maybe you have some other needs where Linux would really help you but from what you describe, I would personally take a long hard look at just doing bare metal programming with som MCU-board.

This device is pretty basic for Linux, but there are many other applications in the pipeline which will be easily done on Linux. And having a good base for the Linux will be helpful for company's future. 

For what you describe I would think an STM32F4 would be a better choice.  Why do you need Linux? 

We have multiple devices like this which run on PLC which we might want to convert on to embedded systems, so using Linux will give us the flexibility we need to do that also we will be needing GUI interface on a display.

[agehall]

Fair enough. I would have gone for an bare metal solution as it would allow me easier access to hardware but either option works fine in the end. (Assuming you are not going to write kernel drivers which allows you direct access to hardware ofc)

[yashrk]

Fair enough. I would have gone for an bare metal solution as it would allow me easier access to hardware but either option works fine in the end. (Assuming you are not going to write kernel drivers which allows you direct access to hardware ofc)

True.
Can you please point me to resources that might be useful for the problems I am stuck at?

[agehall]

Can you please point me to resources that might be useful for the problems I am stuck at?

https://www.google.com

[Kalvin]

One option is to separate the design into two parts: The embedded part and the Linux part. The embedded part performs the actual control algorithm and provides the hardware interface, and the Linux part performs the connectivity, logging, firmware update etc. tasks. The embedded part and the Linux part can communicate over a serial bus or SPI bus, for example. Thus, you are free to select the Linux platform and the embedded hardware so that they are most suitable for the job. This approach will make life a bit easier if there are any hard real-time requirements.

[paulca]

I would gather that the system you are embedding linux into will have some form of GPIO device on a bus or peripheral port.

You will need a kernel driver for that which will present an interface to your user land applications to manipulate it.

You might have to write that driver yourself.

Depending on what bus or IO mechanism you end up using it might be a bit more complex than using the the Raspberry PI libraries.  Note that they also use a kernel module for various components.  The source code for them is available in the Linux Kernel + Raspbian patches and Raspbian modules.  The code for the various python libraries is there also.

I would start there.  Investigate using the Raspberry PI as an example and trace through how from a line of Python code does it call into the drivers, into the kernel modules and through the buses/io ports to the physical hardware.

Asides the bus and interrupt architecture being a bit more complex the kernel module driver code should be somewhat comparible to MCU code.  Of course the requirements placed on that code by the kernel itself will be a bit more complex.

There are examples of "HelloWorld" style kernel modules to start on.

Just remember that that the Linux eco system is a LOT more complicated than an MCU.  You have multi-processing, multi-programming, multi-user paradigms to work through.  Probably physical and virtual address spaces.  User permissions, kernel and user land memory address ranges etc. etc. etc.

[Kalvin]

Latest kernels typically have means to access the GPIO, I2C and the on-chip peripherals from the /sys/class interface. This may be quite sufficient if your system doesn't require hard real-time responsiveness.

Writing a simple kernel driver is not magic, but requires some time and effort. Starting from an existing driver and modifying it for your purposes is a typical approach. Please keep in mind that you cannot link the driver statically into kernel unless you also release the source code as required by the kernel's GPL-license. But using a dynamically loaded driver seems to be just fine.

[nfmax]

He hasn't updated it in a while now, so some of the information is a bit dated relative to modern kernels, but Derek Molloy's website http://derekmolloy.ie/ has lots of useful stuff. He has also written a book: this is published in two versions, one for the BeagleBone and one for the Raspberry Pi.

[sambran]

Look into Toradex, they offer a wide variety of SOMs and carrier boards (which they market as custom SBCs). I have found their documentation to be pretty good so I'd recommend looking through their developer pages.

Octavo Systems makes a really cool product, I've never used it so I can't say how easy it would be to use it in a product. The Beaglebone Black and Beaglebone Pocket use it, so buying one of those boards could be a good starting point.

[yashrk]

Look into Toradex, they offer a wide variety of SOMs and carrier boards (which they market as custom SBCs). I have found their documentation to be pretty good so I'd recommend looking through their developer pages.

Octavo Systems makes a really cool product, I've never used it so I can't say how easy it would be to use it in a product. The Beaglebone Black and Beaglebone Pocket use it, so buying one of those boards could be a good starting point.

Thank you, buddy, you might just have solved my biggest problem  Emailing vendors now

[Delta]

          1. A good industrial SBC vendor. I have to select a vendor for my applications (as it won't be right to use a raspberry pi for an Industrial application)

I don't mean to hijack this thread, nor ask a stupid question, but why not a Raspberry Pi?

I know they are cheap and considered a "toy" (and were designed as such - or rather educational toys), but are there any engineering reasons why you would NOT use a RasPi in an industrial application, assuming it has the required grunt etc?

[rstofer]

Like the Arduino, the Raspberry Pi is perceived to be a 'toy', not suitable for 'real work'.

That isn't the problem, the idea of replacing an industrial grade PLC with Linux on a board is the real problem.  In the first place, PLCs are designed to be deterministic in operation.  Linux isn't even a real-time OS much less deterministic.  There is simply no way to know how much latency there will be in any operation and throwing Python (to use their IO libraries) into the mix makes it worse.  Remember, in a PLC, at every loop cycle, every input is read, all logic is evaluated and all outputs are latched.  Every rail is evaluated on every cycle.

Still, some kind of system could be cooked up but the next problem is the environment.  PLCs are designed to live in a truly ugly environment.  Noise, voltage spikes, system faults, whatever, the PLC is expected to survive and keep operating (if physically possible).  To add all of this protection around a commercial SBC, with or without Linux, is a gigantic undertaking.

There's a reason that industrial grade PLCs cost a lot of money (relatively) - it is the nature of the operation and the environment in which it operates.

My exposure to PLCs is industrial automation - out on the factory floor where anything and everything can happen to the equipment.  I don't see SBCs as capable of matching this performance without a LOT of protective circuitry around the outside.

Perhaps the OP's application isn't as severe as true automation.  Perhaps it is simply a data logger - no problem, data logging is trivial.  But real-time control is not.

[yashrk]

Like the Arduino, the Raspberry Pi is perceived to be a 'toy', not suitable for 'real work'.

That isn't the problem, the idea of replacing an industrial grade PLC with Linux on a board is the real problem.  In the first place, PLCs are designed to be deterministic in operation.  Linux isn't even a real-time OS much less deterministic.  There is simply no way to know how much latency there will be in any operation and throwing Python (to use their IO libraries) into the mix makes it worse.  Remember, in a PLC, at every loop cycle, every input is read, all logic is evaluated and all outputs are latched.  Every rail is evaluated on every cycle.

Still, some kind of system could be cooked up but the next problem is the environment.  PLCs are designed to live in a truly ugly environment.  Noise, voltage spikes, system faults, whatever, the PLC is expected to survive and keep operating (if physically possible).  To add all of this protection around a commercial SBC, with or without Linux, is a gigantic undertaking.

There's a reason that industrial grade PLCs cost a lot of money (relatively) - it is the nature of the operation and the environment in which it operates.

My exposure to PLCs is industrial automation - out on the factory floor where anything and everything can happen to the equipment.  I don't see SBCs as capable of matching this performance without a LOT of protective circuitry around the outside.

Perhaps the OP's application isn't as severe as true automation.  Perhaps it is simply a data logger - no problem, data logging is trivial.  But real-time control is not.

Yeah, that's the gist of it. 

Truth to be said there is nothing that other SBC are doing that a raspberry pi cannot do, but there are perks to being using an industrial grade SBC in terms of design and built-in safety for the IOs and the support you get from the vendor is helpful, also there are few features I would like to have which are available not on the Raspberry Pi.
I have seen few companies in India which are in the networking & automation side of fields using R-Pi for industrial use.

[Delta]

Like the Arduino, the Raspberry Pi is perceived to be a 'toy', not suitable for 'real work'.

That isn't the problem, the idea of replacing an industrial grade PLC with Linux on a board is the real problem.  In the first place, PLCs are designed to be deterministic in operation.  Linux isn't even a real-time OS much less deterministic.  There is simply no way to know how much latency there will be in any operation and throwing Python (to use their IO libraries) into the mix makes it worse.  Remember, in a PLC, at every loop cycle, every input is read, all logic is evaluated and all outputs are latched.  Every rail is evaluated on every cycle.

Still, some kind of system could be cooked up but the next problem is the environment.  PLCs are designed to live in a truly ugly environment.  Noise, voltage spikes, system faults, whatever, the PLC is expected to survive and keep operating (if physically possible).  To add all of this protection around a commercial SBC, with or without Linux, is a gigantic undertaking.

There's a reason that industrial grade PLCs cost a lot of money (relatively) - it is the nature of the operation and the environment in which it operates.

My exposure to PLCs is industrial automation - out on the factory floor where anything and everything can happen to the equipment.  I don't see SBCs as capable of matching this performance without a LOT of protective circuitry around the outside.

Perhaps the OP's application isn't as severe as true automation.  Perhaps it is simply a data logger - no problem, data logging is trivial.  But real-time control is not.

Yeah, that's the gist of it. 

Truth to be said there is nothing that other SBC are doing that a raspberry pi cannot do, but there are perks to being using an industrial grade SBC in terms of design and built-in safety for the IOs and the support you get from the vendor is helpful, also there are few features I would like to have which are available not on the Raspberry Pi.
I have seen few companies in India which are in the networking & automation side of fields using R-Pi for industrial use.

Yeah, sorry, I was not talking about PLC vs SBC - I work in heavy industry and am a PLC man through and through (Siemens S7 in particular); I was asking in an application where a Linux SBC is suitable (HMIs, data logging etc), are there engineering reasons to NOT use a RasPi?

[paulca]

SDCard storage is unreliable.

You will need to set up the Raspberry PI to be read-only and put it's OS on a network drive if you want reliability.

MicroSD Cards, even branded expensive ones have a high cyclic (lots of writes) life expectancy of a few years before you start to run into issues.  Running an OS off them can cause issues.

[Raj]

i'd say,hybridise.
you're microcontroller expert
use r.pi to control microcontroler,use usart/i2c/spi etc

personally,i think,raspberry pi is waste of power

about indian companies using r-pi,I've seen most of them shifting to their own variant of custom boards in the very next generation.
I can't remember which one,but one of them used arm cortex variant,with pcb made in tiawan