ts-7000
[Top] [All Lists]

[ts-7000] Re: Reading GPIO ports

To:
Subject: [ts-7000] Re: Reading GPIO ports
From: "Guillermo Prandi" <>
Date: Mon, 24 Jul 2006 12:36:27 -0000
Jim, you are mixing the two problems. The compiler optimization 
problem and the kernel caching problem. Let's separate them to help 
you understand:

1) Compiler problem:

In the code you presented, the compiler will generate good machine 
code. The problem would show up if you DON'T declare the pointers as 
volatile and use the code more than once, like in a loop:

unsigned char *adc_io_stat;
<...>
do {
s=*adc_io_stat & 0x80;
} while( !s );





--- In  Jim Jackson <> wrote:
>
> 
> 
> [re-ordered to remove the top posting]
> 
> On Sun, 23 Jul 2006, Guillermo Prandi wrote:
> > > On Sun, 23 Jul 2006, Guillermo Prandi wrote:
> > > > If you omit the O_SYNC keyword,
> > > > the system would map a *buffer* to the /dev/mem file rather 
than to
> > > > the actual memory (you could flush the buffers using the 
fcntl system
> > > > call, but that just would be unpractical). The /dev/mem driver
> > > > interprets the O_SYNC flag and makes use of the virtual 
memory mapper
> > > > to map real memory locations into the user's virtual memory 
ranges.
> > >
> > > All well and good, but why have I and others not found the 
caching
> > > problem? Admittedly I've only used a TS7200, and I'm using an 
early
> > > Technologics kernel.
> > >
> > The problem would not show up if your program reads or writes and
> > then exits (like to be used from a shell script); in such case 
cache
> > wouldn't apply (buffers are flushed on file close, i.e., on 
process
> > exit). The problem would only be noticed if reads/writes are 
repeated
> > within the same process, and before any automatic buffer flush
> > happens (because the kernel typically flushes the file buffers 
every
> > now and then).
> 
> OK I'm genuinely trying to understand what you are saying here, so 
i'm
> going to run thru' this stage by stage - because I'm not convinced.
> I don't understand where your claimed "buffering" comes in,
> /dev/mem is not a block device, we are not using read/write system 
calls
> to read this file.
> 
> Let's look at some code......
> 
>   volatile unsigned char *adc_io_cntl;
>   volatile unsigned char *adc_io_stat;
>   volatile unsigned char *adc_io_read;
>   int iofd;
> 
>       iofd=open("/dev/mem", O_RDWR);
> 
>       adc_io_stat=(unsigned char *)mmap(0,getpagesize(),
>                    PROT_READ|PROT_WRITE, 
MAP_SHARED,iofd,0x10800000);
> 
>       s=*adc_io_stat & 0x80;
> 
> Are you saying that this pointer dereference doesn't generate the 
correct
> code to cause the hardware to read the relevant byte from the 
correct
> memory location, that we are somehow reading a buffered copy of 
"memory"
> instead of the real thing? And that somehow if we add O_SYNC to the 
open
> then we read the real memory?
> 
> Jim
>






------------------------ Yahoo! Groups Sponsor --------------------~--> 
See what's inside the new Yahoo! Groups email.
http://us.click.yahoo.com/2pRQfA/bOaOAA/yQLSAA/CFFolB/TM
--------------------------------------------------------------------~-> 

 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/ts-7000/

<*> To unsubscribe from this group, send an email to:
    

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 



<Prev in Thread] Current Thread [Next in Thread>
Admin

Disclaimer: Neither Andrew Taylor nor the University of NSW School of Computer and Engineering take any responsibility for the contents of this archive. It is purely a compilation of material sent by many people to the birding-aus mailing list. It has not been checked for accuracy nor its content verified in any way. If you wish to get material removed from the archive or have other queries about the archive e-mail Andrew Taylor at this address: andrewt@cse.unsw.EDU.AU