Re: Embedded software interview question collection
- From: David Brown <david@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Fri, 15 Sep 2006 10:03:04 +0200
Stef wrote:
In comp.arch.embedded,
David Brown <david@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
Stef wrote:True, and this could be catagorized as DMA. The peripheral directlyIn comp.arch.embedded,In embedded programming, the biggest use of non-cache access (and of volatile access) is for accessing memory mapped peripherals.
Peter <meltyb@xxxxxxxxxxx> wrote:
"Michael N. Moran" <mike@xxxxxxxxxxx> wrote in message news:2CRNg.59500$e9.5509@xxxxxxxxxxxxxxxxxxxxxxxxxAnd how would the compiler do this? Will it insert a complete cacheJulian Gardner wrote:volatile on a variable stops a compiler from doing optimisations like caching. This is useful if there is more than one thread using the variable because the actual variable and a cached copy would not match.Well ive been arguing with a company because they cant get to grips what volatile really does and because of this the new piece of hardware they have released witb an embedded processor does not work if the cache is switched on!!!!Off topic, but ... maybe it's because my brain hasn't clicked on yet,
I have tried for 2 years to get them to understand but they still screw the design up.
I now need to got through all my code and try to move every variable into a seperate block of memory so there will be no memory corruption.
but what has the use of volatile got to do with cache?
flushing sequence after the variable update?
On the other hand, if you only worry about different threads, you do not need to worry about the cache. All threads run on the same CPU (multi
core excluded here ;-) and will therefore use the same cached value, no
problem.
You only need to worry about the cache if there is some kind of DMA at
work. You might also run into problems with self modifying code using
separate data and instruction caches.
Use volatile for variables that get updated outside the normal execution
flow (from an interupt or from another thread). This prevents the compiler
from re-using a value read into a register, but this has nothing to do
with caches.
modifies the memory mapped registers.
That strikes me as a strange way to view it, but I suppose it depends on where you are coming from - for my type of programming, caches and DMA are very high-end features, while memory-mapped peripherals are accessed continuously.
Sometimes it is possible for the processor to choose to avoid the cache - the Nios soft processor from Altera uses the highest address bit to indicate a non-cache access, and thus "volatile" avoids the cache. However, that's an unusual case. The most common volatile/cache problem is the misunderstanding that some people have when they believe that "volatile" accesses avoid the cache.
I was not aware of such a processor. My only hands-on experience with
caches is on the AT91RM9200 (ARM 920T). On this one you can tell the MMU which areas to cache and which not. As I understand it, this is far
more common the your Nios example. Volatile has no effect on the cache,
but is needed in addition to turning the cache off for the I/O areas.
That's a much more common arrangement (and you can configure cache areas on the Nios too) - I was just using it as an example.
Also got bitten by the cache when using a serial driver that uses the
PDC (sort of DMA on AT91 devices). I had to use an uncached area of
memory for the PDC buffers to get it working.
Yes, DMA and caches are fun. Live is a lot easier when your cpu clock speeds match your memory speeds and you don't have to bother with caches.
.
- Follow-Ups:
- References:
- Embedded software interview question collection
- From: dreamguy007
- Re: Embedded software interview question collection
- From: Yuriy K.
- Re: Embedded software interview question collection
- From: Julian Gardner
- Re: Embedded software interview question collection
- From: Michael N. Moran
- Re: Embedded software interview question collection
- From: Peter
- Re: Embedded software interview question collection
- From: Stef
- Re: Embedded software interview question collection
- From: David Brown
- Re: Embedded software interview question collection
- From: Stef
- Embedded software interview question collection
- Prev by Date: Re: difference between SMP and non-SMP
- Next by Date: Decoding CAN messages
- Previous by thread: Re: Embedded software interview question collection
- Next by thread: Re: Embedded software interview question collection
- Index(es):
Relevant Pages
|