Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Altera_Forum
Honored Contributor I
1,011 Views

avalon_spi RX data and onboard memory

Hi guys 

 

I am new, but have created a simple nios ii hello world that will interface with my DUT using the avalon_spi_command routine. The DUT is somewhat unique in that i have to send it 4 bytes of data to command it, and then send another 2 bytes to receive its 2 byte response. The code works well and im able to see the rxdata in eclipse is exactly what i expect.  

 

I built the fpga code with qsys and have a nios ii, spi core, onboard memory and jtag uart. 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. 

 

When im running this to capture real data, i will have hundreds of spi reads, each 2 bytes wide.  

 

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? 

 

I will then use system console to read back all spi rx data to a file 

 

thanks!
0 Kudos
5 Replies
Altera_Forum
Honored Contributor I
46 Views

 

--- 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.
Altera_Forum
Honored Contributor I
46 Views

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!
Altera_Forum
Honored Contributor I
46 Views

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);
Altera_Forum
Honored Contributor I
46 Views

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!!
Altera_Forum
Honored Contributor I
46 Views

Sorry, yes you would want to invoke it correctly with an address and length. Your length would be x2 though because you're writing 16-bits.

Reply