Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 1 year ago.
The community reviewed whether to reopen this question 1 year ago and left it closed:
Original close reason(s) were not resolved
Improve this question
I've realized that the 3 ways to make an I/O connection :
1- Programmed I/O (polling)
2- Interrupt-Driven I/O
3- Direct Memory Access (DMA)
now, I need to relate this with the reality of how accessing I/O addresses is done
(Isolated I/O || Memory-mapped I/O) :
DMA
Memory mapping does not affect the direct memory access (DMA) for a device, because, by definition, DMA is a memory-to-device communication method that bypasses the CPU.
this is all information I have.
now, what about Interrupt-driven and Programmed I/O, what is the addressing modes are used in these cases?
Does a microcontroller can do both addressing modes (Isolated/memory-mapped) or only one choice?
Am I understanding the topics right now, or there are any misconceptions?
Port mapped vs memory mapped (Communication)
This is how the IO access is performed, i.e. how the CPU communicates with the device.
With port mapped IO the CPU uses special instructions (e.g. x86's in and out) to read/write from a device in a special IO address space you can't access with load/store instructions.
With memory mapped IO the CPU performs normal memory loads and stores to communicate with a device.
The latter is usually more granular and uniform when it comes to security permissions and code generation.
Polling vs Interrupt driven (Notification)
This is how notifications from the devices are received by the CPU.
With polling the CPU will repeatedly read a status register from the device and check if a completion bit (or equivalent) is set.
With interrupt driven notifications the device will raise an interrupt without the need for the CPU to do any periodic work.
Polling hogs the CPU but has less latency for some workload.
DMA vs non-DMA (Transfer)
This is how the data is transferred from the device to the CPU.
With DMA the device will write directly into memory.
Without DMA the CPU will have to read the data repeatedly (either with port or memory mapped IO).
All these three dimensions are independent of each other, you can combine them however you like (e.g. port mapped, interrupt driven, DMA).
Note, however, that the nomenclature is not consistent in the literature.
Also, different devices have different interfaces that may not need all of the three dimensions (e.g. a very simple output-only GPIO pin may have a single write-only register, so it makes no sense to talk about polling or DMA in this case).
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 1 year ago.
Improve this question
I am trying to learn the basics of DMA. I watched certain videos on YouTube for the same.
I have got a few queries:
Can we set/reset bits of registers using DMA? Like if I want to set the 4th bit of GPIO_ODR, can I do it using DMA?
Does DMA follow polling method or interrupt method?
If incase I want to set and reset bits of the registers of the GPIO (general purpose input-output) peripheral, then what would be the workflow of DMA?
Will it be:
CPU->DMA->Peripheral->Register
and then for reverting back
Register->Peripheral->DMA->CPU
Is this workflow correct?
Please help me with this. Also, it would be great if you explain in simple words because I am completely new to this topic.
Thanks!
-Aditya Ubarhande
Disclaimer: My answer is based on my experience on DMA hardware of STM32 microcontrollers.
If the DMA you're using have access to the memory region where hardware registers reside (like GPIO), then yes, you can move data to these registers and change the bits. But be aware that this doesn't give you bit-wise read-modify-write access. DMA writes (or reads) the memory region (can be 8, 16 or 32 bits etc.) all at once. On STM32, Timer triggered DMA driven GPIO access can be used for synchronous parallel port implementations. On the other hand, DMA is generally used for event triggered bulk memory transfers, so using it for one time manipulation of hardware registers makes little sense.
In general, you arm the DMA and it generates an interrupt when its job is done (or half complete) or when some error occurs. DMA has its own control & status registers, so you can poll them instead of enabling & using interrupts. But most of the time, using interrupts is a better idea. It's also an option (probably a bad one) to fire & forget it, if you don't need to be notified when the transfer is complete.
In general, for any DMA transfer you configure source address, destination address, data length & width and the triggering condition (unless it's a memory-to-memory transfer). Of course, there can be additional settings like enabling interrupts etc.
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 3 years ago.
Improve this question
If the CPU cannot access the bus during DMA transfers so must wait on the bus to be released, how does using DMA provide any performance advantage?
There may be bus contention, but it is still likely to be faster than the alternative which is typically interrupt driven I/O which has a huge software overhead. Typically the DMA transfer will not use the maximum memory bandwidth (except for memory-to-memory transfers perhaps) because peripheral devices tend to be far slower than the memory. The DMA controller will interleave CPU access.
Moreover bus contention is not a given, many microcontrollers segment their memory on separate buses so access by the CPU to memory on one bus can occur concurrently with DMA operations in memory on another. For example Harvard architecture devices have independent buses for code and data memory, so can fetch op-codes and data simultaneously, but the reduced access load on the data memory (because not all instructions require memory operands to be fetched) advantages DMA.
Further, some microcontrollers such as many in the STM32 series (Cortex-M so also Harvard architecture) segment their on-chip SRAM on separate buses (as well as an external memory interface on a separate bus). Typically there will be some segment of SRAM smaller than the other segments - 4K or 16K perhaps - that is ideal for exclusive use for DMA buffering. Using the memory in this way can have a significant impact on performance by avoiding bus contention.
Another feature of some STM32 parts is core coupled memory (CCM) which is not available for DMA or bit-banding, but if used for most CPU data processing, leaves other on-chip SRAM available for DMA further reducing bus contention.
Other microprocessors may have similar memory segmentation. To take advantage of such memory architecture you typically require a custom linker script and possibly linker directives in the code, to allow segments to be identified and objects to be explicitly assigned to them. This will be toolchain specific.
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
In the past few days I found how important is RTOS layer on the top of the embedded hardware.
My question is :
Is there any bifurcation between device driver (written in C directly burned over the microcontroller)
And the Linux Device driver ?
This question is a little broad, but an answer, a little broad itself, can be given.
The broadness comes from the fact that "embedded hardware" is not a precise term. That hardware ranges from 4 bit microcontrollers, or 8 pins ones, up to big CPUs which have many points in common with typical processors used tipically on linux machines (desktop and servers). Linux itself can be tailored up to the point it does not resemble a normal operating system anymore.
Anyway, a few things, generally acceptable, can be the following. Linux is not, in its "plain" version, a real time operating system - with the term RTOS instead, the "real time" part is implied. So, this can be one bifurcation. But the most important thing, I think, is that embedded firmware tries to address the hardware and the task to be done without anything else added. Linux O.S. instead is general purpose - it means that it offers a lot of services and functionalities that, in many cases, are not needed and only give more cost, less performances, more complication.
Often, in a small or medium embedded system, there is not even a "driver": the hardware and the application talk directly to each other. Of course, when the hardware is (more or less) standard (like a USB port, a ethernet controller, a serial port), the programming framework can provide ready-to-use software that sometimes is called "driver" - but very often it is not a driver, but simply a library with a set of functions to initialize the device, and exchange data. The application uses those library routines to directly manage the device. The O.S. layer is not present or, if the programmer wants to use an RTOS, he must check that there are no problems.
A Linux driver is not targeted to the application, but to the kernel. And the application seldom talks to the driver - it uses instead a uniform language (tipically "file system idiom") to talk to the kernel, which in turns calls the driver on behalf of the application.
A simple example I know very well is a serial port. Under Linux you open a file (may be /dev/ttyS0), use some IOCTL and alike to set it up, and then start to read and write to the file. You don't even care that there is a driver in the middle, and the driver was written without knowledge of the application - the driver only interacts with the kernel.
In many embedded cases instead, you set up the serial port writing directly to the hardware registers; you then write two interrupt routines which read and write to the serial port, getting and putting data from/into ram buffers. The application reads and writes data directly to those buffers. Special events (or not so special ones) can be signaled directly from the interrupt handlers to the application. Sometimes I implement the serial protocol (checksum, packets, sequences) directly in the interrupt routine. It is faster, and simpler, and uses less resources. But clearly this piece of software is no more a "driver" in the common sense.
Hope this answer explains at least a part of the whole picture, which is very large.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 7 years ago.
Improve this question
I am running a Linux VM on Windows 7, and experience extreme slowness when using the VM. Is this because of a lack of memory? I thought VM's leveraged primarily compute cores and drive space (HDD/SSD).
I am looking at getting a new Surface device and need to know whether memory is critical to running VMs. Unfortunately VMWare hasn't been very helpful: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1008360. Please advise.
There are four main bottlenecks with respect to VMs in my experience:
CPU
Memory
Disk IO Throughput
Network throughput
CPU
CPUs will be taxed and cause performance issues if your VMs are working constantly at computing. IO (Input/Output) usually doesn't factor into this it is more about computation time on the processor for your applications. You will need more CPU if you are doing tasks like:
computing large numbers
video/photo editing
Video Games
Memory
Memory is a very common bottleneck as each machine will need a set amount to host the OS. Windows usually uses more for this than Linux and the like. Also, If you are running applications which are storing large amounts of data in memory like:
Some Databases
video playback
video/photo editing
Video Games
Disk Throughput
While disk storage space is becoming incredibly cheap, there is still a finite amount of throughput (the amount of data it can send/receive at once) available. You will notice more lag here if you are running a low-RPM disk like a 5200 RPM drive, if you are experiencing lag (especially during boot) your best bang for your buck will usually be in a solid-state hard drive.
Network Throughput
If your VMs are reaching out to the network or handling a lot of network requests (like a server), you may notice some lag, but this will not usually affect the other factors, so your lag would usually be noticed only in page load times. If this is a problem, I have invested in a NIC (Network Interface Card) which has four gigabit network interfaces. This ran me about $250 about a year ago, and it has allowed my servers to keep up with a couple of medium traffic websites. I believe any lag my users experience are usually on my ISPs end (only 25 Mb service is available in my area).
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 7 years ago.
Improve this question
I am running Ubuntu on my physical machine; and VirtualBox to run various virtual ones on top.
Most of the time, I was doing "straight forward" installations; but today I wanted to be "smart" and checked out the partitions that the fedora or ubuntu installers will create on my virtual disks.
And sure, when going for the defaults, some GBs of my virtual disks will be used as "swap space".
Now I am wondering: assuming that I have plenty of physical memory (so I can assign 6 or 8 GB to a VM) - is there any sense in dedicated swap space for a a virtual machine?
This is answered at ServerFault:
TL;DR: use swap: 1. avoids out of memory error, 2. guest OS is better at memory management
Ignoring the fact that people are dealing with OS specific reasons I
have two reasons why it's a bad idea to not run with a swap
partition/file.
If you have 1.5 GB of RAM allocated to a VM with no space file/partition and it wants to use 1.5 GB + 1 MB it will report an out
of memory error. With the swap space it will be able to swap data out
of active memory and onto the disk.
The guest OS does a much better job of memory management than the host. This is why technology like memory ballooning exists because the
Host can make educated guesses on what memory isn't needed right now
but the guest knows at a much more intelligent level (this keeps OS
memory from being swapped out which could kill your performance).
Swap partitions are used to free your physical memory when it goes out of space. In modern day machines, with plenty of memory, it depends on the type of applications you would be running. If you are planning to run such memory intensive programs like video editors, high end games or something of that sort, virtual memory or swap space is an asset. But if it is not the case then you are safe to avoid swap space, provided you have enough memory. But it is safe to have a fallback.
That depends on what programs you are running on your host system along with the virtual machine, or what programs you are running within the virtual machine.
The only upper bound on memory that software can consume is the total memory (physical or virtual) available to it. There are plenty of programs that require large amounts of memory when behaving normally, and plenty of circumstances that cause a program to consume large amounts of memory (e.g. loading of input files). There are also plenty of faulty programs that unintentionally consume large amounts of memory.
You can often get an idea by examining requirements or recommendations (e.g. memory and drive space) of the programs you run. Failing that, try it out.