 |
|
 |
| Parallax Forums > Public Forums > Propeller Chip > Sharing SD SPI pins without unmounting | Forum Quick Jump
|
|  Kal_Zakkath Registered Member
        Date Joined Nov 2008 Total Posts : 11 | Posted 11/6/2009 10:38 PM (GMT -8) |   |
I have an SD card and an LCD screen (nokia 3310) that I want to have sharing the 3 SPI pins (DI\DO\CLK on the SD).
All works fine if I do this:
sd.mount(10)
sd.unmount
lcd.Init lcd.str(String("Test"))
My problem is that I'll be playing wav files from the SD card and want the lcd to continue updating, but if I do this:
sd.mount(10)
lcd.Init
lcd.str(String("Test"))
then the LCD does not initialise properly.
my understanding is that the CS pin is used to tell devices when to listen to the SPI bus, so it shouldn't matter what the LCD does when not accessing the SD card (in my actual code I am using mutex locks to ensure the SD and LCD are not clashing with each other).
For the SD I'm using fsrw24 (but rolling back to 2.3 or 1.6 makes no difference), the lcd code I have written myself, as far as I can see the issue is not because of anything I've done but I'm attaching the source code here just in case.
Currently the pinout is:
SD: DO = 10, Clk = 11, DI = 12, CS = 13
LCD: Reset = 8, CS = 9, DC = 10, DI = 11, Clk = 12
So far I can only think of three options:
-
Alter fsrw somehow (seems like it would take too long to be worth the effort)
-
Alter the wav code to unmount the SD card between reads (would require seeking back to the last file position, which could be too slow)
-
Don't share any pins between the SD and LCD (looking like my favourite option because it was my original design so it's easy to go back to... would be nice to have a few more pins spare though)
File Attachment : PSM_WavPlayerMono - Archive [Date 2009.11.07 Time 19.34].zip 48KB (application/x-zip-compressed)This file has been downloaded 4 time(s). | | Back to Top | | |
 |  Mike Green Registered Member

       Date Joined Oct 2004 Total Posts : 13554 | Posted 11/6/2009 11:07 PM (GMT -8) |   | | The problem is that the LCD code and the SD code are not designed for those lines to be shared. Each cog has its own direction and output registers and the SD routines use a separate cog to do the low-level I/O. The two cogs (the main one and the low-level SD one) are both trying to control the output pins (Clk and DI). The simplest thing is to use separate I/O pins for each. It is possible to modify the I/O routines to share the I/O pins "nicely", but it would be a bit of work to go through the code to make it happen. | | Back to Top | | |
  |  Kal_Zakkath Registered Member
        Date Joined Nov 2008 Total Posts : 11 | Posted 11/7/2009 4:48 AM (GMT -8) |   |
Thanks for the quick replies.
Mike: Yeah I realised that would be the issue, I thought I might get passed it since A) all the lines to the LCD are outputs (so it should be fine provided the SD cog leaves the lines as either inputs or low outputs, as all cog outputs are OR'd together) and B) as far as I can tell all calls to fsrw (spin) block until the low-level cog is finished, so there shouldn't be any instances when both the 'Main' cog and the 'low-level' cog are both trying to output to the same pins.
I could be wrong about B, if A is the only problem though (the low-level SD code not reverting the pins back to inputs\low) it should just be a matter of having it switch the pins on\off when it goes to\from it's idle state (this is of course my 'ideal simplistic world' thinking).
Cluso99: Thanks for that tip. I wonder, if Lonesock\rokicki have done code for it, does that mean pin sharing may work with the next version of fsrw?
As with so many things this idea of sharing the pins sounded great (and simple) on paper, but is turning out to be more complicated in practicality.
32 pins seemed like a lot when I started this project! heh | | Back to Top | | |
      |  Kal_Zakkath Registered Member
        Date Joined Nov 2008 Total Posts : 11 | Posted 11/13/2009 2:44 AM (GMT -8) |   |
just re-checked the pins and I was wrong, it is DI (pin #13 on the prop, pin #2 on the card, adjacent to CS) being held high not DO.
After calling release, DO and CLK are fine (tristated), CS is high (as it should be) and DI is still high.
At the moment I'm sharing DO and CLK pins with DI moved to its own pin and everything works fine.
I should be able to make do this way, can't see why DI isn't tristated though as release_DO clearly zeros dira, unless the card itself is doing something weird.
The test code I have now is:
i := \sd.mount_explicit(10, 11, 13, 14) 'Mount SD Card if(i <> 0) repeat
repeat 5 waitcnt(cnt + 80_000_000)
sd.release
repeat 5 waitcnt(cnt + 80_000_000)
sd.unmount
sd.release is just a pass-through function that calls sdspi.release
logic probe shows DI pulsing after mount, still pulsing after release, then tristated after unmount.
I've also tried two different SD card brands (Transcend and Adata) and also tried using pins 2,3,5,6 just in case but got the same results.
Oh and the cards are microSD with SD adapters... shouldn't matter but thought I should give as much information as I can just in case.
As I said it's working now by giving DI its own pin, and whilst it would be a bit tidier to share the three SPI pins I'll pick a design that works over one that's tidy any day ;) | | Back to Top | | |
   | Forum Information | Currently it is Friday, November 20, 2009 11:27 PM (GMT -8) There are a total of 393,739 posts in 55,521 threads. In the last 3 days there were 81 new threads and 701 reply posts. View Active Threads
| | Who's Online | This forum has 17687 registered members. Please welcome our newest member, mark09. 51 Guest(s), 5 Registered Member(s) are currently online. Details StefanL38, Dr_Acula, W9GFO, pharseid, micromang |
Forum powered by dotNetBB v2.42EC SP2.02 dotNetBB © 2000-2009 |
|
|