Parallax Forums
  HomeLog InRegisterCommunity CalendarSearch the ForumHelp
   
Parallax Forums > Public Forums > Propeller Chip > Sharing SD SPI pins without unmounting  Forum Quick Jump
 
New Topic Post Reply Printable Version
[ << Previous Thread | Next Thread >> ] | Show Newest Post First ]

Kal_Zakkath
Registered Member

Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Nov 2008
Total Posts : 11
 
   Posted 11/6/2009 10:38 PM (GMT -8)    Quote This PostAlert An Admin About This Post.
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:
  1. Alter fsrw somehow (seems like it would take too long to be worth the effort)
  2. 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)
  3. 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



Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Oct 2004
Total Posts : 13554
 
   Posted 11/6/2009 11:07 PM (GMT -8)    Quote This PostAlert An Admin About This Post.
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
 

Cluso99
We live onboard



Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Apr 2008
Total Posts : 2276
 
   Posted 11/7/2009 2:23 AM (GMT -8)    Quote This PostAlert An Admin About This Post.
Further to what Mike has said, there is another problem with sharing the pins. DO from the SD card does not release (tristate) normally when CS is removed. It requires a number of clock pulses as well.

See the TriBlade and ZiCog threads. I have solved the fsrw driver for Femto in the ZiCog/TriBlade femto driver. Lonesock/rokicki have added some extra code to disable the DO as well, but I don't have it working on TriBlade yet.


Links to other interesting threads:
Back to Top
 

Kal_Zakkath
Registered Member

Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Nov 2008
Total Posts : 11
 
   Posted 11/7/2009 4:48 AM (GMT -8)    Quote This PostAlert An Admin About This Post.
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
 

lonesock
Registered Member



Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined May 2008
Total Posts : 284
 
   Posted 11/7/2009 9:46 AM (GMT -8)    Quote This PostAlert An Admin About This Post.
In FSRW 2.4, the block layer has a "release" command. The block layer is designed to have only one instance, so it's OK to do something like this:

OBJ
  sdfat: "fsrw"
  sdspi: "mb_rawb_spi" ' make sure this matches exactly the block layer used in "fsrw"

'...
' bunch of code
'...

  ' finished reading WAV data
  sdspi.release
  ' now update my LCD


FSRW will automatically reacquire the lines next time you ask "sdfat" to do something, so make sure the LCD is no longer using those lines before you read/write/open/close, etc.

You will need to uncomment the line immediately after "for Cluso99" in the release_DO section of the "mb_rawb_spi.spin", so it should read:
mov dira,#0


Jonathan


lonesock
Piranha are people too.

Back to Top
 

Kal_Zakkath
Registered Member

Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Nov 2008
Total Posts : 11
 
   Posted 11/10/2009 12:39 AM (GMT -8)    Quote This PostAlert An Admin About This Post.
Hmm, I tried that but still no go. According to a logic probe all lines are fine except for DO which is still high after calling release.
If I try to then make it low in the 'main' cog, it pulses (or at least the logic probe says it is [Sq. wave < 100kHz], I don't have an oscilloscope to see what it's really doing unfortunately).
 
I tried adding more calls to in8 in release_DO in case it needed more clock cycles but it didn't seem to make any difference.
 
And as before if I call unmount first it all works fine.
 
Back to Top
 

lonesock
Registered Member



Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined May 2008
Total Posts : 284
 
   Posted 11/10/2009 8:36 AM (GMT -8)    Quote This PostAlert An Admin About This Post.
OK. If the card refuses to release the DO line I'm not sure what else to do (the driver cog is not driving that...it's an input to the prop, from the SD card). You could try it with a card from a different manufacturer. I suppose we could even write the mount logic in PASM to speed up a remount, but I'm very hesitant to do that, for the resulting code size, readability, and debug-ability.

sorry,
Jonathan


lonesock
Piranha are people too.

Back to Top
 

Cluso99
We live onboard



Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Apr 2008
Total Posts : 2276
 
   Posted 11/10/2009 7:18 PM (GMT -8)    Quote This PostAlert An Admin About This Post.
Jonathan: I haven't had the time to debug, but that could be the same problem I was finding. As soon as time permits, I will get back to finishing the ZiCog/TriBlade code and that may perhaps showup the problem. For now, I have just presumed I am missing something.


Links to other interesting threads:
Back to Top
 

RossH
Registered Member



Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Jun 2008
Total Posts : 411
 
   Posted 11/11/2009 1:00 AM (GMT -8)    Quote This PostAlert An Admin About This Post.
@all,

Also, look in the Catalina code I wrote for the TriBladeProp - I also had to rewrite the spdi low level code to get it working, and make sure the XMM Kernel and the SD plugin correctly tristated the control lines in each case. The files to look at are:

Catalina_SD_Plugin_Input.spin
Catalina_XMM_Input.spin

both in Catalina\target\input - look for the "#ifdef TRIBLADEPROP" sections

Ross.


Catalina - a FREE C compiler for the Propeller - see Catalina

Back to Top
 

Kal_Zakkath
Registered Member

Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Nov 2008
Total Posts : 11
 
   Posted 11/13/2009 2:44 AM (GMT -8)    Quote This PostAlert An Admin About This Post.
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
 

lonesock
Registered Member



Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined May 2008
Total Posts : 284
 
   Posted 11/13/2009 8:17 AM (GMT -8)    Quote This PostAlert An Admin About This Post.
You know what...I think you found a bug in my code!

I have some code that will auto-release after an inactivity timeout (currently 0.125 seconds). Once the timeout is exceeded, the release_DO code gets called repeatedly under the theory that it couldn't hurt. However, in my command handler if the last command was a reset, then it re-enables the output lines...then processes the fact that the new command is another release, and releases the lines. So, of the state of outa doesn't happen to match your pull-ups/downs, then the pins that don't match will be toggling!

This particular bug _should_ only happen 1/8th a second after you call release, though (I think, anyway).

Nice catch, and I'll try to fix this today...I just need to make sure my fix doesn't break anything else. (Hopefully this will make it work for Cluso as well.)

Jonathan


lonesock
Piranha are people too.

Back to Top
 

lonesock
Registered Member



Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined May 2008
Total Posts : 284
 
   Posted 11/13/2009 9:07 AM (GMT -8)    Quote This PostAlert An Admin About This Post.
Please try this updated version of the block layer. If it fixes the problem, I will then make the changes across the board to the other block layers (the smaller versions, etc.). We will then push out a 2.5 release as soon as possible.

Note: you will still need to uncomment the "mov dira,#0" line again.

Jonathan


lonesock
Piranha are people too.



File Attachment :
mb_rawb_spi.spin   30KB (application/octet-stream)
This file has been downloaded 5 time(s).
Back to Top
 

Kal_Zakkath
Registered Member

Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Nov 2008
Total Posts : 11
 
   Posted 11/13/2009 2:11 PM (GMT -8)    Quote This PostAlert An Admin About This Post.
Yes! That seems to have fixed it, both the test code and my full app now run fine sharing all three pins, awesome job! thanks for all the hard work smile
Back to Top
 
[ << Previous Thread | Next Thread >> ]
New Topic Post Reply Printable Version
 
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