Honored Contributor
Honored Contributor<div class='quotetop'>QUOTE </div>
--- Quote Start --- but you do need a hardware Mutex to allow the processors to be sure which one is allowed to write to critical memory locations e.g. to create a Mailbox mechanism: a CPU sets a bit to say: "mailbox contains data", the other CPU clears the bit to say: "data read and can be replaced" by new data.[/b] --- Quote End --- What is the exact meaning of CPU bit? <div class='quotetop'>QUOTE </div> --- Quote Start --- These operations need to be protected against each other. Altead SOPC-Builder does provide a Mutex on the Avalon bus for that purpose. I suppose it can issue an interrupt so that one CPU can notify the other of changes of the mailbox state.[/b] --- Quote End --- The mutex on the Avalon bus is automatically generated, isn't it? Which means although I cannot visually see it ,but the Avalon bus has its own arbitration, to prevent the conflict? I have already tested an idea. cpu_1 in charges of Program which stores in sdram ( reset addr 2) cpu_0 in charges of Uclinux which stores in sdram (reset addr 1) put the flag (or called it a status 32-bit storage ) in a on-chip memory (NO_DATA,DATA_IN,DATA_OUT) put the shared memory,which is used to store message, in a sram Program keep checking the status( on-chip mem ) ( I have already put a delay() function into it ) Uclinux writes a message onto shared memory and changes the flag, once program realize while checking, it will receive message from sram. However, when running the two processor simultaneously, cpu_1 keeps checking, cpu_0 runs uclinux, sometimes one or both of them go to dead. I don't know the reason why. Is it because they are using the same sdram for running?
