electro-music.com   Dedicated to experimental electro-acoustic
and electronic music
 
    Front Page  |  Radio
 |  Media  |  Forum  |  Wiki  |  Links
Forum with support of Syndicator RSS
 FAQFAQ   CalendarCalendar   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   LinksLinks
 RegisterRegister   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in  Chat RoomChat Room 
go to the radio page Live at electro-music.com radio 1 Please visit the chat
poster
 Forum index » DIY Hardware and Software » Microcontrollers and Programmable Logic
32 K byte SPI SRAM
Post new topic   Reply to topic Moderators: State Machine
Page 2 of 2 [45 Posts]
View unread posts
View new posts in the last week
Mark the topic unread :: View previous topic :: View next topic
Goto page: Previous 1, 2
Author Message
JovianPyx



Joined: Nov 20, 2007
Posts: 1988
Location: West Red Spot, Jupiter
Audio files: 224

PostPosted: Wed Jan 16, 2013 7:02 pm    Post subject: Reply with quote  Mark this post and the followings unread

yogi wrote:
I haven't dug too deep into your code, mainly because it worked with the '256 and you made adjustments to the adr length. So I'm thinking you could have s slight difference between the two chips. I found a note in the 23xx1024 DS in Fig 3.8 that notes 3 Pin should not be left floating with Non-SQI operations.The text doesn't say a word about that and the pin diag shows it as NC. This is different then on the '256 where Pin 3 is a NC. Don't know if you made this change to you layout and don't know what happens if it IS floating but that's the only diff I can see so far.


Yeah, saw that. I bring pin 3 to Vdd. I read the same "is it is it or is in not is it...". I haven't tried grounding pin 3 yet...

When I did the piggy back, I left the 23K256 pin 3 float. It worked, the 23LC1024 did not. The only thing that was going on was a write to the mode register and a read from the mode register that went "forever". This produces an obvious toggling signal on the 23K256, but not on the 23LC1024. The program sends an 8 bit command (write or read mode register) and 8 bits of data then sends an mode register read command and gets an 8 bit response. The command data is the same for both ICs, so this program should work with both. Having now tried two 23LC1024 ICs, I'm leaning toward "I got bad ICs"... I know how improbable that is...

_________________
FPGA, dsPIC and Fatman Synth Stuff

Time flies like a banana.
Fruit flies when you're having fun.
BTW, Do these genes make my ass look fat?
corruptio optimi pessima
Back to top
View user's profile Send private message Visit poster's website
yogi



Joined: Jun 26, 2008
Posts: 29
Location: Maryland

PostPosted: Wed Jan 16, 2013 7:37 pm    Post subject: Reply with quote  Mark this post and the followings unread

Just went through the 'loop' routine, seems simple enough. During the WRMR sequence, MISO stays HiZ. During the RDMR sequence, MISO should be HiZ for the first 8 clocks, then Hi/Lows for the last 8 clocks. If it works with a '256 then should work with '1024, same instructions/sequences .
As far as Pin3 the DS doesn't say what level to tie it to, so either that means either state (but Vdd didn't work), or we just got'a guess. Don't think it matters on the '256, but the '1024 has the SDI/SQI mode (don't know about these modes, more research to do). If Vss on P.3 doesn't help then it may be a dead bug ?!?!
I've got 3 samples coming, you'r welcome to a couple. I don't know when they will be here, ordered them 2 or 3 days ago( MC is pretty fast most times) PM me if you want them.
EDIT-Just went through AN 1484 It recommends that 10K pull ups on /CS, /HOLD and Pin 3. It notes that Pin 3 can be pulled low, but on exit from SQI mode it needs to go high, so that is the preferred idle state. Also mentioned that if Vcc sags below Op levels, should do a full pwr cycle reset.
Back to top
View user's profile Send private message
JovianPyx



Joined: Nov 20, 2007
Posts: 1988
Location: West Red Spot, Jupiter
Audio files: 224

PostPosted: Thu Jan 17, 2013 4:58 am    Post subject: Reply with quote  Mark this post and the followings unread

I have AN1484 here (01484A.pdf), did the pullups and pin 3 is pulled high. I have a thread open on the Microchip forum about this. I'll wait and see what they say there before I do anything else. It really looks like a bad IC or a mismarked IC. (well, 2 bad or mismarked ones). Definately works with 23K256 and fails with 23LC1024.

Don't know how close your are to connecting a 23LC1024 to dsPIC33F, but if you're there - you have my code... Wink

_________________
FPGA, dsPIC and Fatman Synth Stuff

Time flies like a banana.
Fruit flies when you're having fun.
BTW, Do these genes make my ass look fat?
corruptio optimi pessima
Back to top
View user's profile Send private message Visit poster's website
yogi



Joined: Jun 26, 2008
Posts: 29
Location: Maryland

PostPosted: Thu Jan 17, 2013 9:42 am    Post subject: Reply with quote  Mark this post and the followings unread

Well the board's mostly done but waiting for the '1024s to show up. In the interim, I'll be adding some ifdefs for the PLL setup and remapping the SPI pins; I've built it based on the RoninSynth setup. So I'll let you know in the next few days, once I blinken de LEDs Wink
Back to top
View user's profile Send private message
JovianPyx



Joined: Nov 20, 2007
Posts: 1988
Location: West Red Spot, Jupiter
Audio files: 224

PostPosted: Fri Jan 18, 2013 9:59 am    Post subject: Reply with quote  Mark this post and the followings unread

GOOD NEWS.

Bit CKE in SPI1CON1 needs to be SET not CLEARED.

I got this from a Microchip forum member. I looked at that bit and thought "well, the worst that can happen is bad data". Not so. When I CLEAR that bit, toggle of the SRAM chip stops and the SO line (pin2) remains at Vss (zero volts).

After setting the bit and retesting, I see toggling on pin 2. Then I ran the full data reliability test and it started to pass immediately. Just to make sure, I disabled the compare and branch that detects pass/fail so that it always (pretends) to fail and the listed read from RAM matches the data that was written.

This test is currently running with the SPI channel set to 10 megabits per second.

_________________
FPGA, dsPIC and Fatman Synth Stuff

Time flies like a banana.
Fruit flies when you're having fun.
BTW, Do these genes make my ass look fat?
corruptio optimi pessima
Back to top
View user's profile Send private message Visit poster's website
yogi



Joined: Jun 26, 2008
Posts: 29
Location: Maryland

PostPosted: Fri Jan 18, 2013 4:45 pm    Post subject: Reply with quote  Mark this post and the followings unread

That's great to hear! I remember reading about trying dif settings for the Clk edge and the idle state for a intermittent EEPROM problem, but seeing how your code seemed to work with the '256. Well I guess there is a subtle difference between these SRAM families. Learn something new everyday!
Back to top
View user's profile Send private message
JovianPyx



Joined: Nov 20, 2007
Posts: 1988
Location: West Red Spot, Jupiter
Audio files: 224

PostPosted: Fri Jan 25, 2013 1:07 pm    Post subject: Reply with quote  Mark this post and the followings unread

Next stage is now working: 2 x 23LC1024 SPI SRAMs each operating from it's own SPI interface. The driver starts both (with DMA) at nearly the same time so they operate mostly in parallel. This allows 16 bit transfers in the same time it takes to do 8 bits. Both channels are running at 10 megabits per second (the max for dsPIC33F).

My initial attempts were troubled by an inability to use pin 22 (RP11) for SDO. It simply would not toggle. I've still got to research why that happened, but I found that using pin 23 (RP12) worked just fine. I then tried RP11 again with a brand new dsPIC33F IC and the results were the same - no toggling of SDO when assigned to RP11. This tells me that there is something funky about my peripheral device setup code. However, for the time being, it is working. I have a random data diagnostic running in 16 bit mode now.

_________________
FPGA, dsPIC and Fatman Synth Stuff

Time flies like a banana.
Fruit flies when you're having fun.
BTW, Do these genes make my ass look fat?
corruptio optimi pessima
Back to top
View user's profile Send private message Visit poster's website
yogi



Joined: Jun 26, 2008
Posts: 29
Location: Maryland

PostPosted: Sun Jan 27, 2013 10:09 pm    Post subject: Reply with quote  Mark this post and the followings unread

Very interesting idea. Could be very useful to hold L & R sample data and not have to worry about interleaving the data in one buffer.
On the board I've been building, I added another dip for a SPI EPROM but its on the same channel as the SRAM. So there's not any saving as to bandwidth, but I thought it would be useful for patch storage and recall.
I saw a project where the dsPIC was interfacing to a unusual CD filter chip, don't recall all the details, but he needed to run 2 SPI channels in synchronous, I think for left and right sample streams. He setup one SPI channel as a Master and the second in slave mode. Then ran a jumper from the master's SCLK out pin to the slave's SCLK in pin, so the master channel's CLK was in effect timing the whole system. Don't think this could be of help here, but it may be a way to trigger the second DMA channel start-up.
The 28 pin package is getting very tight, pin wise. If the duel SRAM setup is a big benefit I could re-route the 2nd dip's wiring to setup a second SPI channel, but lose either balanced DAC outputs or some Analog inputs? But I've got a 'gp708 protoboard with a TI 'aic23b codex that has an abundance of pins! On the one hand the '802 with the built-in DAC is very simple and fun; on the other hand, the larger dsPIC package opens new doors, (been thinking about the PMP interface with a large parallel RAM) but then the system complexity grows so fast!!
As I write this, a thought just occurred to me, Can the DMA controller run two channels simultaneously? If you have two SPI channels started at about the same time, will they both compleat at the same time, or will one DMA channel block the other? Don't remember reading anything about this one way or the other. My impression was that the DMA controller has a separate bus (from the CPU's) for the transfers but all DMA channels would need to share this bus.
Back to top
View user's profile Send private message
JovianPyx



Joined: Nov 20, 2007
Posts: 1988
Location: West Red Spot, Jupiter
Audio files: 224

PostPosted: Mon Jan 28, 2013 6:40 am    Post subject: Reply with quote  Mark this post and the followings unread

I'm using 4 DMA channels to do this. Channel 0 has hard wired priority in terms of owning the bus. Yeah, all the DMA channels share the same SRAM port, but since the DMA is started sequentially, there doesn't seem to be an arbitration problem (that is, the data is not late enough to cause problems with the diagnostic). I was able to do this with one interrupt from the second read channel started. Read always finishes after write, so the DMA read interrupt from the second read channel started tells the program that all SPI DMA is complete.

The messy part is the amount of code needed to stuff the DMA write buffers before starting the transfer. If the SPI SRAM addresses are truly random, some 24 or so instructions are needed to fire off an SPI SRAM transaction. This is about 0.6 microseconds (assuming 40 MIPS). However, the rest happens in the DMA controller and the CPU can go do other things until the interrupt occurs. So it's not super efficient as parallel SRAM would be, but the DMA does help quite a bit.

Each SPI SRAM transaction needs 40 clocks, so at 10 megabits per second, this is 4 microseconds. In my case, since I use two in parallel, I get one 16 bit word transfer every 4 microseconds or 250,000 times per second. Doing a read and a write as are needed for echo means 125,000 echo samples per second (mono) or 62,500 per second in stereo. That's why I decided to try running two parallel SPI interfaces.

It does, as you say, use a lot of pins. I'm now working on adding a CS4270 codec IC which will need 6 (maybe 7) pins, but then I won't use the internal stereo DAC. So pins are tight, but for what I'm trying to do, the 28 pin package might work. I do save one pin by operating both SPI SRAM CS pins from a single dsPIC pin.

_________________
FPGA, dsPIC and Fatman Synth Stuff

Time flies like a banana.
Fruit flies when you're having fun.
BTW, Do these genes make my ass look fat?
corruptio optimi pessima
Back to top
View user's profile Send private message Visit poster's website
yogi



Joined: Jun 26, 2008
Posts: 29
Location: Maryland

PostPosted: Mon Jan 28, 2013 7:51 pm    Post subject: Reply with quote  Mark this post and the followings unread

JovianPyx wrote:

Each SPI SRAM transaction needs 40 clocks, so at 10 megabits per second, this is 4 microseconds. In my case, since I use two in parallel, I get one 16 bit word transfer every 4 microseconds or 250,000 times per second. Doing a read and a write as are needed for echo means 125,000 echo samples per second (mono) or 62,500 per second in stereo. That's why I decided to try running two parallel SPI interfaces..

OK, I think I'm understanding. In effect, the SPI peripheral is the bottleneck, with each DMA channel spending most of the time waiting on the service request. Any DMA blocking that may occur, if the two SPI channels send DMA requests at the same time, is minimal compared to the time to transmit a byte.
When reading the DS for the LC1024s, it mentioned the dual and quad SPI modes, though, I'm thinking that the dsPIC' SPI channels don't allow this (no mention of it in that DS). I'm assuming those modes are similar to what you have created.
Back to top
View user's profile Send private message
JovianPyx



Joined: Nov 20, 2007
Posts: 1988
Location: West Red Spot, Jupiter
Audio files: 224

PostPosted: Tue Jan 29, 2013 6:52 am    Post subject: Reply with quote  Mark this post and the followings unread

yeah, correct - no quad or double speed SPI modes for dsPIC33F. Heck, I wish they had a version (or a selectable mode using pin 3) that would access 16 bits per transfer instead of 8 bits.
_________________
FPGA, dsPIC and Fatman Synth Stuff

Time flies like a banana.
Fruit flies when you're having fun.
BTW, Do these genes make my ass look fat?
corruptio optimi pessima
Back to top
View user's profile Send private message Visit poster's website
yogi



Joined: Jun 26, 2008
Posts: 29
Location: Maryland

PostPosted: Tue Jan 29, 2013 1:28 pm    Post subject: Reply with quote  Mark this post and the followings unread

After reading Wikipedia; really only the quad mode would be a help. Both are half duplex modes, so dual mode runs at about the same speed as generic SPI full duplex and Quad mode offers about double the through-put. It's all mote anyway, never seen a SPI peri. on a uC that supported these modes, might be useful on an FPGA.
Oh Well
Back to top
View user's profile Send private message
JovianPyx



Joined: Nov 20, 2007
Posts: 1988
Location: West Red Spot, Jupiter
Audio files: 224

PostPosted: Thu Jan 31, 2013 10:48 am    Post subject: Reply with quote  Mark this post and the followings unread

I've found the problem with RP11. It's I/O pin is output enabled using RPOR5. This register also enables RP10. There is a tremendous advantage for doing hardware device setup in C since the "bits" variables are affected as bit fields and not as full registers.

One way around this when using ASM30 is to use only BCLR and BSET instructions to change settings in such registers that are shared by more than one peripheral.

_________________
FPGA, dsPIC and Fatman Synth Stuff

Time flies like a banana.
Fruit flies when you're having fun.
BTW, Do these genes make my ass look fat?
corruptio optimi pessima
Back to top
View user's profile Send private message Visit poster's website
yogi



Joined: Jun 26, 2008
Posts: 29
Location: Maryland

PostPosted: Sat Feb 02, 2013 12:02 am    Post subject: Reply with quote  Mark this post and the followings unread

Good to hear you resolved the problem with RP11. Will keep this in mind.

JovianPyx wrote:
...Heck, I wish they had a version (or a selectable mode using pin 3) that would access 16 bits per transfer instead of 8 bits.

This got me thinking; the SPI can handle word transfers, and the SRAM can be set for sequential mode, would that be any help? Not clear from the timing diag how the SRAM will react to a pause on the clock between word transfers, but it looks like it may work, as long as CS remains low. It might decrease the loading on the DMA controller. Would have to be mindful of rollover at the end of the array, but that may not be a concern for a circular buffer with a echo.
Back to top
View user's profile Send private message
JovianPyx



Joined: Nov 20, 2007
Posts: 1988
Location: West Red Spot, Jupiter
Audio files: 224

PostPosted: Sat Feb 02, 2013 7:52 am    Post subject: Reply with quote  Mark this post and the followings unread

I had wondered that too. Now that you mentioned it, I looked at the timing diagram and it shows an address being sent to the SRAM. The PDF also says that in sequential mode, the SRAM ignores page boundaries. All that is needed to cut off the transaction after reading 2 or however many bytes is to raise bar-CS. I will have to try this today. The arithmetic says that two 16 bit words can be transfered 156,250 times per second. Doing a stereo read and write could happen 78,125 times per second, well fast enough to use a single SPI interface. A dual parallel interface could operate at twice that speed. This might actually simplify the driver code as well.

I will post if/when I get it working.

EDIT ADD: It turns out that I've been using sequential mode to read and write bytes all along. The default mode is sequential and I never sent a "byte mode" command to the control register. So sequential mode for reading and writing bytes has already been tested. The code I have reads or writes a byte and then raises bar-CS. All I need do is extend this to 16 bits.

_________________
FPGA, dsPIC and Fatman Synth Stuff

Time flies like a banana.
Fruit flies when you're having fun.
BTW, Do these genes make my ass look fat?
corruptio optimi pessima
Back to top
View user's profile Send private message Visit poster's website
JovianPyx



Joined: Nov 20, 2007
Posts: 1988
Location: West Red Spot, Jupiter
Audio files: 224

PostPosted: Sat Feb 02, 2013 10:04 am    Post subject: Reply with quote  Mark this post and the followings unread

This is now under test and passing. The test writes 32 bits (random data) to two SRAMs in parallel, reads back, compares and repeats.

EDIT ADD: The diagnostic runs noticably faster as well.

EDIT ADD: In the case of 2 parallel SRAMs, timing is 104,166 stereo samples per second.

EDIT ADD: The driver code is indeed a bit simpler.

_________________
FPGA, dsPIC and Fatman Synth Stuff

Time flies like a banana.
Fruit flies when you're having fun.
BTW, Do these genes make my ass look fat?
corruptio optimi pessima

Last edited by JovianPyx on Sat Feb 02, 2013 11:06 am; edited 2 times in total
Back to top
View user's profile Send private message Visit poster's website
yogi



Joined: Jun 26, 2008
Posts: 29
Location: Maryland

PostPosted: Sat Feb 02, 2013 10:54 am    Post subject: Reply with quote  Mark this post and the followings unread

Most excellent!'Laughing' Hummmm, VERY long stereo delay...
Back to top
View user's profile Send private message
skrasms



Joined: Feb 21, 2008
Posts: 121
Location: Portland, OR

PostPosted: Sun Feb 24, 2013 1:15 pm    Post subject: Reply with quote  Mark this post and the followings unread

I just want to say thanks for creating this thread. I had an FPGA design where I needed about 1 Mbit of low-bandwidth external RAM but only had a few pins to spare. Serial RAM was a perfect fit. I just got the 1 Mbit Microchip part running last night, and it's working great.

Now they just need to offer larger sizes and kick the supported clock frequency up to 50+ MHz.

_________________
Software and Hardware Design
Back to top
View user's profile Send private message
JovianPyx



Joined: Nov 20, 2007
Posts: 1988
Location: West Red Spot, Jupiter
Audio files: 224

PostPosted: Sun Feb 24, 2013 5:39 pm    Post subject: Reply with quote  Mark this post and the followings unread

You're welcome skrasms.

The latest is I've reverted back to using two 23LC1024 SRAM ICs on one SPI bus because I needed a couple of pins for something else. Using sequential mode, I am transferring 32 bits of data per transfer and it is still faster than the 48 khz sample rate I will be using.

In an FPGA, you could use the quad speed mode that the 23LC1024 supports and do things quite a bit faster.

I've used the 23K256 IC (256kbits or 32kbytes) on an FPGA, I'd like to try the 23LC1024, especially in quad speed mode when I get a new supply of round tuits...

_________________
FPGA, dsPIC and Fatman Synth Stuff

Time flies like a banana.
Fruit flies when you're having fun.
BTW, Do these genes make my ass look fat?
corruptio optimi pessima
Back to top
View user's profile Send private message Visit poster's website
cloudscapes



Joined: Feb 09, 2004
Posts: 100
Location: Montreal

PostPosted: Tue Feb 26, 2013 2:21 pm    Post subject: Reply with quote  Mark this post and the followings unread

While we're on the topic of delays.

How are you guys speeding up and slowing down delay/loops on a fixed 48khz interface?

_________________
Sonic Crayon DIY effects lab
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic Moderators: State Machine
Page 2 of 2 [45 Posts]
View unread posts
View new posts in the last week
Goto page: Previous 1, 2
Mark the topic unread :: View previous topic :: View next topic
 Forum index » DIY Hardware and Software » Microcontrollers and Programmable Logic
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Forum with support of Syndicator RSS
Powered by phpBB © 2001, 2005 phpBB Group
Copyright © 2003 through 2009 by electro-music.com - Conditions Of Use