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 5 years ago.
Improve this question
I want to know out of SPI and I2C communication protocol which one
is Faster? I have read in an article that SPI is faster but they
have not given an explanation why? Is it because of less
overhead in SPI when compared to I2C (like start, ack, stop)?
Which one is better out of two? I have seen that for ADC mostly SPI
is preferred, but why? For Flash also I have mostly seen SPI
protocol being used, but for Sensor both SPI and I2C. Now, what makes
as to decide that for one peripheral I should go with SPI and for
another I2C is preferred?
Better question is when I should use I2C and when I should use SPI. Like always in engineering there are different pros and cons in both protocols. I compared them below so you will be able to asses what is better match for your requirements.
Quick comparison of my own:
Additional remarks:
SPI is usually used for slave devices where speed matters e.g. ADC peripherals, FLASH memories etc.
I2C is usually used for slave devices which are fine with I2C speed constrains or which are kind of slow like sensors which can take longer time to get the measure e.g. popular temperature and humidity sensor HTU21-D with I2C performs measure between 3-16 [ms] (this time depends on the selected measurement resolution).
Post explaining I2C Bus Length constrains.
Post explaining why SPI is faster than I2C
PS:
The fastest ADC peripherals are not using either I2C or SPI. They use parallel I/O.
Keep in mind that for simple (hobby) projects it usually doesn’t matter and you will be fine with either of them.
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.
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).
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 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 8 years ago.
Improve this question
Suppose we have a simple processor, could be an embedded system, with one system bus, for the sake of the argument, a 32bit bus.
Now, if we have a couple of Peripherals, one named PER0 for example, attached to the bus, we can do two things:
Allow it to have fixed-width access to the main bus, for example 8 bits, and that way PER0 will always communicate with the bus in 8bit packages. This we can call static-width access.
Allow it to have options to choose how it will communicate with the
bus in terms of size of data by using signals with which it tells
the processor the mode of access it wants to use. For example, we
create two signals, A1 and A0, between the processor and PER0, whose
values will say:
00 - wait
01 - 8bit
10 - 16bit
11 - 32bit
and so the processor will know whether to send 8bit data to its
bus, or 32bit data, based on the values of A1, A0. This we can call
dynamic-width access to the bus.
Question:
In your experience, which of these two methods is preferred, and why? Also, in which cases should this be implemented? And finally, considering embedded systems, which method is more widely spread?
EDIT: I would like to expand on this topic, so I'm not asking for personal preferences, but for further information about these two methods, and their applications in computer systems. Therefore, I believe that this qualifies as a legitimate stackoverflow question.
Thanks!
There are multiple considerations. Naturally, the dynamic-width would allow better utilization of bandwidth in case you have multiple sizes in your transactions. On the other hand, if you transfer some 8 bytes, and then the next 8, you double the overhead compared to the baseline (transferring the full block in one go, assuming you can cache it until it fully consumed). So basically you need to know how well you can tell in advance which chunks you're going to need.
There's an interesting paper about the possibility of using such a dynamic sized transactions between the CPU and the DRAM:
Adaptive granularity memory systems: a tradeoff between storage efficiency and throughput
There you can see the conflict since it's very hard to tell which transactions you'll need in the future and whether bringing only partial data may cause a degradation. They went to the effort of implementing a predictor to try and speculate that. Note that this is applicable to you only if you're dealing with coherent memory.