Multimediacard issues

John · Guest

I'm planning to build a data logger which would store values into an external memory. I've tested serial eeproms and they're ok but the amount of storage is too low. Hence I started thinking about mulimedia cards (mmc) in SPI-mode. The drawback seem to be that they require 512 bytes to be written at each occasion but I would like to write, say, 2 bytes every quarter of a second. What are my options here? I really would like to avoid buffering the data in an external eeprom. Is it possible to write a few bytes to the mmc, get new data and resume to write this new data and so on but not actually terminating the write sequence? Any ideas?

Regards,
/John (PCM 2.686, 16F8xx)
___________________________
This message was ported from CCS's old forum
Original Post ID: 10434

Regan · Guest

John, have you considered FRAM? Check out the SPI products at www.ramtron.com

The great thing about this neat technology is that you don't have to wait for the writes to commit to memory before using the device again. That way you could use the FRAM as a queueing buffer, before writing out 512 bytes to the MMC.

Regan.

:=I'm planning to build a data logger which would store values into an external memory. I've tested serial eeproms and they're ok but the amount of storage is too low. Hence I started thinking about mulimedia cards (mmc) in SPI-mode. The drawback seem to be that they require 512 bytes to be written at each occasion but I would like to write, say, 2 bytes every quarter of a second. What are my options here? I really would like to avoid buffering the data in an external eeprom. Is it possible to write a few bytes to the mmc, get new data and resume to write this new data and so on but not actually terminating the write sequence? Any ideas?
:=
:=Regards,
:=/John (PCM 2.686, 16F8xx)
___________________________
This message was ported from CCS's old forum
Original Post ID: 10439

Tomi · Guest

You MUST write MMC in 512-byte blocks so you must have a buffer for your data. In one of my older projects I have used an external EEPROM but maybe you (as me) must consider to use 18F PIC and buffer the data in the internal RAM.

:=I'm planning to build a data logger which would store values into an external memory. I've tested serial eeproms and they're ok but the amount of storage is too low. Hence I started thinking about mulimedia cards (mmc) in SPI-mode. The drawback seem to be that they require 512 bytes to be written at each occasion but I would like to write, say, 2 bytes every quarter of a second. What are my options here? I really would like to avoid buffering the data in an external eeprom. Is it possible to write a few bytes to the mmc, get new data and resume to write this new data and so on but not actually terminating the write sequence? Any ideas?
:=
:=Regards,
:=/John (PCM 2.686, 16F8xx)
___________________________
This message was ported from CCS's old forum
Original Post ID: 10449

John · Guest

Yes, but maybe it is possible to "cheat"?
The specs says that it tolerates variable clock frequency. What would happen if I halt the clock pulses in the middle of a write to get another data sample and then just continue to feed the MMC with the new data by letting the clock start again, hence like a variable clock. Will the MMC time out during this or what? Haven't found anything in the datasheet about this. To me it looks like the MMC itself buffers the 512bytes and then writes it. Am I way out of line here?
/John

:=You MUST write MMC in 512-byte blocks so you must have a buffer for your data. In one of my older projects I have used an external EEPROM but maybe you (as me) must consider to use 18F PIC and buffer the data in the internal RAM.
:=
:=
:=:=I'm planning to build a data logger which would store values into an external memory. I've tested serial eeproms and they're ok but the amount of storage is too low. Hence I started thinking about mulimedia cards (mmc) in SPI-mode. The drawback seem to be that they require 512 bytes to be written at each occasion but I would like to write, say, 2 bytes every quarter of a second. What are my options here? I really would like to avoid buffering the data in an external eeprom. Is it possible to write a few bytes to the mmc, get new data and resume to write this new data and so on but not actually terminating the write sequence? Any ideas?
:=:=
:=:=Regards,
:=:=/John (PCM 2.686, 16F8xx)
___________________________
This message was ported from CCS's old forum
Original Post ID: 10459

John · Guest

They do seem to be neat. But I would really, really like to avoid another device for buffering purposes... :-) There are too few I/O pins as it is!
/John

:=John, have you considered FRAM? Check out the SPI products at www.ramtron.com
:=
:=The great thing about this neat technology is that you don't have to wait for the writes to commit to memory before using the device again. That way you could use the FRAM as a queueing buffer, before writing out 512 bytes to the MMC.
:=
:=Regan.
:=
:=:=I'm planning to build a data logger which would store values into an external memory. I've tested serial eeproms and they're ok but the amount of storage is too low. Hence I started thinking about mulimedia cards (mmc) in SPI-mode. The drawback seem to be that they require 512 bytes to be written at each occasion but I would like to write, say, 2 bytes every quarter of a second. What are my options here? I really would like to avoid buffering the data in an external eeprom. Is it possible to write a few bytes to the mmc, get new data and resume to write this new data and so on but not actually terminating the write sequence? Any ideas?
:=:=
:=:=Regards,
:=:=/John (PCM 2.686, 16F8xx)
___________________________
This message was ported from CCS's old forum
Original Post ID: 10460

Tomi · Guest

:=Yes, but maybe it is possible to "cheat"?

Yes, I think it is possible but don't forget that in that case the ChipSelect line is nearly always active and the power consumption is cca. 60mA instead of the 50uA. This means a continous 180mW dissipation on a few square inches...
If you want to use MMC then you already have an SPI bus so it is easy to select an SPI-related EEPROM as suggested by Regan (you need only 1 additional port pin).
___________________________
This message was ported from CCS's old forum
Original Post ID: 10464

John · Guest

:=:=Yes, but maybe it is possible to "cheat"?
:=
:=Yes, I think it is possible but don't forget that in that case the ChipSelect line is nearly always active and the power consumption is cca. 60mA instead of the 50uA. This means a continous 180mW dissipation on a few square inches...
:=If you want to use MMC then you already have an SPI bus so it is easy to select an SPI-related EEPROM as suggested by Regan (you need only 1 additional port pin).

That could perhaps be a problem and I guess a heat sink isn't a serious solution. :-) OK, maybe I should give up and use a buffer...
Thanks for the responses!
/John
___________________________
This message was ported from CCS's old forum
Original Post ID: 10477

Chang-Huei Wu · Guest

Thanks for Tomi's code ... I did some modification and finally

1. variable clock: write a byte, do something else, write next
2. MMC always on, 16 mA only (not 60 mA, which is burst programming)
3. MMC takes 2.5 msec to program those 512 bytes in MMC buffer, average 32 KB/sec or 24 KB/sec with 40 byte FIFO buffer in F877 at 20 MHz making wrost case byte_write become 0.25 msec
4. read back by MMC card reader as removable disk under Win2000 with USB 1.1 interface at 8 MB/min. ( the reader cost me USD 20. )

C-H Wu
___________________________
This message was ported from CCS's old forum
Original Post ID: 10525

Gerrit · Guest

Hello C-H Wu,

Just starting a project with large data storage.

I have been looking at SST 25vf040 chip (4 Mb) also large
input buffer (4Kb).

The solution with variable clock is what i'm looking for.

Could you send me some information to start this project, like
simple schematic, CCS sample source etc.

Every help is use-full.

Looking forward for some information. (privite e-mail addres included)

regards,

Gerrit Faas

:=Thanks for Tomi's code ... I did some modification and finally
:=
:=1. variable clock: write a byte, do something else, write next
:=2. MMC always on, 16 mA only (not 60 mA, which is burst programming)
:=3. MMC takes 2.5 msec to program those 512 bytes in MMC buffer, average 32 KB/sec or 24 KB/sec with 40 byte FIFO buffer in F877 at 20 MHz making wrost case byte_write become 0.25 msec
:=4. read back by MMC card reader as removable disk under Win2000 with USB 1.1 interface at 8 MB/min. ( the reader cost me USD 20. )
:=
:=C-H Wu
___________________________
This message was ported from CCS's old forum
Original Post ID: 10531

John · Guest

:=Thanks for Tomi's code ... I did some modification and finally
:=
:=1. variable clock: write a byte, do something else, write next
:=2. MMC always on, 16 mA only (not 60 mA, which is burst programming)
:=3. MMC takes 2.5 msec to program those 512 bytes in MMC buffer, average 32 KB/sec or 24 KB/sec with 40 byte FIFO buffer in F877 at 20 MHz making wrost case byte_write become 0.25 msec
:=4. read back by MMC card reader as removable disk under Win2000 with USB 1.1 interface at 8 MB/min. ( the reader cost me USD 20. )
:=
:=C-H Wu

So, if I understand you correctly, you do fill the MMC buffer at "any" rate by holding up the data write (+clock) without a problem?

/John
___________________________
This message was ported from CCS's old forum
Original Post ID: 10534

Chang-Huei Wu · Guest

Here's my test code 5 min. ago,
write two bytes, delay 1 msec, then loop back ...
no problem ( 8 sec to write 256 kB or 130 sec with delay)

is this what you want ?

I just tested with 32 MB MMC, will try 128 MB next month.

C-H Wu
---------------------------

main()
{
.... // deleted

printf("\n\n\n\rWriting data to ... ecg_256k.dat");

mmc_open_4_write(0x00, 0x01, 0x52); // ecg_256k.dat

x_index = 50;
y_index = 0;

for(j=0; j < 8; j++) {
for(i=0; i < 16384; i++) { // write x and y 16 kB

x = SINE_WAVE [ x_index ]; mmc_write( x );
y = SINE_WAVE [ y_index ]; mmc_write( y );

if ( ++x_index == 200 ) x_index = 0;
if ( ++y_index == 200 ) y_index = 0;

delay_ms(1); // just for testing ...

} printf(" \%u", j+1);
}

mmc_close(); // close before R/W mode change

.... // deleted
}
___________________________
This message was ported from CCS's old forum
Original Post ID: 10538

Chang-Huei Wu · Guest

I don't know how to delete it ... sorry
___________________________
This message was ported from CCS's old forum
Original Post ID: 10539

Chang-Huei Wu · Guest

:=So, if I understand you correctly, you do fill the MMC buffer at "any" rate by holding up the data write (+clock) without a problem?
:=
:=/John

yes, and I believe you can even do this

clock high 50 nsec, clock low 50 msec,
clock high 50 nsec, clock low 50 nsec,
clock high 50 msec ...

my MMC manual says max. 20 MHz, min. 0 Hz

best wishes
___________________________
This message was ported from CCS's old forum
Original Post ID: 10540

John · Guest

:=yes, and I believe you can even do this
:=
:=clock high 50 nsec, clock low 50 msec,
:=clock high 50 nsec, clock low 50 nsec,
:=clock high 50 msec ...
:=
:=my MMC manual says max. 20 MHz, min. 0 Hz
:=
:=best wishes

I believe that it also would be ok since it is the flanks that triggers.
Thank you very much for the help and tests! So, hopefully I will not need any other buffering which is relieving...
/John
___________________________
This message was ported from CCS's old forum
Original Post ID: 10547

John · Guest

:=
:=Here's my test code 5 min. ago,
:=write two bytes, delay 1 msec, then loop back ...
:=no problem ( 8 sec to write 256 kB or 130 sec with delay)
:=
:=is this what you want ?

It would be interresting to see the code the functions mmc_open_4_write, mmc_write and mmc_close. Maybe you have a mmc_read too? I would highly appreciate it if you wouldn't mind sharing your code!
/John
___________________________
This message was ported from CCS's old forum
Original Post ID: 10580