Char interface for lib_sdram?

Technical questions regarding the XTC tools and programming with XMOS.
Post Reply
User avatar
aneves
Experienced Member
Posts: 93
Joined: Wed Sep 16, 2015 2:38 pm

Char interface for lib_sdram?

Post by aneves »

Hi Guys,

I've been using lib_sdram extensively for quite some time now. I find that the API requiring unsigned int arrays for data transfer to be hard to use in most cases because most of the time my source or sink of data is a char array. I wrote some wrapper functions which wrap sdram_write and sdram_read to provide a char array interface. I don't particularly like it because of the buffer gymnastics that need to take place to convert to/from unsigned int/unsigned char.

Is there anything requiring the API to be unsigned ints? I was looking at the source code and my first instinct was that the majority of the code for reading and writing to/from sdram takes place in assembly and so everything has to be in words. However, the core data transfer code for lib_usb also takes place in assembly and that API provides interfaces for unsigned char arrays for data transfer. I did, however notice this comment in XUD_EpFuncs.S:

Code: Select all

// Note: Assumes startIndex is word aligned
That leads me to believe that the API for lib_usb could have also been written for unsigned ints as well but the xC API implicitly "casts" the data arrays from unsigned chars to unsigned ints when it crosses the xC -> assembly barrier.

I guess the big question I'm asking is, if I were take on an effort to provide a "native" unsigned char interface for sdram_read and sdram_write, would that be feasible? Any impediments to keep in mind?

Thanks.


User avatar
infiniteimprobability
XCore Legend
Posts: 1126
Joined: Thu May 27, 2010 10:08 am
Contact:

Post by infiniteimprobability »

Under the hood lib_sdram always reads and writes long words. The minimum access is 2 x 16b words which take place as a 2 cycle access on a 16b buffered port (32b buffer). This was necessary so that the inner loop can run at half the rate of the SDRAM clock and provide good throughput for longer bursts. So the API reflects that.

Under the hood USB is a byte orientated transport so is different in that respect.

There is nothing to stop you changing the types of the interface but anything less than a 32b type would require careful packing and address translation.
Post Reply