How to read and write value in two different systems?

As already said in the other thread, I don't suppose it's a good idea to access anything (in fact especially memory) from both CPUs via the same Avalon bus.

Moreover I don't think it's a good idea to (in Linux) access anything from userland software using the "0x80000000 + hardware_address". There are decent (portable) means provided to do this (e.g. using "uio" from user land or better doing a decent Kernel driver) and using the correct (portable) macros provided to avoid caching.

But of course for testing purpose you can happily ignore these suggestions.

You do know that (only with a non-MMU-NIOS2-system) setting bit 31 means "don't cache" ?!?!?!?

Thus in your test you might try to use the "0x80000000 + hardware_address" notation with your second CPU as well, if same is a NIOS2 without MMU and with data-Cache.

-Michael

<div class='quotetop'>QUOTE (mschnell @ Aug 11 2009, 01:36 AM) <{post_snapback}> (index.php?act=findpost&pid=23473)</div>

--- Quote Start ---

As already said in the other thread, I don&#39;t suppose it&#39;s a good idea to access anything (in fact especially memory) from both CPUs via the same Avalon bus.

Moreover I don&#39;t think it&#39;s a good idea to (in Linux) access anything from userland software using the "0x80000000 + hardware_address". There are decent (portable) means provided to do this (e.g. using "uio" from user land or better doing a decent Kernel driver) and using the correct (portable) macros provided to avoid caching.

But of course for testing purpose you can happily ignore these suggestions.

You do know that (only with a non-MMU-NIOS2-system) setting bit 31 means "don&#39;t cache" ?!?!?!?

Thus in your test you might try to use the "0x80000000 + hardware_address" notation with your second CPU as well, if same is a NIOS2 without MMU and with data-Cache.

-Michael[/b]

--- Quote End ---

Thank you for your reply.

It&#39;s staying at a primary stage, so the simple thing is only for testing.

I have tried the "0x80000000 + hardware_address" in NIOSII IDE program, but the result is always -1.

I suppose whether the reason lies in the led hardware.

led light doesn&#39;t store value, once it lights on, the value disappears.

Or another reason may be using the led_red[17..0] is out of the variable range.

And I have found a reference in nioswiki:

http://nioswiki.com/accessing_hardware_reg..._space_programs (http://nioswiki.com/accessing_hardware_registers_from_user_space_programs)

Will it help?I am quite new to it, hoping to hear from your instruction.

There are many ways to do a more portable hardware access. mmap is one of them. Others are a dedicated Kernel driver that more specifically handles the hardware in question and the "uio" stuff that does not seem use specific Kernel code.

Of course it might be that the "LED" "hardware" port does not provide read access to the latches holding the state of the LEDs. IMHO that would be quite unusual. You should check the appropriate HDL implementation and maybe upgrade it.

-Michael

<div class='quotetop'>QUOTE </div>

--- Quote Start ---

There are many ways to do a more portable hardware access. mmap is one of them. Others are a dedicated Kernel driver that more specifically handles the hardware in question and the "uio" stuff that does not seem use specific Kernel code.[/b]

--- Quote End ---

I have checked many references. Some mentioned the idea of mailbox, which I think is very convenient.

Does it need to add an driver for uclinux to own the access to mailbox. Or any other ideas?

I will gather more information about mmap and uio, coz they are quite new to me.

<div class='quotetop'>QUOTE </div>

--- Quote Start ---

Of course it might be that the "LED" "hardware" port does not provide read access to the latches holding the state of the LEDs. IMHO that would be quite unusual. You should check the appropriate HDL implementation and maybe upgrade it.[/b]

--- Quote End ---

Thanks to your instructions. I have tried the sram, the read and write function runs well.

The problem may be the specific characteristic of LED hardware.

<div class='quotetop'>QUOTE (babysnow @ Aug 11 2009, 11:20 AM) <{post_snapback}> (index.php?act=findpost&pid=23477)</div>

--- Quote Start ---

I have checked many references. Some mentioned the idea of mailbox, which I think is very convenient.[/b]

--- Quote End ---

Ooops Mailboxes are a means to communicate between two CPUs, not between a Linux userland process and some hardware device. Of course a mailbox is a hardware device (i.e. a one stage FIFO, a multi-stage FIFO will provide more performance, if needed), so the Linux system needs a dedicated device driver (or something else) to decently access same from userland.

<div class='quotetop'>QUOTE (babysnow @ Aug 11 2009, 11:20 AM) <{post_snapback}> (index.php?act=findpost&pid=23477)</div>

--- Quote Start ---

I have tried the sram, the read and write function runs well.

The problem may be the specific characteristic of LED hardware.[/b]

--- Quote End ---

So the "LED" hardware really does not provide read access to the latch.

-Michael

The ultimate purpose of doing so is to commucnicate between the uclinux and program.

The user land process may be a destination, and the hardware device may be an transimittion, not the purpose.

Which means I only wanna create a communication byte between them, also to prevent accessing simultaneously.

Also , I wanna create a share memory between them. But that may be the next step.

<div class='quotetop'>QUOTE (babysnow @ Aug 11 2009, 11:54 AM) <{post_snapback}> (index.php?act=findpost&pid=23479)</div>

--- Quote Start ---

Also , I wanna create a share memory between them. But that may be the next step.[/b]

--- Quote End ---

Not a good idea IMHO. A FIFO will be much less problematic and supposedly offer not much less performance. Maybe even more performance, as a shared memory - unless it&#39;s a dual ported design - needs to do hardware access control with any read and write cycle.

-Michael

<div class='quotetop'>QUOTE (mschnell @ Aug 11 2009, 06:45 AM) <{post_snapback}> (index.php?act=findpost&pid=23480)</div>

--- Quote Start ---

<div class='quotetop'>QUOTE (babysnow @ Aug 11 2009, 11:54 AM) <{post_snapback}> (index.php?act=findpost&pid=23479)

--- Quote End ---

--- Quote Start ---

Also , I wanna create a share memory between them. But that may be the next step.[/b]

--- Quote End ---

Not a good idea IMHO. A FIFO will be much less problematic and supposedly offer not much less performance. Maybe even more performance, as a shared memory - unless it&#39;s a dual ported design - needs to do hardware access control with any read and write cycle.

-Michael

[/b]

--- Quote End ---

The shared memory is a intermediate medium ,which is used to sent messages between them.

My thought is to create a mailbox, will that be much more trouble?

If so, can you give much more details or useful reference about FIFO. Thank you very much.

Of course, shared memory, accompanied by a hardware Mutex, is a perfectly legal design. It can be done as (1) a real dual ported RAM, accessible simultaneously by both CPUs or (2) simply by using the Avalon bus to handle mutual accesses. (2) might slow down both systems, as any access to the RAM needs to wait until an access from the other CPU is over. This is especially bad if that RAM is not dedicated to the inter-CPU communication but holds other data or even code, as well.

Regarding designing a FiFo by means of an FPAG, I suppose there is lots of literature in the Internet.

Here supposedly a pair of FiFos, one in either direction, is the most useful design.

Each CPU sees it&#39;s own read port (reading the incoming FiFo), write port (writing the outgoing FiFo) and flag port. The flags being (e.g.) "outgoing FiFo full" and "incoming FiFo empty". A "clear outgoing FiFo" command port might be useful, too. (See the datasheet of some hardware FiFo.)

Additionally, for speed, it might be useful to have the FiFos create interrupts towards the appropriate CPU, if the incoming FiFo gets "not empty" and/or if the outgoing FiFo gets "not full" (or e.g. "not half full").

The CPU interface might be similar to a hardware UART with a built-in FiFo (e.g. 16550).

-Michael

Thank you for your instruction.

Maybe I could use a more mediate way.

the onchip memory (32 bit ) stores the flag,

and the sram( 512kb ) stores the data wanna be communicated.

onchip memory&#39;s accessibility is arbitrated by avalon bridge.

sram&#39;s accessibility is arbitrated by flag status.

What about this idea?

By the way,is there anything do with the cache? Should I notice the effect of cache flushing?