Can anyone suggest links/resources for sample project implementations of embedded projects using c++ or gcc.
Many resources are target specific, so you will have to be more specific if you want a specific answer. However http://embedded.com/ is a good general resource, and depending on your geographical location, you may qualify for a free subscription to Embedded Systems Design or Embedded Systems Design Europe paper publications.
Apart from Atmel AVR, GCC is targetted for 16/32bit targets, and C++ is generally ambitious and unnecessary for 8 bit, so I am guessing we are considering 16/32bit targets?
You might also take a look at:
Martin Thomas's ARM-Projects, including a GCC toolchain for Windows.
http://embdev.net/ which includes an embedded GCC forum.
Building Bare-Metal ARM Systems with GNU A description of bringing up a system using GCC with C and C++
FreeRTOS a well respected and widely used open-source RTOS kernel
eCos another open-source RTOS, but somewhat more than a scheduler kernel.
There are many many many resources....the question is too broad. Do you have a particular embedded micro you are targetting?
different embedded apps have different concerns
real time concerns?
extremely limited memory / resources?
OS? no OS?
Security?
Failsafe?
Device Drivers?
Question is incomplete, you have to provide all information, like product summary, hardware you want to use. But I guess you are porting some linux kernel to some embedded device.
For application program, easiest is to cross compile your code from your local system for specific arch and then transfer the binary to your embedded product.
Related
I'm currently getting familiar with PLC's, the WAGO 750-8206 PLC in particular. It offers a linux OS and can run CoDeSys programs. There are some I/O modules attached to the controller: 750-530, 750-430 and 750-600. What I would like to know is this:
Is it possible to write a C++ linux application that runs on the PLC and gets/sets the digital inputs and outputs?
Even better: can I write a CoDeSys program that "talks to the I/O's" and handles all the logic and at the same time can be accessed by a C++ linux program? THe idea is this: I would like the CoDeSys program to check for let's say two digital inputs. If both are high, a variable should be set to a defined value. The linux application should be able to read that variable and conduct further processing (such as sending JSon data to a server or similar).
Also, I would need to be able to send commands from the linux application to the CoDeSys program in order to switch digital outputs (or set values on analog outputs etc) when the linux application receives a message that triggers the command.
Any thoughts and comments on this topic are greatly appreciated as I am completely new to this topic. Thanks in advance!
The answer you might want
The actual situation has changed into the opposite of the previous answer.
WAGO's recent Board Support Packages and Documentation actively support you in making changes and extensions to the PLC200 line. Specifically the WAGO 750-8206 and 17 (as of March 2016) other PLCs :
wago.us -> Products -> Components for Automation -> Modular WAGO-I/O-SYSTEM, IP 20 (750/753 Series)
What you have to do is get in touch with them and ask for their latest Board Support Package (BSP) for the PLC200 line.
I quote from the previous answer and mark the changes, my additions are in bold.
Synopsis
Could you hack a PFC200 and get custom binaries executed? Probably Absolutely yes. As long as the program is content to run on the Linux-3.6.11 kernel and glibc-2.16 and is compiled for the "armhf" API, any existing ARM application, provided you also copy the libraries it uses as well, will just run without even compiling it specifically for the PFC200.
Would it be easy or quick? No. Yes, if you have no fear of the Linux Command line. It is as easy as using the Cross Compiler provided by the Board Support Package (BSP) with the provided C-libraries and then run this to transfer your program to the PFC's flash and run it: scp your-program root#PFC200:/usr/bin
ssh root#FC200 /usr/bin/your-programOf course, you can use Eclipse CDT with the Cross Toolchain for the PFC200 and configure Eclipse to do do remote run and debug.
Will this change in the future? Maybe. Remember that PFC200 is fairly new in North America.It has, PFC200 has appeared in September 2014
The public HOWTO Building FORTE for Wago describes how to use the initial BSP to run FORTE, which is the IEC 61499 run-time environment of 4DIAC (link: sf.net/projects/fordiac ), an open source PLC environment allowing to implement industrial control solutions in a vendor neutral way. 4DIAC implements IEC 61499 extending IEC 61131-3 with better support for controller to controller communication and dynamic reconfiguration.
In case you want to access the KBUS (which talks to the I/Os) directly, you have to know that currently only one application can be in charge of KBUS.
So either CODESYS, or FORTE, or your own KBUS application can be in charge of the KBUS.
The BSP from 2015 has many examples and demos how to use all the I/O of the PLC200 (KBUS, CAN, MODBUS, PROFIBUS as well as the Switches and LEDs on the PFC200 directly). Sources for the kernel and with all kernel drivers and the other Open Source components is provided and compiled in the Board Support Package (BSP).
But, the sources for the libraries and tools developed from scratch by WAGO and are not based on GPL/Open Source code are not provided: These include the Application Device Interface(ADI)/Device Abstraction Layer(DAL) libraries which do CANopen, PROFIBUS-Slave and KBus (which is used all PLC I/O modules connected to the main PLC unit)
While CANopen is using the standard Linux Socketcan API to talk to the kernel and you could just write a normal socketcan program using the provided libsocketcan, the KBus API is an WAGO-specific invention and there, you'd have to do some reverse-engineering if you'd not want to use WAGO's DAL for accessing all the electrical I/O of the PLC, but the DAL is documented and examples how to use it are provided in the BSP.
If you use CODESYS however, there is an "codesys_lib_demo-0.1" example library which shows how to provide a library for CODESYS to use.
Outdated Answer
This answer was very specific to circumstances in 2014 and 2015. As of 2016, it contains incorrect information. Still going to leave as-is for now to provide background.
The quick answer you probably don't want
You could very reasonably write code using Codesys that put together a JSON packet and sent it off to a server elsewhere. JSON is just text, and Codesys can manipulate text in a fashion very similar to C. And there are many ethernet protocols available from within Codesys using addon libraries provided by Wago.
Now the long Answers
First some background
Since you seem to be new to Wago and the philosophy of Codesys in general... a short history.
Codesys is used to build and deploy Hard Realtime execution environments, and it is important to understand that utilizing libraries without fully understanding the consequences can destabilize performance of the entire system (bringing Codesys to its knees and throwing watchdog errors in the program). Remember, many PLC's are controlling equipment that could kill someone if it ever crashed.
Wago is fond of using Linux to provide the preemptive RT kernel for the low level task scheduling and then configuring Codesys to utilize much of the standard C-libraries that often accompany linux. Wago has been doing this for quite some time, but they would never allow you to peel back the covers without going through Codesys (which means using IEC 61131 languages, of which C++ is not included), and this was for your own safety (and their product image). If you wanted the power of linux on a Wago, you had to get a special PLC with a completely naked OS, practically no manual or support, and forfeit the entire Codesys runtime.
The new PFC200's have much more RAM and memory available than recent models, allowing for more of the standard linux userland stack (ssh, ftp, http,...) to be included without compromising the Codesys runtime, and they advertise this. BUT... they are still keeping a lid on compilation tools and required header files needed to compile and link to Codesys libraries or access specialized hardware (the Wago KBUS, which interfaces your I/O modules).
The Synapsis
Could you hack a PFC200 and get custom binaries executed? Probably yes.
Would it be easy or quick? No.
Will this change in the future? Maybe. Remember that PFC200 is fairly new in North America.
Things you may not know
Codesys does not necessarily know or care about Wago. You can get Target Platforms for Codesys that do target Intel processors running a linux os. Codesys DOES SUPPORT accessing external libraries (communication in the reverse direction is dangerous), but they often expect a C style interface, and you can only access those libraries by defining C-headers that Codesys will analyze, so you may need to do some magic to get C++ working seemlessly. What you can do is create a segment of shared memory that both C++ and Codesys access, and that is how they pass information (synchronization is another problem).
You can get an Open Wago PLC, running Codesys on Linux. Wago's IPC are made specifically for this purpose. They have more power, memory, and communication capabilities in general; but they do cost more than double your typical Wago PLC.
If you feel like toying with the idea of hacking a Wago, you will need to tear apart the manuals for Codesys (it has its own), the manuals for the Wago IPC's, and already be familiar with linux style inter-process-communication and/or dynamic libraries.
Also, there is an older Wago PLC that had the naked Linux on it 750-8??. It also has a very good manual on how to access the Wago hardware using supplied headers.
You must first understand how Codesys expects to talk to its target operating system. Then you work backwards to make it talk to Wago specific libraries living on that operating system. You must be careful not to hijack Codesys.
Your extra C++ libs should assist Codesys, not take it over. For instance, host a sqlite database on the same device, and use C++ to manage the database and provide a very simple interface that Codesys can utilize. All Codesys would do is call a function and pass some values, but your C++ would actually build an SQL query and issue it to the database (Codesys doesn't need to know why or how this is happening).
I hope at least one paragraph is helpful in some way.
Does any one know of any cross platform c/c++ libraries which will utilise the GPU for the purposes of floating point calculations, not specifically graphics oriented calcs. Which ones are in common use, which ones recommended , which ones have you had experience of. Specifically it should be open source with a GPL license.
addendum:- Any libraries you know of that are not GPU manufacturer specific.
addendum:- OpenCL has been brought up in a few answers as having cross GPU compatability. Does anyone have experience using it and can vouch for it's maturity? I'm guessing that if it's Kronos it'll be pretty good.
I would very much doubt that you have a reasonable chance of finding something like this as open source, as "utilise GPU" usually implies "heftily hardware specific, top secret NDA driver stuff".
However, OpenCL is as cross platform as you can get (works with every major vendor and even has at least one software fallback implementation) and it is reasonably free insofar as there are no fees and no restrictions on how you may use it. The only non-free thing is that it's not open source and you can't modify it.
ATI/AMD and nVidia have been offering OpenCL working on G80 and RHD, respectively, for some time, also ATI/AMD has been offering a software implementaion for a good time. As for Intel, I remember reading that they were working for OpenCL for Sandy Bridge generation about a year or so ago, so it should probably be finished by now as well.
How about OpenCL?
Here is the project page at the Kronos Group.
It all depends on the chip you are targeting but NVIDIA offers an SDK in the form of CUDA for Windows, Mac, and Linux. The license is not opensource but depending on what you need that might not actually be a big hurdle.
I am trying to save some money and develop a desktop application that would work on both Windows and a Mac OS. Is this possible? Can we do it in C++ and then, with a few fixes and tweaks, still reuse the same app on both OS?
Yes this is possible. Some code may differ as there are differences in the operating systems.
You should use a common library for GUI such as Qt: http://qt.nokia.com/
It is worth noting that Qt brings much more cross-platform features to the table, so familiarize yourself with it.
There will be some differences to handle such as
File paths (C: doesn't exist on Mac, \ and / are path separators, etc)
File endings differ (CrLf in Windows, Lf in Mac)
You need to compile to two different target CPU's. Most C++ compilers can do this.
The same code can be used for both, you just define regions to be (or not be) included depending on what OS the compiler is targeting.
Just Google a cross-os development guide, looooots of people has done this before. :)
It may not be relevant, but still worth noting (because you said "save money"), that both Java and the Mono Project (.Net, Qt) allows you to write cross platform applications with limited skills about the underlying platform. They are higher level language which in general are considered a time saver (but that is a separate discussion.)
Expanding on my comment:
Don't.
Write your library code in portable C++; putting as much as possible of the functionality in the library, making sure you study the platform-specific APIs (probably Cocoa and .NET) as you go, so the interfaces to the library are at least moderately suitable for either.
Then wrap your library in native binaries; ensuring that you pay attention to how applications are supposed to look on each platform, as well as the feel of them.
Building an application that looks like an X11 application and does everything in a manner somewhere between a Gnome application, a KDE application, an OS X application and a Windows application will really hurt user experience.
Badly.
WxWidgets
This question gets asked a lot, see also:
this question, this one and this one amongst others.
Coming in late to the party here!
I'm in the last stages of finishing a cross-platform, commercial application (OS/X and Windows for right now, conceivably Linux or iOS later).
We're using an open-source, cross-platform C++ development library called Juce, and I can't speak highly enough of it. It's extremely full-featured, the code is solid and high-quality, and you can apparently build for Windows, OS/X, Linux, iOS and Android from the same codebase (we've only tried the first two, but other developers are apparently reporting success for the other platforms).
What's particularly nice is that lead developer is very active on his bulletin boards and extremely responsive to trouble reports.
Also, you can license the library under GPL, and they also have a very reasonably priced commercial license.
Juce is very popular amongst people doing digital audio applications - indeed, to my best knowledge many or perhaps most of the top commercial digital audio apps use this system - but it's very full-featured and extremely fast and should be considered a top candidate for any cross-platform development application.
I ran into this question many times ago and have seen the terms again and didn't know their real concept in computer engineering.
What do platform and framework refer to?
I see many terms like platform-independent and development platforms, and also same for frameworks, but i can't quietly understand them. Do they refer to libraries? do they refer to different kinds of Operating-System?
The term framework is very well defined: a framework is very similar to a library, except that Control is Inverted. (Inversion Of Control is the defining characteristic of what constitutes a framework.) IOW: you call a library, but a framework calls you.
Another way to think about it, is that you write an application, but leave all the un-interesting details blank and use libraries to fill them. A framework OTOH is an application. It is an application which has all the interesting details left blank for you to fill in. (Of course, in the code you use to fill in the blanks you can in turn call libraries yourself. Also, the framework itself will call libraries to implement its inner workings. And, frameworks usually come bundled with a rich set of libraries which are tightly integrated with the framework. However, the distinction is still clear. Just because the framework and the libraries ship together in one package doesn't mean there is no distinction.)
The term platform, however, is not so well defined. It is also heavily overloaded. In the context of porting native applications, it usually refers to the combination of CPU ISA (e.g. x86, AMD64, IA-64, POWER, MIPS, ARMv9, Sparc), hardware architecture (PC, CHRP, PReP, Mac), kernel (Linux, NT) and base libraries (POSIX, Win32, Core Foundation).
In the broader context of software development, "platform" usually literally means "that which your code stands on". For a native application, that could be basically the same as above, for a JVM application it could be the JVM plus the JRE plus OSGI.
Basically, you can take the metaphor quite literal: a platform allows you (i.e. your code) to stand on higher ground than you could without it.
Platform is an amorphous term, which can mean:
Hardware (usually CPU/Architecture) e.g. x86, Alpha etc..
Operating System e.g. Unix, Windows, Linux, Mac OS X etc..
Virtual Machine e.g. Java JVM, FlashPlayer AVM
Frameworks on the other hand are usually a collection of tools: which could be software, hardware, methodology/pattern based (although not necessarily all of these in any particular framework) that combine to provide a way of building applications (or specific layers of an application)
A few examples of frameworks are:
Software
Java Swing
Microsoft WPF
Adobe Flex
Ruby on Rails
Django on Python
Hardware/Software
Arduino (arguable)
Trusted ILLIAC
Method/Patterns (or Process)
SCRUM
IBM Rational Unified Process
Platform usually means something to do with the environment the software is running in. So it often means the operating system (e.g. windows or Linux), but sometimes the architecture (x86 might be a platform, or the java virtual machine). A framework is usually a collection of functions or classes so often is the same as a library, or can be roughly understood in the same way.
I'll try the platform part: Platform is used to talk about something that you "build upon" or you can think of as "stand upon" for a literal analogy to get something done. I've used "telephony platforms" - which consist of software and hardware components that enable the development of interactive voice response systems.
You can have a read about Platforms and Software Frameworks here:
link text
I need to port a c/c++ codebase that already supports Linux/Mac, to VxWorks. I am pretty new to VxWorks. Could you let me know what are the possible issues that could arise?
We recently did the opposite conversion - we ported code from a PowerPC machine running VxWorks to an Intel system running Linux. I don't remember hitting many snags as far as the differences between the operating systems. Obviously any call to an OS specific API will have to change and we were not making extensive use of these functions.
Our biggest problem was not the difference between the operating systems, but rather the difference between PowerPC and Intel hardware. PowerPC is Big Endian and Intel is Little Endian. Our software is written in C and made many assumptions as to the order of bytes and this was an absolute nightmare to get it working smoothly again. There were literally hundreds of structures that defined bitfields and needed to be re-ordered to work correctly. We ended up implementing a #pragma in GCC that reversed these bitfields at their definition (#pragma reverse_bitfields).
Much depends on which version of VxWorks you're targeting, and the actual target processor itself. One thing you will have to deal with is that there is no paged memory system or virtual memory--you have what's there. The environment itself is far more constrained than a linux system. Sometimes the work involved in porting applications goes all the way back to the architecture level because resources are not as unlimited as they are in linux.
Some other tips:
license vxworks such that you have the source code available
use a real, physical target as soon as possible in the development cycle; do not count on the simulators accurately emulating the target
use TSRs (technical support requests) as necessary; I don't know how they structure the purchase of the right to create TSRs, but don't let anybody cheap out on these
Depending on what processor you are running with VxWorks endianness, structure packing, and memory alignment could all be issues. The last time I used VxWorks it supported a pthreads, sockets, and mutex layer that mimicked the unix environments easily enough.
It's difficult to tell, without knowing more about the application that you're porting: What linux libraries and api calls does it use? Is it self-contained, or does it rely on slews of linux command-line tools and scripts to do its job?
As Average says, endianness can cause you way more problems than you expect - particularly if you're not prepared for it.