Problem using OLED uSD Ccard
Squig
Posts: 13
Howdy,
Im using a μOLED-128-GMD1 on my current project.· It works great but I can't get the uSD Card to work.
I must be doing something fundamentally wrong.· I've got a Sandisk 1 gig card in it.
I've·tested it out with the following:
It gets all the way down to reading and locks up.
I've tried reading single Bytes but all I get is zeros.
Should that·code/card work?· Do I need to format the card in some way?
Im using a μOLED-128-GMD1 on my current project.· It works great but I can't get the uSD Card to work.
I must be doing something fundamentally wrong.· I've got a Sandisk 1 gig card in it.
I've·tested it out with the following:
CON _CLKMODE = XTAL1 + PLL16X _XINFREQ = 5_000_000 VAR long SAddr byte uSD_Sector[noparse][[/noparse]512] byte outDat[noparse][[/noparse]512] byte i OBJ OLED : "uOLED-128-GMD1" DELAY : "Clock" PUB main OLED.INIT OLED.ERASE DELAY.PauseMSec(20) OLED.BACKGROUND(0,0,0) DELAY.PauseSec(1) OLED.FTEXT(0,0,0,255,255,255,string("Starting"),0) repeat i from 0 to 255 outDat[noparse][[/noparse]i] := i outDat[noparse][[/noparse]i+256] := i OLED.FTEXT(0,1,0,255,255,255,string("Writing"),0) DELAY.PauseSec(2) SAddr := 1_000 OLED.WRITE_SECTOR(@SAddr,@outDat) OLED.FTEXT(0,2,0,255,255,255,string("Reading"),0) DELAY.PauseSec(2) SAddr := 1_000 OLED.READ_SECTOR(@SAddr,@uSD_Sector) OLED.FTEXT(0,3,0,255,255,255,string("Done"),0)
It gets all the way down to reading and locks up.
I've tried reading single Bytes but all I get is zeros.
Should that·code/card work?· Do I need to format the card in some way?
Comments
Steven
Squig... Jim?
Very timely thread. Great questions. If you don't get an answer here, try 4D's forum. This code must be available... no reason to re-invent the wheel, except that someone deflated the tires?
Sounds like the demo program works for you? There is a demo program that reads and writes images to the uSD. Have you tried writing bytes to specific locations?
http://www.newchicken.com/tag-gmd1.html Won't help much but it has some real nice adds[noparse]:)[/noparse]
Please keep us posted on your progress...
Rich
_CLKMODE = XTAL1 + PLL8X "This seemed to repair the problem". Also might make sure that when you power up the Dispay the scrolling screen has SDK showing up.
JMLStamp2p
If I change the clock settings the OLED fails to·operate at all.
I ran the demo and it's not reading the uSD either.· But it's not locking up.
I have version 5 of the Pmmc so Im going to try updating that.
·
I can write Sectors and read bytes.· But I still can't read sectors.· It locks up every time.
I got as far as reading and writing with your set up... before I destroyed my 128. I have a new one but haven't had time to play with it.
I found that I would get lock ups when I tried to check a bad sector. So, I just left the call out.
Rich
I've found that the prop is successfully reading 256 bytes before it locks up.
My light was on, but there was nobody home.
There is a call in the demo program... commented out. I'm working from memory. Tomorrow after the SuperBrawl I'll break out my fresh 128 and see how far I can get.
Again... sorry for the delay.
Rich
I have been unable to find example code to read/write to the SD card. There was an example in the object exchange, but it failed after "mounting" the card.
The OLED-96 uses the Prop to talk to the card; the OLED-128 uses a different processor.
For the OLED-96, if you download the FAT16 R/W object from the object exchange, and
it doesn't work, chances are good your card is simply formatted wrong, probably in FAT32.
Read the README that comes with that object (http://tomas.rokicki.com/fat16work/README.txt
on the web) and try again. (I'm not sure but I suspect you may have to change the
mount line since I think the OLED-96 connects the SD card on different pins.)
If it doesn't work after that, try the sdrw_test object and let us know what happens.
I can pull out my OLED-96 and give you more detailed instructions if needed.
-tom
If you pull it out... see what happens when you try to delete a file... when I delete files using the prop they still show up in the directory if that is because of what you are doing... it's ok for me... but if it is because of what I am doing then I need to do it right...thanks,
et al...
Other than what tom has said, I also suspect that you have to worry about how you take the card out of the computer... you actually have to "eject" it... you can just pop it out... it seems to mess up the formatting somehow. This is absolutely true on the Mac and I think it might be true with XP as well.
Rich
I verified the card is formatted in Fat16, with 16K cluster size. The card is 1G in size (Kingston).
Do you have some working example code?
Thank you
spry981: Tonight I'll get you some code.
I had to change the low-level block read/write code to reflect the
pinout on the OLED card. This is temporary. The next version of
fsrw will require all four numbers to the start routine, rather than
assuming they are all the same. (Actually, the existing start
routine will still be there but there will be a new start4() that takes
the four pins in a specified order).
The "normal" pin order is do, clk, di, cs. The OLED pin order is
cs, clk, do, di.
The "base" pin for the OLED is 14.
Run the OLED_FSRW_demo. If it says "start returned" and shows
a number that's not zero, that's an error code; search for that
number in the source. (Note that negative numbers are error
codes; in assembly you'll find the numbers as *positive*.)
I'll have to write a better "tester" that does things slowly, step by
step, explaining what is happening at each step and, when things
fail, why they failed. But this should get you started.
-tom
Has anyone had any luck doing this?
so other people don't need to reinvent the wheel. That also means I'll have to deal with
the MIT license issue, but no big deal.
Squig: No idea what's happening there. It does seem odd that it claims to successfully
write, but then the read hangs up. Did you verify that the data is actually written to the card
(the bytes 0..255 on the first sector)? Did you try throwing a scope on the pins and see
what is happening? What I would do in this case is such in the read sector routine inline
and add some debugging code to see where it hangs up. If you take out the write, does the
read routine still hang up? You may have to ask the manufacturer for some sample code
to read a sector. Where did you get the OLED-128 Propeller code from? Maybe the
author can help you.
I know it reads the first 256 bytes before it locks up but I haven't checked to see if the data it reads is good.
I got the propeller code from the object exchange.
I changed the driver so that it only tried to read in 256 bytes, then compared the data to what it was writing.· I have already verified that the write sector work perfectly.
Anyway, when it does a sector read, it reads about 21 bytes correctly, then it drops about 16 bytes, reads 21 bytes, drops 16.
It could be a timing problem, it's hard to say.· I also wonder if it might be due to the serial buffer size of·16 bytes in the full duplex driver.· Since it's in a cog, I can't increase it to 512 and Im having a little trouble pointing elsewhere.