>> Having it set to true doesn't call stop_write() at all. sd_stop_write() does get called, in the sample. a stop write is just to send 0xFD, then wait till the card is ready with sd_set_idle(), and repeats. The card should have gotten the commands the first time. SD_STOP_TRANSMISSION, SD_GO_IDLE_STATE that are in set_idle. Maybe these old cards require the clock pulses or can't listen while busy, but that is not in the datasheets. These are the only reason I can think of, and would explain why 2 calls of stop_write fixes it. weird. I actually think I read somewhere in the datasheets that a disable of the select line would stop any reads/writes, and after some time the card would be ready again. This is of course not working here. I suggest we try going with FALSE as default, and maybe eventually get rid of TRUE. High capacity needs a much different init procedure, and it's smallest addressing is a block of 512 bytes. on standard capcity you can address bytes. In sd_start_read() you can see this line: address = address * SD_BYTE_PER_SECTOR This line would be commented out on high capacity. I think I got the init procedure working once and received a reply from a high capacity card (one out of my 2 cards), but I never was able to read/write anything. I can look around to see if I still have that code if you want. Matt.
On Thursday, September 20, 2012 2:06:57 AM UTC-4, Sebastien Lelong wrote: > Hi Matt, > > Thanks for your reply. What's weird is the TRUE case just wait, and FALSE > case does a lot of things. I'd expect TRUE case to wait, then execute the > FALSE case (that is, no "else"). > > In our case, setting it to false doesn't mean it waits 50ms, it just loops > in the else case, performing stop_write(), etc... Having it set to true > doesn't call stop_write() at all. What Trev found is calling stop_write() a > second time fixes the issue. > > About high capacity card, is it a matter of timing, or is it about a > different protocol to implement ? > > Cheers, > Seb > > On 20 September 2012 05:19, mattschinkel <[email protected]<javascript:> > > wrote: > >> Hey Guys, >> >> http://justanotherlanguage.org/content/jallib/tutorials/tutorial_sd_card >> >> "Some sd cards may require a 10ms (or more) delay every time you stop >> writing to the sd card, you can choose weather or not to have this delay. >> If you are doing many small writes and are worried about speed, you may set >> SD_DELAY_AFTER_WRITE to FALSE." >> >> I had an issue with writes quite a while ago when I wrote the lib, and so >> I made this 50,000 delay. It seems that some cards take longer then others >> to do writes. 50ms is plenty long enouf to do a write. I see most of my >> files still have it set to TRUE. Using this should be safe as it gives the >> card more time, but apparently not in this case. >> >> I actually wrote the FALSE part later on, and it seems to be stable now. >> I've been thinking of removing the TRUE. >> >> So, since setting SD_DELAY_AFTER_WRITE to FALSE solved his issue, I am >> guessing that the card is taking longer then 50ms to become ready which is >> rediculusly slow. >> >> I'm not sure how long the 50,000 loop takes. The loop is not supposed to >> equal 50ms, it's just supposed to allow the loop to exit eventually if >> there is no reply. An error should be set here if no reply from the card, >> but I never got to that. >> >> The question is... how is it exiting that loop with >> SD_DELAY_AFTER_WRITE = FALSE? There are 2 ways to exit. Please find out. >> >> I guess this constant is hidden from jaluino users? >> >> We're still waiting for high capacity cards > 2gb to work :) >> >> Matt. >> >> On Wednesday, September 19, 2012 1:34:39 AM UTC-4, Sebastien Lelong wrote: >> >>> Hi guys, >>> >>> >>> Trev, from Jaluino, has made several tests with SD cards, running on >>> Jaluino Bee. He's been able to make 2GB SD Card working, see below. Matt, >>> can you tell us more about this SD_DELAY_AFTER_WRITE constant ? When true, >>> it just waits, when false, it does a lot more than just wait ? >>> >>> Pull-ups configured with this test: /SS and SCK >>> Sample: https://code.google.**com/p/jaluino/source/browse/** >>> trunk/samples/jaluino_bee_sd_**card.jal<https://code.google.com/p/jaluino/source/browse/trunk/samples/jaluino_bee_sd_card.jal> >>> with modified SD_DELAY_AFTER_WRITE to false (in lib jaluino.jal) >>> >>> >>> Cheers, >>> Seb >>> >>> >>> ---------- Forwarded message ---------- >>> >>> You might recall issues I had with some uSD cards not working with the >>> Bee and your test SD write/read program. >>> >>> Well, having purchased a single 2Gb uSD card off eBay and finding it >>> worked and was branded ADATA I asked the Chinese vendor if I bought more, >>> would they also be ADATA branded. He said yes, so I bought six more. >>> However, when they arrived they were generic, unbranded cards. Three of >>> them worked and three of them didn't work with the Bee. >>> >>> Dang! So tonight while I was re-testing the three non-working cards, I >>> removed a card after the Bee had "written" but after it got stuck and did >>> not do any "reading", and then put it back almost immediately. The Bee then >>> started reading the crad and flashing the LED. Hmmm. So I decided to play >>> around with the code. >>> >>> The first thing I did was add a delay after the stop_write() and before >>> the start_read(). This made no difference. The next thing I did was add a >>> second stop_write() immediately after the first one... this worked! >>> >>> So now I turned my attention to the sd_card.jal file. >>> >>> if SD_DELAY_AFTER_WRITE == TRUE then >>> _usec_delay (50_000) >>> else >>> for 50000 loop >>> sd_chip_select = low -- enable the sd card >>> >>> var byte reply >>> send_command(SD_STOP_**TRANSMISS**ION,0,reply) -- stop current >>> transmission >>> sd_ready() -- wait till sd card is >>> ready >>> send_command(SD_GO_IDLE_STATE,****0,reply) -- command 0, >>> Resets card to idle state >>> sd_ready() -- wait till sd card is >>> ready >>> >>> sd_chip_select = high -- disable the sd card >>> >>> if !(reply == 0) then >>> exit loop >>> end if >>> end loop >>> end if >>> >>> I first commented out the "if...else" and "end if" and ... it worked! >>> Looking at the code, I'm not sure I understand how simply delaying for >>> 50,000us is supposed to be a delay compared with all those commands in the >>> else clause trapped in a 50,000 loop! >>> >>> But be that as it may, the ultimate fix was to track down the >>> SD_DELAY_AFTER_WRITE constant in the jaluino_bee.jal file and make it FALSE >>> although I still suspect there's something not quite right about that >>> sd_card.jal code which I don't understand because it seems to me that the >>> else clause causes an even bigger delay! >>> >>> Anyway, it now works for all the 2Gb uSD cards that I have (although I >>> can't find the 2Gb Kingston branded one which first caused the problem more >>> than a year ago). >>> >>> Cheers, >>> TREV. >>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "jallib" group. >> To view this discussion on the web visit >> https://groups.google.com/d/msg/jallib/-/fKVNV4T0CrIJ. >> To post to this group, send email to [email protected]<javascript:> >> . >> To unsubscribe from this group, send email to >> [email protected] <javascript:>. >> For more options, visit this group at >> http://groups.google.com/group/jallib?hl=en. >> > > > > -- > Sébastien Lelong > > > -- You received this message because you are subscribed to the Google Groups "jallib" group. To view this discussion on the web visit https://groups.google.com/d/msg/jallib/-/t88LKeIF9eoJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jallib?hl=en.
