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.
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'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.
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 4 years ago.
Improve this question
I see on quite a few job descriptions for embedded developer positions, that a requirement would be for example to have knowledge of embedded C programming on ARM microcontrollers.
What's not very clear to me is , what is the difference between having knowledge of developing C for a particular ARM processor, or developing C for a PowerPC or other type of processor. Developing with C we are abstracted from the actual instructions which will get compiled and the architecture so why does it really matter?
I would guess that it is important mainly to have knowledge of embedded development, knowing memory constraints etc. and that the actual target processor wouldn't matter too much. For example, won't a developer who was writing code for PowerPC MCUs for many years be just as good as developing code for an ARM-based or other type of MCU?
Perhaps i'm missing something obvious here. Please could someone give an example of what could be some major differences between writing C/C++ code for one type of processor and another type. Thanks
All you write about Linux and kernels, but 99% of the embedded work is purely bare metal. therefore, the knowledge of the core and peripherals is essencial.
In the most cases, before Linux programmers learn how to program the bare metal, they are way useless.
And this time needed costs your employer money.
As usual, it depends.
If you are going to develop at a deep C level, it is a good idea to know about the architecture, in order to optimize your code according to speed or/and memory (data bus size, instructions per clock, etc).
It is a must if you are going to develop at a deeper level (and if we are talking about ARM and its thumb, thumb2 and ARM... It is madness).
Furthermore, each architecture because of legacy reasons or to make our life better, adds some tricks. For instance, ARM PC points to the instruction after the next one to be executed, which is quite different in PowerPC or RH850 or whatever.
Above that (I mean, above or close to an OS), the compiler uses to be better than us, but anyway, it is a nice to know how it is working (and definitely it will make the debugging easier)
The answer is yes and no.
If a job is more of application related then MCU specific knowledge will be of little help
If the software development is at kernel/BSP/drivers or hardware related then the knowledge of MCU/CPU hardware is critical.
Please check the Job Description in details to know the kind of work expected.
Well, I haven't written any ARM code myself, but I would think the ARM-specific experience would be (in no particular order):
Experience with ARM-specific toolchains (particularly non-standard parts of that toolchain, pieces of proprietary software etc)
Knowledge of which relevant libraries are available on ARM rather than on Intel machines, and whether their ARM version is performant enough, stable enough etc.
Knowledge of how certain coding patterns look like when compiled to ARM machine code, and consequently, good discretion regarding certain choices regarding low-level implementation.
Ability to write inline ARM assembly when and if necessary
Knowledge of ARM systems' cache layout
Ability to estimate/forecast the power economy of code rather than its mere performance (as ARM processors are sometimes more concerned with that).
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 5 years ago.
Improve this question
I know that win32 API is written in C language and also why Qt is portable?
Could someone explain this to me?
Because WinAPI was not designed to be portable as it targets only the Windows OS while the QT framework targets multiple OS-es. The fact that WinAPI was written in C does not make a difference.
The windows API is portable in the sense of being processor agnostic (indeed, it has run on many non-Intel processors over the years). It is not portable in the sense of being OS agnostic; although even there Microsoft's is not the only implementation of the API. The wine project has done a credible job of re-implementing the API for other platforms, to the point that windows binaries will run, at least on processors that match the binary.
The fact that the WinAPI is aimed at C makes no difference.
Just because the language is cross platform it does not mean the library (especially in the case of those like WinAPI which are not in the standard library) are the same.
It's just a library that interacts with the video card/processor to make a GUI on a very low level. At this point it is so low level the process depends more on memory locations or processor specific operations. IE saying that certain memory locations (specific to the OS) will reference a pixel on a screen ect.
The Win32API has been built so that it only "knows" the tasks for computers with Windows OS, libraries like QT, once again are still not truly "cross-platform" they have just been built to include all the relevant operations needed for each OS it covers.
Why is a rather open question; but here's my take on it:
Win32 API is produced by microsoft; which has commercial reasons for not being portable.
QT is open source; which was created with the sole intention to be portable.
Bonus:
X11 is open source; which was created with the idea that the machine displaying the images might not be the machine running the program that wants the window. Which makes it inherently non-portable to other APIs that don't (eg windows)
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 7 years ago.
Improve this question
Given that Java is highly portable and it is not having serious overheads, can't C++ be made platform independent?
Yes, it is perfectly possible. For example, you can compile C++ to JavaScript ( see https://softwareengineering.stackexchange.com/questions/197940/how-to-run-c-code-in-browser-using-asm-js ) or to CLI byte code ( https://en.wikipedia.org/wiki/C%2B%2B/CLI ) to run on Windows or Linux, or various other targets.
None of these currently performs as well as native C++, and most lack direct access to operating system resources. So the portability comes at some cost, and usually if you wanted to pay the cost of targeting web browsers or CLI, you have languages better suited to those platforms.
In reality, the method of code execution (whether the code is compiled, interpreted, run by VM, etc) is more a property of the implementation, and not the language.
when people say C++ is a compiled language and that JavaScript is an interpreted language, that does not necessarily mean that you can't write a compiler that translates JavaScript code to machine code on your hardware of choice, but rather what is a common way to provide implementation for said language.
In practice, C++ is used because of its efficiency and close to the metal features that is a good choice for performance critical tasks like embedded systems programming, systems programming, graphics, etc, so getting C++ to run in a VM would defeat its purpose.
kinda like buying a fillet Mignon and cooking it in the microwave.
Java compiles to an intermediate platform-independent byte code that is then interpreted at runtime by platform-specific JVMs. That is what allows Java to be portable. Each type of JVM is tailored to run the byte code on the platform's particular hardware architecture.
C/C++ compiles to native machine code that runs directly on the CPU (or as directly as the OS will allow). So no, you cannot compile C/C++ in a platform-independent manner. You have to use platform-specific compilers to compile C/C++ code for each hardware architecture that you want to run your code on.
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.