SD-Card on MSSP2

[Sebastien Lelong]

Hi Matt,

I'm modifying your sd-card library so it's not tied to MSSP1. Currently, your lib internally uses "spi_master_hw" pseudo-var, I put a "if defined" logic such has:

-- carrier used to access SD-Card (pseudo-var dealing with SPI)

if !defined(spi_carrier) then

   alias spi_carrier is spi_master_hw

end if

It now uses "spi_carrier", pointing to whatever needed (MSSP1, MSSP2, maybe even SPI software ?)

Cheers,

Seb

PS: I've also seen procedure _sd_read_512(), filling an array, index by index ([0], [1], ...), resulting in 512 lines in the body. There sure must be a reason, but I have to ask: why not using a loop ?

[Oliver Seitz]

>PS: I've also seen procedure _sd_read_512(), filling an array, index by index ([0], [1], ...), resulting in 512 lines in the body. There sure must be a reason, but I have to ask: why not using a loop ?

While loops are handled very efficient by the compiler, access to arrays with a variable index is not as much so. For the PATA lib, it definitely increases speed a lot to read one sector not using a loop. For SD I'm not so sure about this, as data transfer over SPI takes its time, so the difference may be less here.
But that's surely the reason for the existence of this "bad style" part: Speed.

Greets,
Kiste

[Sebastien Lelong]

Oh, bloody hell, I got a working sample writing "A" on some SD-card sector and reading values back, on a PIC18F27J53 (jaluino bee) using PPS to select MSSP2 ! SD-card slot is a micro SD Transflash (or the like). SD-card is a 1GB Sandisk microSD. I didn't use any pull-ups, but I plan to make them optional on the next bee v2.0, just in acse

Cool :)

Cheers,

Seb

PS: Kiste, thanks for the explanation

2011/4/19 Oliver Seitz <karl...@yahoo.com>

[mattschinkel]

> I'm modifying your sd-card library so it's not tied to MSSP1. Currently,
> your lib internally uses "spi_master_hw" pseudo-var, I put a "if defined"
> logic such has:
>
> -- carrier used to access SD-Card (pseudo-var dealing with SPI)
> if !defined(spi_carrier) then
>    alias spi_carrier is spi_master_hw
> end if
>
> It now uses "spi_carrier", pointing to whatever needed (MSSP1, MSSP2, maybe
> even SPI software ?)

Please use spi_master instead of spi_carrier. When SPI is defined in
the sample, there can be aliases. For example:

...
include spi_master_hw
alias spi_master is spi_master_hw

I do this for other things as well:
alias serial_data is serial_hw_data

It makes it easy for the user to choose hw or software, etc.

> PS: I've also seen procedure _sd_read_512(), filling an array, index by
> index ([0], [1], ...), resulting in 512 lines in the body. There sure must
> be a reason, but I have to ask: why not using a loop ?

Because it's faster. There is a constant in the sample for extra speed
to use a non array loop. I think I made this a optional constant. Of
course this uses much more program memory space.

I believe this doubled the speed of hard disk transfers, I can't
remember the exact benifit. Maybe when I get around to writing a
tutorial, I'll add something on speed comparison.

Matt.

[Sebastien Lelong]

2011/4/19 mattschinkel <mattsc...@hotmail.com>

Please use spi_master instead of spi_carrier. When SPI is defined in

the sample, there can be aliases. 

OK, done.

Cheers,

Seb 

[mattschinkel]

Thanks.

You may also want to pay attention to these lines (if you are using
more then one SPI device that use different modes)

-- put spi into mode 11
if SD_ALWAYS_SET_SPI_MODE == TRUE then
SSPCON_CKP = 1
SSPSTAT_CKE = 0
end if

All of my SPI libs use these lines so the devices can be used
together.

SD_ALWAYS_SET_SPI_MODE is defined in the sample.

Matt.

[Sebastien Lelong]

OK, thanks for pointing this. How can we solve this in order sd_card.jal to be fully generic ? I remember we have the exact same problem with ethernet libs.

Cheers,

Seb

2011/4/19 mattschinkel <mattsc...@hotmail.com>

Matt.

--
You received this message because you are subscribed to the Google Groups "jallib" group.
To post to this group, send email to jal...@googlegroups.com.
To unsubscribe from this group, send email to jallib+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/jallib?hl=en.

--
Sébastien Lelong
http://www.sirloon.net
http://sirbot.org

[mattschinkel]

I prefer to take the spi init procedure and split it into two.

spi_master_hw_set_mode(byte in mode)
spi_master_hw_set_speed(byte in speed)

The set speed procedure may not be used as often, however there are
some devices that require SPI commands to be slower then SPI data
transfers. For example, mp3 decoder vs1053b

Then add another alias to the sample

alias spi_master_set_mode is spi_master_hw_set_mode

Matt.

On Apr 19, 6:42 am, Sebastien Lelong <sebastien.lel...@gmail.com>
wrote:

> OK, thanks for pointing this. How can we solve this in order sd_card.jal to
> be fully generic ? I remember we have the exact same problem with ethernet
> libs.
>
> Cheers,
> Seb
>

> 2011/4/19 mattschinkel <mattschin...@hotmail.com>

[mattschinkel]

Here are some sample includes for samples that I use. Alias takes few
extra lines and is quite effective for generic libs.

include spi_master_hw -- includes the spi library
-- define spi inputs/outputs
pin_sdi_direction = input -- spi input
pin_sdo_direction = output -- spi output
pin_sck_direction = output -- spi clock
--
spi_init(SPI_MODE_11,SPI_RATE_FOSC_4) -- init spi, choose mode and
speed
alias spi_master is spi_master_hw

-----------------------------------

alias spi_master_sw_sdi is pin_sdi
alias spi_master_sw_sdi_direction is pin_sdi_direction
alias spi_master_sw_sdo is pin_sdo
alias spi_master_sw_sdo_direction is pin_sdo_direction
alias spi_master_sw_sck is pin_sck
alias spi_master_sw_sck_direction is pin_sck_direction
-- define spi inputs/outputs
spi_master_sw_sdi_direction = input -- spi input
spi_master_sw_sdo_direction = output -- spi output
spi_master_sw_sck_direction = output -- spi clock
--
include spi_master_sw
spi_init(SPI_MODE_11) -- init spi, choose mode
alias spi_master is spi_master_sw

-------------------------------------

-- setup uart for communication
const serial_hw_baudrate = 115200 -- set the baudrate
include serial_hardware
serial_hw_init()
-- some aliases so it is easy to change from serial hw to serial sw.
alias serial_write is serial_hw_write
alias serial_read is serial_hw_read
alias serial_data is serial_hw_data
alias serial_data_available is serial_hw_data_available

--------------------------------------

-- setup serial software
const serial_sw_baudrate = 115200
alias serial_sw_tx_pin is pin_B4
alias serial_sw_rx_pin is pin_B5
pin_B4_direction = output
pin_B5_direction = input
include serial_software
serial_sw_init()
-- some aliases so it is easy to change from serial hw to serial sw.
alias serial_write is serial_sw_write
alias serial_read is serial_sw_read
alias serial_data is serial_sw_data


PS: I have many of these snippets made up if you need them for Jaluino
IDE.
PS#2: Let me know when you get more Jaluino boards :)

Matt.

[Sebastien Lelong]

2011/4/19 mattschinkel <mattsc...@hotmail.com>

Here are some sample includes for samples that I use. Alias takes few
extra lines and is quite effective for generic libs.

Yeah I've seen these several times in your libs.

 

PS: I have many of these snippets made up if you need them for Jaluino
IDE.

Yes, though Editra code snippets aren't as powerfull as VI's. I recently played with VI, kind of porting Jaluino IDE features under this editor (and even add inline API documentation). So, I'm not 100% sure about code snippets in Jaluino IDE / Editra...

 

PS#2: Let me know when you get more Jaluino boards :)

Well, I got few here, but this is version v1.0: there are several mistakes I did in schematic. As I test my PCB, I fix these mistakes, I hope to be able to order a new & better batch soon. For instance, I added a lot of optional pull-ups on many pins, as SPI & I²C can be used on many different pins depending on the device being used. For now, I built 3 Jaluino Bee boards, with more or less "green wire" fixes, using 18F27J53 (really cool chip), 18F25K22 or 18F2550 with: blink-a-led, serial hardware on both RX1/TX1 and RX2/TX2, USB serial & HID, RTCC, PPS, and SD-card (and this one was a big one). I couldn't succesfully test USB bootloader, it seems program memory isn't programmed the same way and current existing code isn't compatible AFAIK. I still need to test Xbee connections. 18F27J53 is the one requiring the most fixes, while 18F25K22 and 18F2550 requires an extra diode.

To be continued...

Cheers,

Seb

[Sebastien Lelong]

2011/4/19 mattschinkel <mattsc...@hotmail.com>

I prefer to take the spi init procedure and split it into two.

OK, do you want me to take care of this ?

Cheers,

Seb

[mattschinkel]

Sure, and also check if pragma inline is a good idea.

Matt.

On Apr 19, 12:33 pm, Sebastien Lelong <sebastien.lel...@gmail.com>
wrote:
> 2011/4/19 mattschinkel <mattschin...@hotmail.com>

[Sebastien Lelong]

Hi Matt,

Some more feedback about current sd_card.jal library:

  - send_command() should be prefixed with sd_send_command() to avoid potential collision

  - I wanted to use sd_data_byte, to read card byte by byte, but it seems already "infected" by some filesystems stuff: it increment a counter related to sector, dealing with 512 bytes. 

  - in the same procedure, there seems to be special values when reading SPI (eg. 0xFE). What if I need to read these values ? I don't understand the following loop:

   if sd_byte_count == 0 then               -- beginning of sector read

      while spi_master != 0xFE loop      -- wait till data is ready to read

      end loop

   end if

Basically this is why my sample doesn't work, commenting the "while" loop fixes the issue.

Shouldn't I use this procedure ? Shouldn't it be completely independent from filesystem concerns ?

Thanks for your light !

Cheers,

Seb

2011/4/19 mattschinkel <mattsc...@hotmail.com>

Sure, and also check if pragma inline is a good idea.

--

[Sebastien Lelong]

OK, I can see many things about sectors of 512 bytes, this doesn't fit my need at all, as I need 1024 bytes / sectors. I'd say sd_card library shouldn't have anything related to sectors or the like, as it is something related to file systems, and you may just use your SD-Card without considering any of these.

But since I'm no SD expert, there could be a reason to do so. Still, setting address with sd_start_read(sector) ends with accessing SD-card on a byte-level, not sector.

Cheers,

Seb 

2011/4/20 Sebastien Lelong <sebastie...@gmail.com>

[Sebastien Lelong]

Oh... sorry for the noise, I did a mistake about minix paritions and wasn't reading the correct bytes. I also noticed extra bytes as the end of 512-bytes, I guess this is about CRC check according to comments. Anyway, I understand SD-card uses internal 512-bytes, not related to some higher level of sectors (filesystem's).

Right ?

[mattschinkel]

>   - send_command() should be prefixed with sd_send_command() to avoid
> potential collision

Your right, I didn't notice this.

What if I need to read these values ? I don't understand the
> following loop:
>
>    if sd_byte_count == 0 then               -- beginning of sector read
>       while spi_master != 0xFE loop      -- wait till data is ready to read
>       end loop
>    end if
>
> Basically this is why my sample doesn't work, commenting the "while" loop
> fixes the issue.

Before a sector is ready to read, you should get one 0xFE.
Sector size is almost always 512 on hard disks and sd cards.
After a sector read, there are two CRC bytes.

Yes, you should read in 512 byte chunks and must write in 512 byte
chunks. I think some sd cards do support byte by byte reads/writes. I
have not looked into it.

I guess this method was chosen for speed of PC's, and smaller
addressing.

Matt.

[mattschinkel]

Here's some more info for you, from the datasheet:

In the case of a Standard Capacity Memory Card, a data block can be as
big as one card write block
and as small as a single byte. Partial block read/write operations are
enabled by card options specified
in the CSD register.
In the case of a High Capacity SD Memory Card, the size of data block
is fixed to 512 bytes. The block
length set by CMD16 is only used for CMD42 and not used for memory
data transfer. So, partial block
read/write operations are also disabled. Furthermore, Write Protected
commands (CMD28, CMD29 and
CMD30) are not supported.

Set Block Length
When memory read and write commands are used in block address mode,
512-byte fixed
block length is used regardless of the block length set by CMD16. The
setting of the block
length does not affect the memory access commands. CMD42 is not
classified as a memory
access command. The data block size shall be specified by CMD16 and
the block length can
be set up to 512 bytes. Setting block length larger than 512 bytes
sets the
BLOCK_LEN_ERROR error bit regardless of the card capacity.

From my lib:
address = address * 512 -- make sd card sector addressable, sd cards
are normally byte addressable.

My comment is not completely true. SD Cards ARE normally byte
addressable, but for fat32 and PC's, there is never a need to start in
the middle of a 512 byte chunk and end in the middle of the next.

For example, you could start a read at byte 256 of the sd card, and
end at byte 512 + 256 (which is 512 bytes read total)

FAT32 and PC's assume the first sector starts at byte 0 and the next
sector is at byte 512

My conclusion:
You can start reading or writing a block from anywhere, but have to
read/write an entire block, default block size is 512 (one sector).
I'm not sure if there's another way to read/write other then block
mode. We could improve the library by looking into this or to set a
block size of 1 byte and add a constant for the user.

512 should stay default, byte reads/writes may not work at all on high
capacity SD memory cards. I don't think I tried any high capacity
cards yet with this lib.

Filesystems usually assume sectors are 512 bytes. From what I
understand, hard disks always use 512 byte sectors. Hard disks have a
read/write buffer that is 512 bytes.

I would have to ask the user: why not just use 23k256 instead of sd
card for byte reads/writes?

What are your thoughts on this?

Matt.

[Sebastien Lelong]

Hi Mat,

thanks for your explanations

2011/4/21 mattschinkel <mattsc...@hotmail.com>

From my lib:
address = address * 512 -- make sd card sector addressable, sd cards
are normally byte addressable.

My comment is not completely true. SD Cards ARE normally byte
addressable, but for fat32 and PC's, there is never a need to start in
the middle of a 512 byte chunk and end in the middle of the next.

For example, you could start a read at byte 256 of the sd card, and
end at byte 512 + 256 (which is 512 bytes read total)

OK, I now understand but...

 

FAT32 and PC's assume the first sector starts at byte 0 and the next
sector is at byte 512

... this means sd_card is "infected" (no offense :)) with FAT32 concerns. Not a big deal in this case (start at 0, assume next is at 512), because filesystems blocks are mutiple of 512. But if there's something more FAT32-specific, it should be removed to be as generic as possible, so other can build on top of it without finding weird workaround. AFAIK there's currently no such case !

My conclusion:
You can start reading or writing a block from anywhere, but have to
read/write an entire block, default block size is 512 (one sector).
I'm not sure if there's another way to read/write other then block
mode. We could improve the library by looking into this or to set a
block size of 1 byte and add a constant for the user.

But you can actually read byte-by-byte, using sd_data_byte pseudo-var ? You don't necessarily have to deal with a 512-bytes buffer.

 

512 should stay default, byte reads/writes may not work at all on high
capacity SD memory cards. I don't think I tried any high capacity
cards yet with this lib.

I remember some were having troubles with 4GB, which I think is classified High Capacity. Maybe there's something wrong with HC and the lib ?

 

Filesystems usually assume sectors are 512 bytes. From what I
understand, hard disks always use 512 byte sectors. Hard disks have a
read/write buffer that is 512 bytes.

Hard-disk may have 512 buffer, but lot all filesystems assume 512. I'd even say 512 is quite small for a filesystem ! Minix for instance defaults to 1K. I can be set higher to 2K, 4K. The higher the easier it is to index (that's why I said 512 seems very small).

 

I would have to ask the user: why not just use 23k256 instead of sd
card for byte reads/writes?

Because of yet another part ? And because it's RAM ? (I mean, it's volatile, right ?)

Cheers,

Seb

[Sebastien Lelong]

Hi guys,

2011/4/21 mattschinkel <mattsc...@hotmail.com>

I would have to ask the user: why not just use 23k256 instead of sd
card for byte reads/writes?

Has anyone tried SST Serial Flash ? It seems cheaper than 23K and much bigger.

http://www.microchip.com/ParamChartSearch/chart.aspx?branchID=71201&mid=&lang=en

Cheers,

Seb 

[Oliver Seitz]

>Has anyone tried SST Serial Flash ? It seems cheaper than 23K and much bigger.

I've used 24LC256, 32kByte EEPROM, 8 chips totalling to 0.25MByte on one PCB. It's connected via I2C. Works fine. If more memory was required, I wanted to use SD card, for it is far cheaper per byte...

Page size of 64 byte has only to be observed while writing, reading consecutive or adressed bytes is easily possible, one chip at a time.

Greets,
Kiste

[mattschinkel]

> But you can actually read byte-by-byte, using sd_data_byte pseudo-var ? You
> don't necessarily have to deal with a 512-bytes buffer.

Yes, you can maybe read byte-by-byte, but you can't write byte-by-
byte. You have to write the entire block.

> ... this means sd_card is "infected" (no offense :)) with FAT32 concerns.
> Not a big deal in this case (start at 0, assume next is at 512), because
> filesystems blocks are mutiple of 512. But if there's something more
> FAT32-specific, it should be removed to be as generic as possible, so other
> can build on top of it without finding weird workaround. AFAIK there's
> currently no such case !

If you want, we can add some user constants and improve the lib.

Maybe this:

address = address * 512

can be changed to this:
address = address * SD_BLOCK_SIZE

SD_BLOCK_SIZE would be a optional user constant. The init procedure
can tell the sd card what block size to use. It will only work on
standard sized sd cards.

Is there a need for block size to be variable? Is there a need for
blocks to not start at byte 0?

Adding this feature may be desirable (with warning about HC cards). Do
you also wish that fat32 could use smaller blocks?

> > I would have to ask the user: why not just use 23k256 instead of sd
> > card for byte reads/writes?
>
> Because of yet another part ? And because it's RAM ? (I mean, it's volatile,
> right ?)

I guess I meant that there are other parts out there, eeproms, etc
that would also serve the purpose. But SD cards are cheap these days.

Would anyone use a soldered on sd card in a final design?

Anyone with a final design with a removable sd card will not want to
limit the design to standard capacity cards. Eventually there may not
be any more standard capacity cards on the market, and so, the design
maker should use blocks that are 512 bytes.

> I remember some were having troubles with 4GB, which I think is classified
> High Capacity. Maybe there's something wrong with HC and the lib ?

I didn't notice anyone say they have a 4gb or larger card, and it is
noted in my lib. This does need to be tested.

a block size of 1 will allow the user to access a max of 4.294 GB
(this is why HC cards are set to a block size of 512)
a block size of 512 will allow the user to access 2199.023 GB

Matt.

[Sebastien Lelong]

2011/4/21 mattschinkel <mattsc...@hotmail.com>

> But you can actually read byte-by-byte, using sd_data_byte pseudo-var ? You
> don't necessarily have to deal with a 512-bytes buffer.

Yes, you can maybe read byte-by-byte, but you can't write byte-by-
byte. You have to write the entire block.

OK

 

> ... this means sd_card is "infected" (no offense :)) with FAT32 concerns.
> Not a big deal in this case (start at 0, assume next is at 512), because
> filesystems blocks are mutiple of 512. But if there's something more
> FAT32-specific, it should be removed to be as generic as possible, so other
> can build on top of it without finding weird workaround. AFAIK there's
> currently no such case !

If you want, we can add some user constants and improve the lib.

As far I can see, and now that I better understand, I don't see such need anymore...

 

Maybe this:
address = address * 512

can be changed to this:
address = address * SD_BLOCK_SIZE

... though using SD_BLOCK_SIZE instead of hard-coded 512 is always a good idea :)

This leaves room for easy experiments about this parameter.

 

Is there a need for block size to be variable? Is there a need for
blocks to not start at byte 0?

No, I'd say there's no need not to start at 0, if you're using a "standard" filesystem (I mean FS using mutliple of 512)

 

Adding this feature may be desirable (with warning about HC cards). Do
you also wish that fat32 could use smaller blocks?

No, and I'm not sure what would be the benefit ?

Cheers,

Seb

[Oliver Seitz]

> Would anyone use a soldered on sd card in a final design?

For $0.03 per MByte, including card holder? Yes, I would, bien sure. (oops, that was french :-)

Especially if I stored raw data without any file system, I would make a SD-card non-replaceable. At least noone would ask me then how to read that card on his windows machine. Discrete memory chips are harder to come by, more expensive and often take more board space, so why shouldn't I solder on a SD-card?

Greets,
Kiste

[mattschinkel]

Great, so I may just add that optional constant SD_BLOCK_SIZE

You should also be careful about stopping your reads in the middle of
a block. I think the working (but not proper) way to stop in the
middle of a block is to de-activate the chip select line. If the chip
select line stays active, the sd card will assume the next thing you
try to do is a read. Even if you are trying to send a command.

The proper way of course is to just dummy read the rest of the block.

I do wish to improve the lib and I very much appreciate your input!

Matt.

[Sebastien Lelong]

2011/4/21 mattschinkel <mattsc...@hotmail.com>

Great, so I may just add that optional constant SD_BLOCK_SIZE

OK

 

You should also be careful about stopping your reads in the middle of
a block. I think the working (but not proper) way to stop in the
middle of a block is to de-activate the chip select line. If the chip
select line stays active, the sd card will assume the next thing you
try to do is a read. Even if you are trying to send a command.

The proper way of course is to just dummy read the rest of the block.

OK. I'm currently using sd_stop_read(), so I guess this isn't the proper way as it doesn't read remaining block's bytes.

 

I do wish to improve the lib and I very much appreciate your input!

I'll give feedback as much as I can, but I'm not completely understanding SD-cards and just stick to available API :)

Cheers,

Seb

 

[mattschinkel]

Another thing that is a bit of a pain, is that the chip select line
must stay active during your entire read. You can't read a few bytes
then store them onto a separate SPI memory like 23k256 and then
continue reading from where you left off.

Maybe a look in the specification will tell you if it is ok to stop
reading by de-activating the chip select line. I don't really know for
sure. I suppose the stop read procedure does make the chip select line
go inactive.

I guess I never really had a need for partial reads :)

Matt.

On Apr 21, 4:13 am, Sebastien Lelong <sebastien.lel...@gmail.com>
wrote:
> 2011/4/21 mattschinkel <mattschin...@hotmail.com>

[Sebastien Lelong]

It seems SST serial flash (say SST25VF010A, 1Mb for $0.38 volume pricing, vs. $0.96 for 23K256) is pin-compatible with 23K256. Except for Write-Protection pin. I need to check this in datasheet to see if it's optional.

I'll add it to my current design.

Cheers,

Seb

2011/4/21 Oliver Seitz <karl...@yahoo.com>

--
You received this message because you are subscribed to the Google Groups "jallib" group.
To post to this group, send email to jal...@googlegroups.com.
To unsubscribe from this group, send email to jallib+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/jallib?hl=en.

[mattschinkel]

I perfer the RAM due to fast read/write speeds, high endurance. Does
SST have any serial ram? What is the write speed of SST flash?

Matt.

On Apr 21, 1:48 pm, Sebastien Lelong <sebastien.lel...@gmail.com>
wrote:

> It seems SST serial flash (say SST25VF010A, 1Mb for $0.38 volume pricing,
> vs. $0.96 for 23K256) is pin-compatible with 23K256. Except for
> Write-Protection pin. I need to check this in datasheet to see if it's
> optional.
>
> I'll add it to my current design.
>
> Cheers,
> Seb
>

> 2011/4/21 Oliver Seitz <karlki...@yahoo.com>

>
>
>
>
>
>
>
> > >Has anyone tried SST Serial Flash ? It seems cheaper than 23K and much
> > bigger.
>
> > I've used 24LC256, 32kByte EEPROM, 8 chips totalling to 0.25MByte on one
> > PCB. It's connected via I2C. Works fine. If more memory was required, I
> > wanted to use SD card, for it is far cheaper per byte...
>
> > Page size of 64 byte has only to be observed while writing, reading
> > consecutive or adressed bytes is easily possible, one chip at a time.
>
> > Greets,
> > Kiste
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "jallib" group.
> > To post to this group, send email to jal...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > jallib+un...@googlegroups.com.
> > For more options, visit this group at
> >http://groups.google.com/group/jallib?hl=en.
>
> --

> Sébastien Lelonghttp://www.sirloon.nethttp://sirbot.org- Hide quoted text -
>
> - Show quoted text -

[Oliver Seitz]

> I perfer the RAM due to fast
> read/write speeds, high endurance. Does
> SST have any serial ram? What is the write speed of SST
> flash?

I was about to write that... But then I realized that both chips were pin compatible, so the PCB would work with ram or flash ;-)

Greets,
Kiste

[Sebastien Lelong]

Hum... I didn't realize this difference...

:)

Seb

2011/4/21 Oliver Seitz <karl...@yahoo.com>

Greets,
Kiste

--
You received this message because you are subscribed to the Google Groups "jallib" group.
To post to this group, send email to jal...@googlegroups.com.
To unsubscribe from this group, send email to jallib+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/jallib?hl=en.

--

[Sebastien Lelong]

Hi Matt, guys,

I'm experiencing troubles implementing Minix filesystem over sd card. For some reason I can't  find, reading a big file (64MB) always gets stuck at the exact same location.

I can't dive into Minix internals here, but filesystem is divided into 1KB block. Addresses where data actually lies are located on zones. When files is becoming large, you need to read some indirect data addresses (and even double indirect). So, when reading content, block addresses are read like this:

block 0x3250 => 1KB data

block 0x3251 => 1KB data

block 0x3252 => 1KB data

...

then nothing :(

Digging this, I discovered the data location address isn't 0x3253 as expected (I checked with hexdump, this is the next data location for sure), but, instead, it is 0x3253FEFF ! This means while reading address on sd card, it seems some sd card internal bytes were returned, instead of actual data (0xFE and 0xFF are some kind of meaningful internal bytes IIUC).

Does this make sense to you ? I really can't figure out why it occurs at this time. And it is always, strictly always the same location.

TIA

Cheers,

Seb

2011/4/21 Sebastien Lelong <sebastie...@gmail.com>

[mattschinkel]

It could be from the start of a sector or CRC bytes but you would not
get them unless you are starting or stopping reads incorrectly.

Look for 0xFE in sd_data_byte'get()

Matt.

On Apr 28, 10:27 am, Sebastien Lelong <sebastien.lel...@gmail.com>
wrote:

> Hi Matt, guys,
>
> I'm experiencing troubles implementing Minix filesystem over sd card. For
> some reason I can't  find, reading a big file (64MB) always gets stuck at
> the exact same location.
>
> I can't dive into Minix internals here, but filesystem is divided into 1KB
> block. Addresses where data actually lies are located on zones. When files
> is becoming large, you need to read some indirect data addresses (and even
> double indirect). So, when reading content, block addresses are read like
> this:
>
> block 0x3250 => 1KB data
> block 0x3251 => 1KB data
> block 0x3252 => 1KB data
> ...
> then nothing :(
>
> Digging this, I discovered the data location address isn't 0x3253 as
> expected (I checked with hexdump, this is the next data location for sure),
> but, instead, it is 0x3253FEFF ! This means while reading address on sd
> card, it seems some sd card internal bytes were returned, instead of actual
> data (0xFE and 0xFF are some kind of meaningful internal bytes IIUC).
>
> Does this make sense to you ? I really can't figure out why it occurs at
> this time. And it is always, strictly always the same location.
>
> TIA
> Cheers,
> Seb
>

> 2011/4/21 Sebastien Lelong <sebastien.lel...@gmail.com>

>
>
>
> > Hum... I didn't realize this difference...
>
> > :)
>
> > Seb
>

> > 2011/4/21 Oliver Seitz <karlki...@yahoo.com>

>
> >> > I perfer the RAM due to fast
> >> > read/write speeds, high endurance. Does
> >> > SST have any serial ram? What is the write speed of SST
> >> > flash?
>
> >> I was about to write that... But then I realized that both chips were pin
> >> compatible, so the PCB would work with ram or flash ;-)
>
> >> Greets,

> >> Kiste- Hide quoted text -

[mattschinkel]

Why did you decide to read 4 bytes (0x3253FEFF) instead of two
(0x3253)?

What are the next bytes if you read after 0x3253FEFF?

Matt.

[Sebastien Lelong]

I read data location from zone addresses. These are 32-bits long, that's why I need to read 4 bytes. It should read 0x00003253 (as it previously read 0x00003252).

I can't read anything after 0x3253FEFF, because this address is beyond my sd card's bounds. 3253FEFF is the address of a block, blocks are 1KB, this would give 800GB while my SD is 1GB :) that's why it gets stucks here.

I'll perform more tests, and try to close SD card sector every 512 bytes (it is required, right ?). I just can't understand why this address seems particular, but other troubles may be hidden by not properly closing sd sectors.

Cheers,

Seb

2011/4/28 mattschinkel <mattsc...@hotmail.com>

--
You received this message because you are subscribed to the Google Groups "jallib" group.
To post to this group, send email to jal...@googlegroups.com.
To unsubscribe from this group, send email to jallib+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/jallib?hl=en.

[Sebastien Lelong]

2011/4/29 Sebastien Lelong <sebastie...@gmail.com>

I'll perform more tests, and try to close SD card sector every 512 bytes (it is required, right ?)

Doesn't work either, still stuck on the same location. I also tried to directly move (seek) just before, avoiding long reading before getting there, and it gets stuck too. Moving just after works perfectly, I can read the remaining data (~56MB).

I've just also tried to move just before the problematic location, and manually read content, that is, directly read contiguous data bytes, and... it works, I can read several blocks after ! This means my adressing logic is buggy...

cheers,

Seb

 

2011/4/28 mattschinkel <mattsc...@hotmail.com>

Why did you decide to read 4 bytes (0x3253FEFF) instead of two
(0x3253)?

What are the next bytes if you read after 0x3253FEFF?

Matt.

--
You received this message because you are subscribed to the Google Groups "jallib" group.
To post to this group, send email to jal...@googlegroups.com.
To unsubscribe from this group, send email to jallib+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/jallib?hl=en.

--
Sébastien Lelong
http://www.sirloon.net
http://sirbot.org

[mattschinkel]

> I'll perform more tests, and try to close SD card sector every 512 bytes (it
> is required, right ?).

No, you don't have to stop a sector read every 512 bytes. Just don't
stop in the middle of a sector.

Matt.

[Sebastien Lelong]

I'm starting to suspect some troubles with my SD card. I've tried to create a new copy of my big 64MB file, that is, putting data onto other locations. So far it's been reading 14MB (> 8MB causing probllems) with success...

Cheers,

Seb

2011/4/29 mattschinkel <mattsc...@hotmail.com>

Matt.

--
You received this message because you are subscribed to the Google Groups "jallib" group.
To post to this group, send email to jal...@googlegroups.com.
To unsubscribe from this group, send email to jallib+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/jallib?hl=en.

[Sebastien Lelong]

Spoke too fast... I can't my big file anymore, it gets stucks after ~10MB. It worked once before...

Seb

2011/4/29 Sebastien Lelong <sebastie...@gmail.com>

[mattschinkel]

What voltage are your running the PIC at? are you using voltage
dividers?

I can test on my SD card at any time if you provide hex from your
card. I would like to see your lib anyways and give feedback.

Matt.

On Apr 29, 3:50 pm, Sebastien Lelong <sebastien.lel...@gmail.com>
wrote:

> Spoke too fast... I can't my big file anymore, it gets stucks after ~10MB.
> It worked once before...
>
> Seb
>

> 2011/4/29 Sebastien Lelong <sebastien.lel...@gmail.com>

>
> > I'm starting to suspect some troubles with my SD card. I've tried to create
> > a new copy of my big 64MB file, that is, putting data onto other locations.
> > So far it's been reading 14MB (> 8MB causing probllems) with success...
>
> > Cheers,
> > Seb
>

> > 2011/4/29 mattschinkel <mattschin...@hotmail.com>

[Sebastien Lelong]

Hi Matt,

PIC is running at 3.3V, no voltage dividers. And no pull-ups either.

In order to test my lib, you'll need a Linux box. If you want to have a better overview, comments at the beginning of the lib will help prepare the filesystem. There's also some testing data available on jaluino repository, you can untar the archive to play with the files. I they are specially designed to show data accross blocks, help understand how data zones (direct, indirect, double indirect) are accessed.

If you want to give a try, let me know, I'll give more instructions.

Cheers,

Seb

2011/4/30 mattschinkel <mattsc...@hotmail.com>

[mattschinkel]

Maybe try large files on FAT32 to see if you have the same issue.

Matt.

[Sebastien Lelong]

but i can't make fat32 work ;)
i'll try to dump raw content of my sd card, bypassing fileqystem logic
in order to see if there's something on sd car level.
seb
--
Sébastien Lelong

Le 30 avr. 2011 à 18:36, mattschinkel <mattsc...@hotmail.com> a
écrit :

> Maybe try large files on FAT32 to see if you have the same issue.
>
> Matt.
>

[mattschinkel]

What about the normal FAT32 lib? It supports any cluster size.

Matt.

On Apr 30, 12:55 pm, Sebastien Lelong <sebastien.lel...@gmail.com>
wrote:

> but i can't make fat32 work ;)
> i'll try to dump raw content of my sd card, bypassing fileqystem logic  
> in order to see if there's something on sd car level.
> seb
> --
> Sébastien Lelong
>

> Le 30 avr. 2011 à 18:36, mattschinkel <mattschin...@hotmail.com> a  

> écrit :
>
>
>
> > Maybe try large files on FAT32 to see if you have the same issue.
>
> > Matt.
>
> > --
> > You received this message because you are subscribed to the Google  
> > Groups "jallib" group.
> > To post to this group, send email to jal...@googlegroups.com.
> > To unsubscribe from this group, send email to jallib+un...@googlegroups.com
> > .
> > For more options, visit this group athttp://groups.google.com/group/jallib?hl=en

> > .- Hide quoted text -

[mattschinkel]

Seb, I finally found time to fix the FAT32_SMALL cluster size issue.
Give it a try!

Matt.

[Sebastien Lelong]

Hi Matt,

Thanks for your effort, but this is still the same, fat32 get stuck within init procedure. I guess this is due to my fat32 partition, something is wrong with it. Included is an partial hexdump of my partition, showing content but only when changing. Format is:

address  b1 b2 b3 b4 b5 b6 b7 b8  b9 b0 b1 b2 b3 b4 b5 b6  |ascii ascii asci|

(b0 is b10, then b1 is b11, etc...)

If content didn't change, you'll get "*"

If you have time (and only if), you might be able to what's going on by looking at addresses and content in order to see if data is wrong or not. Careful: there may be data residues from previous experiments (but you should be able to read important sectors in fat32)

TIA

Cheers,

Seb

2011/5/2 mattschinkel <mattsc...@hotmail.com>

[mattschinkel]

Seb, can you please provide a file that contains actual data? not
ascii hex.

I haven't tried this, but maybe you can find what device it is in /
dev/ and copy it with "cp" command to a file. I'll download it from
your server.

This needs to be fixed :)

Matt.

On May 2, 3:51 am, Sebastien Lelong <sebastien.lel...@gmail.com>
wrote:

> Hi Matt,
>
> Thanks for your effort, but this is still the same, fat32 get stuck within
> init procedure. I guess this is due to my fat32 partition, something is
> wrong with it. Included is an partial hexdump of my partition, showing
> content but only when changing. Format is:
>
> address  b1 b2 b3 b4 b5 b6 b7 b8  b9 b0 b1 b2 b3 b4 b5 b6  |ascii ascii
> asci|
>
> (b0 is b10, then b1 is b11, etc...)
>
> If content didn't change, you'll get "*"
>
> If you have time (and only if), you might be able to what's going on by
> looking at addresses and content in order to see if data is wrong or not.
> Careful: there may be data residues from previous experiments (but you
> should be able to read important sectors in fat32)
>
> TIA
> Cheers,
> Seb
>

> 2011/5/2 mattschinkel <mattschin...@hotmail.com>

>
> > Seb, I finally found time to fix the FAT32_SMALL cluster size issue.
> > Give it a try!
>
> > Matt.
>
>
>

>  sdcfat32.zip
> 285KViewDownload

[Sebastien Lelong]

Hi Matt,

BTW, I found some potential issue, or at least waste of code in sd_card.jal lib:

Here's the guilty function:

---

function sd_data_byte'get() return byte is

   var byte x, data_byte

   if sd_byte_count == 0 then               -- beginning of sector read

      while spi_master != 0xFE loop      -- wait till data is ready to read

      end loop

   end if

   data_byte = spi_master                -- get data byte

   if sd_byte_count == 512 then             -- end of sector read

      sd_sector_count = sd_sector_count + 1 -- increment sector number

      x = spi_master                     -- get junk crc data, crc is disabled

      x = spi_master                     -- get junk crc data, crc is disabled

   end if

   sd_byte_count = sd_byte_count + 1 -- increment byte_count

   if sd_byte_count == 512 then

      sd_byte_count = 0

   end if

   

   return data_byte

end function

---

When sd_byte_count = 511:

  - enter the function

  - you read data from spi

  - sd_byte_count is incremented, now is 512

  - since it's 512, it then sets to 0 (last "if")

As a consequence:

   if sd_byte_count == 512 then             -- end of sector read

      sd_sector_count = sd_sector_count + 1 -- increment sector number

      x = spi_master                     -- get junk crc data, crc is disabled

      x = spi_master                     -- get junk crc data, crc is disabled

   end if

nerver gets executed.

Am I right ?

Cheers,

Seb

2011/5/2 Sebastien Lelong <sebastie...@gmail.com>

[Sebastien Lelong]

Just a follow-up on this.

This is an actual *issue* IMHO, and the reason why I've never been able to read beyond some address! If I modify the function so CRC bytes are actually read when reaching end of sector, it works !

function sd_data_byte'get() return byte is

   var byte x, data_byte

   if sd_byte_count == 0 then            -- beginning of sector read                                                                                                               

      while spi_master != 0xFE loop      -- wait till data is ready to read

      end loop

   end if

   data_byte = spi_master                -- get data byte

   sd_byte_count = sd_byte_count + 1     -- increment byte_count

   if sd_byte_count == 512 then          -- end of sector read

      sd_byte_count = 0

      sd_sector_count = sd_sector_count + 1 -- increment sector number

      x = spi_master                     -- get junk crc data, crc is disabled

      x = spi_master                     -- get junk crc data, crc is disabled

   end if

   return data_byte

end function

Matt, can you confirm there's a trouble here ?

Cheers,

[mattschinkel]

Thanks Seb, hopefully this will fix some issues. It's funny how I
never had an issue!

I'll have to check the 'put proc as well.

Matt.

On May 2, 11:47 am, Sebastien Lelong <sebastien.lel...@gmail.com>
wrote:

> 2011/5/2 Sebastien Lelong <sebastien.lel...@gmail.com>

> > 2011/5/2 Sebastien Lelong <sebastien.lel...@gmail.com>

>
> >> Hi Matt,
>
> >> Thanks for your effort, but this is still the same, fat32 get stuck within
> >> init procedure. I guess this is due to my fat32 partition, something is
> >> wrong with it. Included is an partial hexdump of my partition, showing
> >> content but only when changing. Format is:
>
> >> address  b1 b2 b3 b4 b5 b6 b7 b8  b9 b0 b1 b2 b3 b4 b5 b6  |ascii ascii
> >> asci|
>
> >> (b0 is b10, then b1 is b11, etc...)
>
> >> If content didn't change, you'll get "*"
>
> >> If you have time (and only if), you might be able to what's going on by
> >> looking at addresses and content in order to see if data is wrong or not.
> >> Careful: there may be data residues from previous experiments (but you
> >> should be able to read important sectors in fat32)
>
> >> TIA
> >> Cheers,
> >> Seb
>

> >> 2011/5/2 mattschinkel <mattschin...@hotmail.com>

[Sebastien Lelong]

Indeed, funny :)

I really should have encountered this problem in any block (1KB = 2 * 512 sectors) reading... Pretty weird.

Cheers,

Seb

2011/5/2 mattschinkel <mattsc...@hotmail.com>

Thanks Seb, hopefully this will fix some issues. It's funny how I

[Sebastien Lelong]

Hi guys,

I added an optional SPI EEPROM (SOIC package) to Jaluino Bee. It's also pin compatible with 23K256 SRAM, and also with a SST serial flash. So PCB would work with an extra EEPROM, SRAM and Flash.

I added a 100nF decoupling cap. /WP (Write Protect) and /HOLD (pause) are tied to 3V3, so always enabled (so no write protect, and no hold/pause) in order to save few pins. Solder jumper is here to choose the Chip-Select pin depending on the PIC being used (25K22 or 27J53)

Cheers,

Seb

2011/4/21 Oliver Seitz <karl...@yahoo.com>

[mattschinkel]

Very good Seb, just remember not to allow SD chip select to go
inactive in the middle of a sector.

Matt.

On May 3, 4:58 am, Sebastien Lelong <sebastien.lel...@gmail.com>
wrote:

> Hi guys,
>
> I added an optional SPI EEPROM (SOIC package) to Jaluino Bee. It's also pin
> compatible with 23K256 SRAM, and also with a SST serial flash. So PCB would
> work with an extra EEPROM, SRAM and Flash.
>
> I added a 100nF decoupling cap. /WP (Write Protect) and /HOLD (pause) are
> tied to 3V3, so always enabled (so no write protect, and no hold/pause) in
> order to save few pins. Solder jumper is here to choose the Chip-Select pin
> depending on the PIC being used (25K22 or 27J53)
>
> [image: spi_eeprom_sram.png]
>
> Cheers,
> Seb
>

> 2011/4/21 Oliver Seitz <karlki...@yahoo.com>

>
>
>
> > > I perfer the RAM due to fast
> > > read/write speeds, high endurance. Does
> > > SST have any serial ram? What is the write speed of SST
> > > flash?
>
> > I was about to write that... But then I realized that both chips were pin
> > compatible, so the PCB would work with ram or flash ;-)
>
> > Greets,
> > Kiste
>
>
>

>  spi_eeprom_sram.png
> 13KViewDownload

[Sebastien Lelong]

ok thanks.
back on sd card, is there a way to read and write at the same time, I
mean, do I have to stop_read/start_write and stop_write/start_read to
switch between 2 modes, or is there something easier ?
also, is it possible to partial partial sector ? (though I think I
know the answer...)

tia
cheers
seb

--
Sébastien Lelong

Le 3 mai 2011 à 15:10, mattschinkel <mattsc...@hotmail.com> a
écrit :

[mattschinkel]

> is there a way to read and write at the same time, I  
> mean, do I have to stop_read/start_write and stop_write/start_read to  
> switch between 2 modes, or is there something easier ?

You will have to stop_read/start_write. I don't know of any other way.
Same thing for hard disks.

Keep hard disks in mind. This makes me ask, Will your lib support hard
disks? You may want to copy the aliases and method from the FAT32 lib.

> also, is it possible to partial partial sector ? (though I think I  
> know the answer...)

Just do stop read (inactive chip select). I don't think there is any
harm, but I didn't see any official doc on this. There may be
something in sd card specification. Maybe we can test on a few cards
to see if the result is the same.


This is from the top of fat32 lib. You may not need some. I see that
"fat32_word_count" and others are not being used in fat32 lib anymore,
I need to remove some lines.

-- data media selection
if (DATA_MEDIA == PATA_HARD_DISK) then
-- hard disk procedures
alias fat32_start_read is pata_hd_start_read -- get
hard disk ready for reading
alias fat32_stop_read is pata_hd_stop_read -- tell
hard disk we are done reading
alias fat32_start_write is pata_hd_start_write -- tell
hard disk we are done reading
alias fat32_stop_write is pata_hd_stop_write -- tell
hard disk we are done reading
alias fat32_raw_read_sector is pata_hd_read_sector -- read
one sector to sector buffer array
alias fat32_raw_read_sector_address is
pata_hd_read_sector_address -- read one sector to sector buffer
array
alias fat32_raw_write_sector is pata_hd_write_sector -- write
one sector from sector buffer array
alias fat32_raw_write_sector_address is
pata_hd_write_sector_address -- write one sector from sector
buffer array
alias fat32_set_idle is pata_hd_set_idle -- sets
hard disk to idle state
alias fat32_raw_data_byte is pata_hd_data_byte -- read
one data byte from storage device
alias fat32_read_pulse_byte is pata_hd_read_pulse_byte -- one
byte read pulse
-- hard disk vars
alias fat32_word_count is pata_hd_word_count -- number
of words read from current sector (byte var)
alias fat32_sector_buffer is pata_hd_sector_buffer -- sector
buffer array
alias fat32_sector_buffer_low is pata_hd_sector_buffer_low
alias fat32_sector_buffer_high is pata_hd_sector_buffer_high
elsif DATA_MEDIA == SD_CARD then
-- sd card procedures
alias fat32_start_read is sd_start_read -- get sd
card ready for reading
alias fat32_stop_read is sd_stop_read -- tell
sd card we are done reading
alias fat32_start_write is sd_start_write
alias fat32_stop_write is sd_stop_write -- tell
sd card we are done reading
alias fat32_raw_read_sector is sd_read_sector -- read
one sector to sector buffer array
alias fat32_raw_write_sector is sd_write_sector -- write
one sector from sector buffer array
alias fat32_raw_write_sector_address is
sd_write_sector_address -- write one sector from sector buffer
array
alias fat32_set_idle is sd_set_idle -- sets
sd card to idle state
alias fat32_raw_read_sector_address is sd_read_sector_address
alias fat32_read_pulse_byte is sd_read_pulse_byte -- one
byte read pulse
alias fat32_raw_data_byte is sd_data_byte -- read
one data byte from storage device
-- sd card vars
alias fat32_word_count is sd_word_count -- number
of words read from current sector (byte var)
alias fat32_sector_buffer is sd_sector_buffer -- sector
buffer array
alias fat32_sector_buffer_low is sd_sector_buffer_low
alias fat32_sector_buffer_high is sd_sector_buffer_high
end if

Matt.

[Sebastien Lelong]

2011/5/3 mattschinkel <mattsc...@hotmail.com>

> is there a way to read and write at the same time, I  
> mean, do I have to stop_read/start_write and stop_write/start_read to  
> switch between 2 modes, or is there something easier ?

You will have to stop_read/start_write. I don't know of any other way.
Same thing for hard disks.

OK

 

Keep hard disks in mind. This makes me ask, Will your lib support hard
disks? You may want to copy the aliases and method from the FAT32 lib.

I think it could be possible, though Minix v2 allows quite small size in total, so better suited to memory cards compared to what HD can offers. 

 

> also, is it possible to partial partial sector ? (though I think I  
> know the answer...)

Just do stop read (inactive chip select). I don't think there is any
harm, but I didn't see any official doc on this. There may be
something in sd card specification. Maybe we can test on a few cards
to see if the result is the same.

With "partial partial" I meant "write partial" :) Well I tested several options, without any success at all... I need to deal with a 512-bytes buffer for reading and writing operation.

Cheers,

Seb

[Oliver Seitz]

Keep hard disks in mind. This makes me ask, Will your lib support hard disks? You may want to copy the aliases and method from the FAT32 lib. I think it could be possible, though Minix v2 allows quite small size in total, so better suited to memory cards compared to what HD can offers.

CompactFlash cards are connected with an electrically PATA-compatible interface, so it is not strictly useable for hard disks only. Greets, Kiste

[mattschinkel]

It should be easy to implement hard disks, as shown above.

Although sd cards are smaller and easier to connect, someone may still
want to use a hard disk:

- faster
- not limited to write cycles

Matt.

[William]

Hi Matt,

On Apr 19, 5:08 am, mattschinkel <mattschin...@hotmail.com> wrote:
>
> > PS: I've also seen procedure_sd_read_512(), filling an array, index by
> > index ([0], [1], ...), resulting in 512 lines in the body. There sure must
> > be a reason, but I have to ask: why not using a loop ?
>
> Because it's faster. There is a constant in the sample for extra speed
> to use a non array loop. I think I made this a optional constant. Of
> course this uses much more program memory space.
>

You might want to consider a compromise -- don't unroll the entire
loop. Try unrolling 8 bytes. You may find it is nearly as fast yet
save a bunch of code space.

William

[Oliver Seitz]

> You might want to consider a compromise -- don't unroll the
> entire
> loop.  Try unrolling 8 bytes. You may find it is
> nearly as fast yet
> save a bunch of code space.

I'm not so sure - the speed is greatly increased because each field in the array is adressed by a _constant_ subscript. The loop version is not slow because of it's a loop. Loops are quite efficient in JAL. What takes quite some time is storing the values to the array using a _variable_ subscript.

Greets,
Kiste

[William]

I see, do we have numbers though? Isn't the spi I/O actually the
slowest part?

William

[Oliver Seitz]

> I see, do we have numbers
> though?  Isn't the spi I/O actually the
> slowest part?

Good point :-)
I had been thinking about that part of the fat lib with PATA in mind, where data is transferred in parallel and two bytes are read within six or seven processor cycles. When SPI is used, things could be significantly sped up by not using a generic "read and write" procedure, but a read-only-procedure. The read-and-write-procedure is called, transfers the "write" data, and waits until the "read" data is ready. As it is only dummy data that is transfered while reading from the SD card, there would be no need to wait for the data transfer. About eight processor cycles per byte are to be saved like that, and those cycles could make up for the variable indexing.

If the read-only-procedure would be inlined, even more cycles would be saved, and that read-only-procedure would be very small, so that should not cost much program data.

The real problem IMO is, that the fat lib would have to make a difference on what storage backend it is run then.

Greets,
Kiste

[William]

Greetings,

On May 11, 10:29 am, Oliver Seitz <karlki...@yahoo.com> wrote:
> I had been thinking about that part of the fat lib with PATA in mind, where data is transferred in parallel and two bytes are read within six or seven processor cycles. When SPI is used, things could be significantly sped up by not using a generic "read and write" procedure, but a read-only-procedure. The read-and-write-procedure is called, transfers the "write" data, and waits until the "read" data is ready. As it is only dummy data that is transfered while reading from the SD card, there would be no need to wait for the data transfer. About eight processor cycles per byte are to be saved like that, and those cycles could make up for the variable indexing.
>

Yes, I was also thinking a generic read a bunch of bytes SPI routine
might be called for. Not sure if the hardware master controller would
freak out if we ignore checking for errors only at the end of the 512
bytes? And dare I say that _asm might be worth considering?

> If the read-only-procedure would be inlined, even more cycles would be saved, and that read-only-procedure would be very small, so that should not cost much program data.
>

Sounds good.

> The real problem IMO is, that the fat lib would have to make a difference on what storage backend it is run then.
>

One way around this would be an alias that points to the function, and
supply a generic default?

William