Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
I'm trying to write a program that can read from a bunch of sensors, make decisions on a windows computer, then write to some actuators (e.g. valves). This is all already done on an existing system and program but we want to do something different and so are starting with a new program on the windows computer from scratch.
The reading and writing of sensors etc is done through a custom-made PCI from the manufacturer and basically I'm not sure how to read and write to the registers on the board. I've done projects with Raspberry Pis and other microcontroller+PCBs but this one's a bit new. The original program was written in c++ if that helps.
Any general or specific info on interfacing directly with PCIs from windows systems would be great, and if this isn't enough info let me know and I'll provide more. Thank you!
You need to access the hardware via a driver provided by the manufacturer. Many manufacturers don't document how to access their drivers directly by the end user code. Instead, they provide an API library (in an SDK) that the users call into to operate the PCI device.
It'd help if you'd post a link to the device you're using - that way we could look at what's bundled with it and help you decide whether it's worth the effort. If the manufacturer is non-cooperative, this may be a relatively hard thing to do. You may have more luck not using the PCI card and e.g. getting some EtherCAT I/O modules, using an open source EtherCAT master library, and connecting your application to the I/O modules via a simple network card. That would be way more supportable, and very resistant against obsolescence, as the EtherCAT I/O is not going away anytime soon, and your code could be fully portable if you used a portable app development framework like Qt or wxWidgets. You could then run it on PCs, macs, Raspberry PI - and it'd do the same thing and look mostly the same. It's not a pipe dream - I maintain some code that does pretty much just that and it's a viable approach. As long as your requirements are "soft" realtime, it's bound to work. If you need hard-realtime, you'll need to limit yourself to Linux with realtime extensions, and access the network interface (using the ECAT master library) from a realtime thread. It's still more developer-friendly than, say, using a PLC with EtherCAT Master support - those usually use CODESYS under the covers, and that's basically just spreading misery :(
In my experience, supporting some custom motion-control PCI cards and such ends up being semi-rewarding, since you get to do some reverse engineering all too often, and that's a good challenge, but it's a dead-end ultimately. If the card has no API/SDK available, then it's best assumed that the manufacturer is dumping it, and all your work will be for nothing when it goes out of support or becomes unobtainium. It's best to rely on viable industry standards, and on interfaces that have multiple vendors on equal footing. EtherCAT I/O is dime a dozen, almost. You can use e.g. the (freely downloadable) TwinCAT to explore the I/O module's functionality and prototype stuff, and then implement it in your own code using the ECAT master library, perhaps with help of WireShark when needed.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
I have some experience in small projects with microcontrollers such as Arduino boards and ESP32. However, when programming these boards, you can usually use abstractions such as the Arduino IDE, which makes them very easy to program.
Indeed, I cannot manage to understand how microcontrollers (others than Arduino) are usually programmed under the hood. As far as I understand, usually, the manufacturers of microprocessors offer development boards to test their products, right? However, how are these microcontrollers/development boards usually programmed? With this I mean that there must be some code that is used to interface with the microcontroller, right? How is this "interfacing" code usually structured and how it works? Is there a common file system structure of this additional "interfacing" code? Is there something like a "main.c" file in which it must be written all your code and that is automatically executed when uploaded to the microcontroller? Is there any type of convention when it comes to programming microcontrollers? As well, how can you "upload" the code to a general microcontroller? For example, Arduino IDE makes this very easy (upload button and USB connection), but I suppose that this is not the usual method of "uploading" code when working with other microcontrollers, right?
The microcontroller is in reality just a small and simple PC with an architecture (such as ARM) that you compile your program's source code against. In a normal PC after BIOS finishes its post test, it will search for an operating system, execute it and hand control over to that. The OS in turn has a process tree that hands over execution to a program's main() function. When main finishes executing it returns a code (usually 0) indicating successful completion and control returns to the OS.
In an embedded solution, there is no operating system. The BIOS loads your program's main() function instead of something like Linux or Windows, and it never returns a value because there is no host OS to return to.
Go take a look at AtmelStudio if you want to learn more about building and installing to the boards. C is still very common for embedded applications, really the only limitation as far as what language you use is whether your compiler can target the board's architecture.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I have a question about sound.
I have used sound libraries like OpenAL in my projects before.
What I need, is insight as to what underling OS APIs these libraries use.
Even if each library provides an easy way to manipulate the input file
according to format, the very basic "raw byte-to-byte, send to the driver"
function has to exist.
I mean, surely there has to be a default api (one for windows, another for Linux)
that these libraries use. I don't suppose they use directly each sound
card's drivers, so the OS has to somehow do the magic. Am I correct?
Now, I know DirectX supports sound (Although I have never used it), but
DirectX isn't installed by default on windows, so I suppose it doesn't count,
and I have no idea what happens on Linux, and I would like to know about both.
I know it's probably impractical not to use a dedicated library, and I don't
really intend not to, but I'm curious about this subject.
So please indulge me.
So, for basic graphics it's OpenGL and DirectX... But what about sound?
Thank you in advance.
Each major platform has a number of API's that allow you to work with sound, On Windows and Mac there are Native Sound Api's that are used by default by the OS as well as well as others that are either Non-Standard or deprecated.
Have A look at he diagram HERE, it has a useful breakdown of many of the major sound API's across major platforms.
In addition to each platform having native sound API's there are also many cross platform API's that encapsulate the way that each native API works in order to allow you to write portable audio software.
For example there is: PortAudio which is a well know C language API
there is also RtAudio which is a C++ API for sound, but it is somewhat of an older C++ style in my opinion(Does not take advantage of post C++11 features).
I am currently working on my own more modern C++11 audio API which can be found HERE. At the moment my API is a thin wrapper around PortAudio that allows you to work with audio in a more modern C++ way.
Keep in mind, the library that you choose will also depend on what kind of audio work you intend to do. All of the libraries I have listed above deal with real-time audio processing and do not deal with audio files. If working with audio files is what you are trying to do you could use libsndfile which is a popular open source sound file manipulation API.
From the context of your question it sound like you have been dealing with sound primarily in a Game Dev related context. It's worth mentioning that working with sound at the level that most of the libraries I have suggested thus far will be at a much lower level than simply calling one function to play a sound file.
Trying to answer the question of how OpenAl interacts with the OS is an answer best left to reading the OpenAL documentation.
I would also suggest looking into basic digital audio theory as well as digital signal processing. There are many resources available for free online on either subject.
EDIT:
In regards to how audio API's work... The average audio api works off of several layers of abstraction between the programmer and the sound card. Typically the programmer is given a buffer of audio data stored as an array of values. The programmer will have requested a specific set of parameters that the system will use for playback (sampling rate, buffer size, number of channels). The programmer will do their work with the audio data and hand the output buffer over to the api which in turn will eventually hand the buffers data over to a device driver written specifically for the installed sound card. The driver for that sound card will have been implemented based off of an interface specified by the platform that the driver is targeting. That is why when you install a new sound card on a machine you may be required to install drivers for it, by installing the drivers you are giving the OS level api a means of communicating with the device.
(There is a lot more that goes on than is possible to easily explain, and i'm sure i have missed a few steps in the process. But I hope that should be a good enough explanation to get started)
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.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
We have very complex C++ image processing engine, using Intel Compiler, OpenCV, etc.
Currently it is being integrated in our production via C# interop layer, which is so thin, it almost doesn't affect speed performance (and we are talking about few milliseconds per request). Now we are planning to migrate our systems to CentOS (and still support Windows platforms). Historically I don't have much trust in Mono, JNI also has its issues so most logical solution is to move towards pure C++ implementation.
Is it good idea in your opinion, considering we need to port following functionality:
1) Filesystem
2) JSON
3) Threads
4) Storm / Kafka / RabbitMq
5) XML
6) Log2Cxx
By the way I thought maybe about Qt, we don't need UI, but it will cover for us Filesystem, Threads, XML and maybe even JSON.
Many thanks,
Pavel
There's a very high chance that your credit card payment was processed at by a system that runs Qt core, so you're on the right track.
Qt is modular. You need a couple of modules that exclude the GUI stuff, although even GUI is usable in a server. It's pretty damn easy to paint some images to send back to the client, for example. I would recommend to use Qt whenever possible and only fall back on Boost if Qt doesn't provide what you need and it can't be implemented in a simple fashion. If you'll be undecided between Qt and boost, you'll end up with a lot of glue code that will make the whole thing much more work than necessary.
Qt doesn't have a logging mechanism per se, it has some facilities for debug output, but it needs more if you want real logging. It does cover the file system, json, threading, networking, communication between objects using event queues and/or signal-slot connections. It also has streaming XML parsers. You can integrate your project with log2xx. The durable messaging infrastructure will also need to be integrated since Qt doesn't provide that. You may find out that it's easier to implement just what you need, as far as messaging is concerned.
Asking about speed overhead of threading is a bit pointless, since in almost any framework out there, a thread controller is just a means of starting user code in a thread. It no runtime overhead once a thread is created. Everything depends on what code you run in the thread.
What you want to ask about, thus, is what code would you normally "run" in a thread? Ideally, you want only to run the event loop provided in the default implementation of QThread. The event loop synchronizes with other threads only when you're posting messages to it from other threads. That's what any other implementation of inter-thread communications would do anyway, so there's no extra Qt-specific overhead. You then move QObjects into the thread that is to run them (or simply create in code that runs in that thread already).
When you have to encapsulate blocking third-party code, like the notorious blocking database interfaces, then you'll be forced to put every database connection in its own thread. This would be the case whether you use Qt or not, so nothing special there.
Qt's XML and json implementations are reasonable, I don't see why they'd be much worse than anything else out there.
If you're serious about your project, you'll become a customer of Digia. I'm sure they'll answer your questions about what level of support is provided, about the stability, etc.
One benefit of using Qt for your project is that it's cross platform: you can run it on Linux or Windows servers. If it's a system for installation by third parties, this may be an important consideration.
Qt might also cover Log2Cxx since it has a logging mechanism. You can certainly parse JSON as far as I know on Qt 5.0. QJson is another alternative, you can check out:
http://qjson.sourceforge.net/usage/
Beside Qt, I would recommend Boost library for it is the first library that I would use in C++ when necessary.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I am trying to write a program which I want to run just before booting up the system like the Setup program of Windows XP. The problem is that I cannot figure out which version of C/C++ programming language should be use. Because as far as I know about the many versions of C language they only works in DOS, Windows and Linux. Or is there any way to write the program in the Visual C++ or Turbo C that can run without any OS.
My next question is that which Graphics library can be use in that C language to create and display Images and Shapes on screen, Setting Background color etc.
I read an article on Windows in Wikipedia and I found that it is written on C++. So I thought that I can also write similar type of program in C++ without switching to Assembly language.
You want to write a program that runs directly off boot, with no OS loaded? Sorry, but if you need to ask which language to use, you have a learning curve ahead of you that's so steep that you ought to consider lowering your ambitions considerably for a first effort.
In the bad old days when space was at a premium, bootloaders were written in raw assembler. Today most of the functionality is written in C (or perhaps C++), but one still needs to go to assembler for the very earliest stages that take over from the BIOS, loads more code from disk than the single sector BIOS gives you, and puts the processor into protected mode so it can access more than 1 MB of RAM.
The choice between C and C++ is mostly up to preferences. C++ tends to require a somewhat more complex assembly intro in order to set up its run-time environment as the compiled code expects to find it. In either case, you won't have much in the way of standard libraries available. No malloc/free/new/delete unless you implement them yourself, for example.
No matter what the language, you will need to customize the linking phase much beyond what an off-the-shelf compiler toolchain will do for you with a simple command.
If you're using an x86 machine, you are going to have to learn how to work with either the default VGA buffer, or possibly VBE mode buffer if you want higher-resolution graphics. Most of this will have to be setup through calling BIOS interrupts or using MMIO ports dedicated to controlling the VGA buffer. In either case, this is going to have to be a mixture of assembly and C ... you can't really take advantage of C++ in this instance, since you will not have the use of a OS runtime that typically provides support for many C++-specific language features like exceptions, etc. If you want those types of features, you're going to have to setup the runtime yourself.
Here is a great site for information on the VGA registers that can be accessed through x86 MMIO: http://www.osdever.net/FreeVGA/home.htm
C/C++ does not matter as each system will compile it into the correct machine code for that machine. I can't remember the exact steps, but you're definitely going to have to mess around with copying your code into boot sector, etc.
You will inevitably have to write a little assembly language to be able to write something which boots before the OS. You'll have to write a boot-loader for one thing.
As to a graphics library, you will pretty much have to roll your own if you want graphics, because most libraries use at least some capabilities of an underlying operating system, no mater how cross-platform they are. You'll notice, for example, that the Windows setup program is all text until it boots into the Windows that's being set up for the first time.
As you mentioned yourself, you need to write a boot loader and that is, after compiling your boot loader you have to install it somehow (I'm not so sure about this part), but that usually involves copying it to a certain location of your hard disk, referenced by the master boot record.
As for graphics (or better say graphics card), as well as any other device that you want to interact with at boot time, you simply need to load their driver. So, in principle, your boot loader starts running, loads a bigger portion of itself into memory and once that is done, it start loading the drivers and starts working (similar to how an operation system boots, but much much simpler). The drivers are usually very limited but very generic drivers that you either have to write yourself or find on the internet.