avalon_spi RX data and onboard memory

--- Quote Start ---

I built it from examples that i saw. there are hooks from the spi to the onboard memory, so i assume that the spi reads will go into memory somewhere.

--- Quote End ---

If you provide a link or attach the example(s), someone will be able to comment/explain on what that example is doing. But the Altera SPI core does not by itself implement any access to memory. It relies on either your software or a DMA controller to perform those transfers from it's peripheral registers.

--- Quote Start ---

My question is how do i know what addresses the spi uses in the onboard memory to store rxdata? And, how do i guarantee that successive spi write of 2 bytes dont just keep overwriting each other, but instead, get their own spot in memory?

--- Quote End ---

Unless you're trying to do something more sophisticated from the example your following, managing the storage of the SPI data is up to your software program: you just need to allocate/reserve a block of memory and place the samples there yourself.

Hi Ted

So using something like IOWR_8DIRECT in my nios code will provide fast access to the memory?

Also, for allocating memory, would i use alt_uncached_malloc() ?

Sorry if these are simple questions... im brand new

thanks!

IOWR_8DIRECT() and alt_uncached_malloc() are ways to make sure your NIOS cache doesn't get in the way of accessing either the peripheral or the memory you hope to come in and access independently from System Console.

They aren't necessarily "fast" but they are direct.

"Fast" would be executing your loop 100 times and then flushing the data cache when you were done, so that the System Console could pick up the results. Note that all of this is assuming you're using a NIOS with a cache enabled.

There are lots of different ways of accomplishing the same task.

One thing I would recommend is simply adding a second "mailbox" On-Chip RAM memory that is dedicated to holding your sample data and possibly has a software semaphore to share with the System Console. i.e. system console TCL will command the NIOS to execute, the NIOS fills the sample buffer and indicates completion back to the system console. If you add a second memory, you would just use it's# define base address from "system.h" directly, and you would not use any malloc for it. This has the benefit that the buffer pointers remain fixed so system console TCL side always knows where to go.

Your NIOS side could look approximately like this:

# define MY_COMMAND_WORD (FOO_RAM_BASE + 0x00)
# define MY_SAMPLE_BUFFER  (FOO_RAM_BASE + 0x20)
while( IORD_32DIRECT(MY_COMMAND_WORD) != go_magic_value ) { /* waiting... */ };
unsigned short *ptr = MY_SAMPLE_BUFFER;
for(i=0; i < 100; i++) { *ptr++ = go_do_spi_read_of_two_bytes(); }
alt_dcache_flush();
IOWR_32DIRECT(MY_COMMAND_WORD, nios_is_done_magic_value);

Hi Ted

So i follow most of that... but what does alt_dcache_flush() do? how does it know to only wipe out the portion of memory related to the spi read? or, would i use alt_dcache_flush(MY_SAMPLE_BUFFER, 100)?

thanks for all your help!!