hi all,
I was trying to write a A/D driver to test my s3c44b0,but what I got from the
result.
here is my result:
===
wait for read:
adc_data_ret:495
adc_data_ret:511
adc_data_ret:512
adc_data_ret:511
adc_data_ret:512
adc_data_ret:528
adc_
On Friday 27 February 2009 20:18:10 Jan Ringoš wrote:
> From: "Lennart Sorensen"
>
> > On Fri, Feb 27, 2009 at 05:57:28AM +0100, Jan Ringo? wrote:
> >> Well, I am interested in uClinux only, in this case. I still don't see
> >> the difference. If all the processes live in the same address space
>
On Friday 27 February 2009 20:01:18 Jan Ringoš wrote:
> > From: "Mike Frysinger"
> > > > You could create a server process that accesses the database, and
> > > > smaller
> > > > client processes that talk
> > > > to it (via sockets, files, pipes, or one of the standard shared
> > > > memory inter
On Friday 27 February 2009 15:16:45 Lennart Sorensen wrote:
> On Fri, Feb 27, 2009 at 11:17:19AM -0500, Mike Frysinger wrote:
> > file descriptors are not shared resources. whatever a child does with
> > them will not affect the parent.
>
> I was hoping that was the case. It did seem like vfork +
From: "Lennart Sorensen"
On Fri, Feb 27, 2009 at 05:57:28AM +0100, Jan Ringo? wrote:
Well, I am interested in uClinux only, in this case. I still don't see
the difference. If all the processes live in the same address space here,
and when I create a thread (pthread_create) I see a new duplicate
From: "Mike Frysinger"
> > You could create a server process that accesses the database, and
> > smaller
> > client processes that talk
> > to it (via sockets, files, pipes, or one of the standard shared memory
> > interfaces).
>
> I think I can use the pipes (with their atomic writes) to get rid
Hi Lennart,
Lennart Sorensen wrote:
On Fri, Feb 27, 2009 at 11:57:47PM +1000, Greg Ungerer wrote:
As a data point I regularly use a gcc-4.2.4 with binutils 2.18 for
m68knommu development, and that works fine. I haven't tried a gcc-4.3
yet.
gcc-4.3 is the one that changed the ABI of course.
On Fri, Feb 27, 2009 at 11:17:19AM -0500, Mike Frysinger wrote:
> file descriptors are not shared resources. whatever a child does with them
> will not affect the parent.
I was hoping that was the case. It did seem like vfork + exac would
loose a lot of purpose if file descriptors weren't dupli
On Fri, Feb 27, 2009 at 11:57:47PM +1000, Greg Ungerer wrote:
> As a data point I regularly use a gcc-4.2.4 with binutils 2.18 for
> m68knommu development, and that works fine. I haven't tried a gcc-4.3
> yet.
gcc-4.3 is the one that changed the ABI of course.
For some reason my first attempt at
On Friday 27 February 2009 09:00:11 Lennart Sorensen wrote:
> On Fri, Feb 27, 2009 at 04:02:23PM +1300, Gavin Lambert wrote:
> > With vfork (and unlike fork) the address spaces of the two processes are
> > exactly identical -- changing a value in one process will change the
> > value in the other p
That fixed the problem.
Thank You very much for everyone's assistance.
John Moore
The Morey Corporation
100 Morey Drive
Woodridge, IL 60517-8135
Office Phone: (630) 754-2305
Email: jmo...@moreycorp.com
Greg Ungerer
Sent by: uclinux-dev-boun...@uclinux.org
02/27/2009 07:49 AM
Please respond
On Wed, Feb 25, 2009 at 05:05:06PM -0600, John B Moore wrote:
> I am working with a device which uses an M523x coldfire running
> uClinux-dist-20080808 with the 20090112 patch applied as well (kernel
> 2.6.26-uc0). I am using uClibc 9.30 and the compiler is gcc 4.2.3 uclinux
> cross compiler. I
On Fri, Feb 27, 2009 at 05:57:28AM +0100, Jan Ringo? wrote:
> Well, I am interested in uClinux only, in this case. I still don't see
> the difference. If all the processes live in the same address space here,
> and when I create a thread (pthread_create) I see a new duplicate process
> through p
On Fri, Feb 27, 2009 at 04:02:23PM +1300, Gavin Lambert wrote:
> With vfork (and unlike fork) the address spaces of the two processes are
> exactly identical -- changing a value in one
> process will change the value in the other process as well, which is why the
> parent process is halted while
Hi Lennart,
Lennart Sorensen wrote:
I have tried for quite a number of days (or maybe a couple of weeks now)
to get a working m68knommu setup with something resembling current code.
I have managed to take the build-uclinux-tools.sh along with the versions
of software it wants and get a working
Hi John,
John B Moore wrote:
I am setting the CONFIG_BOOTPARAM_STRING to the boot parameters as follows:
init=/bin/init console=/dev/ttyS1,115200 rootfstype=romfs
^
No "/dev/" in the console arg, just "ttyS1,115200".
Regards
Greg
After startup, using klogd a
Hi,
I'm using uClinux with Nios2. At the beginning of development I wanted to
use process in my project, but it didn't work well I had lot of problems
with inter-process protection.
So then I chose have a single user precess and use threads. I'm having great
performance.
I use pthread.h lib, that p
See:
"Linux System Programming" by Robert Love (O'REILLY)
-Michael
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http:
9) Or is my approach of multiple processes otherwise flawed?
In Linux the communication between processes is really fast, cheap, easy
and versatile.
You can e.g. use pipes/queues (e.g. named pipes in the file system or
system 5 message queues).
In many cases you don't need threads to wait
On Fri, Feb 27, 2009 at 10:20, Michael Schnell wrote:
>> 1) If properly synchronized I can access data of other processes.
>
> You should not do this. As hardware price goes down and speed goes up, more
> and more systems will e equipped with an MMU. So to provide portability, you
> always should
1) If properly synchronized I can access data of other processes.
You should not do this. As hardware price goes down and speed goes up,
more and more systems will e equipped with an MMU. So to provide
portability, you always should do your software so that it will run on
"full" (MMU-enabled
With vfork (and unlike fork) the address spaces of the two processes are
exactly identical -- changing a value in one
process will change the value in the other process as well, which is why the
parent process is halted while the child is
running, to avoid corrupting the stack.
For the rec
3) There is no practical distinction between process and thread in
uClinux as there is in Windows world.
AFAIK:
Depending on the Arch there are "Linux Threads" or "Native Posix
Threads". The appropriate type of threads will be created automatically
by the pthread library on the same function
4) Can pthread mutexes be used across vfork/exec sub-processes?
In documentation to pthreads they say that the pthread_mutex can be
used to synchronize threads but not processes. But I see no difference
between thread and process in uClinux. What am I missing?
To do threads you should use the
2.6 has a large number of very good reasons to use it, but it does
seem to have regressed w.r.t. fragmentation avoidance on no-MMU, which
might be a showstopper.
Bad news :(
Would just providing enough RAM help in those cases, or will same be
eaten up by fragmentation nonetheless ?
-Micha
25 matches
Mail list logo
