Rokicki.
Thanks so much for your interest and help in this... and thanks for the piece of code too. Like I say...I'm not an academic programmer, but I'll learn more with these simple examples.
I get 11K with the piece of code that I wrote above, and about 21K avoiding the rxf check, although it's not correct, sometimes it work.
I did a check too, of how time takes the spin code by itself (instructions time), and it seems, that almost all the time, is consumed by the spin code.
But, like I don't know, which is the maximun time for the VDIP, to get one byte of data out, I think to do that piece of code in assembler, and try to check, if in many tries if I get the same result of the data read.
VDIP datasheet talk about 50nSec minimun pulse for RD# pin, adding all delays I calculate about 5.5Mb/sec (ideal, and maximun contitions), like I only need about 700k/sec, I think ..perhaps..it will work. I don't now too, the time that the VDIP micro, needs for manage the FAT table of the disk, and also the disk hardware speed.
I have wired up my dip module to have a go with it and perhaps join you in doing the assembly.
At the moment it does not seem to be working all communcations are returning ************************
I have wired it up as per your code and the datasheet, is there something I could be missing? Do you have a file on your thumbdrive you are reading, is is b.btx or btx.b or something?
Hi Graham.
I have a USB drive with the following, A.btx, B.btx, C.btx, A <DIR> (3 files plus a A directory).
I'm using only one of them to read...the B.btx in my code.
Be carrefully !! I have an mp3 player and it wont owrk with it, it hungs after told me the VDAP Firmware version and the Device Detected P2.
But you must unless get those messages.
I forgot to mention that I've a pin of the Pchip to reset the VDIP look at the code 'RST' pin.
I'm going out now..tonight I'll check the forum again. more or less 3 hours more.
Graham.
I'm not interested in messages too, but I noticed that my disk needs some time to get ready, and the VDIP too, (Perhaps you must wait to get ready all before send commands to the VDIP) so in my next sample, I avoid to send the dir command, but at the end, when I need to read the data from the file, the VDIP gives me all messages that I have been ignored.
NOT pullups needed.
The pins are swapped, but in my code are corect.
Look at my code, and there is something not so good, all repeat loops, have a different number to 'repeat', that's why I don't know how many bytes will the VDIP responses to me, so I first try to get it exactly, and then put the correct number of the repeat..
Example: In my case I have 3 files and one directory in the disk, so when I send the command 'dir', the VDIP responses to me with a quantity of bytes, but then if I add one more file to the disk, the code doesn't work, until I change the 'repeats number' in the repeat line to show the dir. (Do you understand ? what I want to say ).
Did you see the LEDs lighting of the VDIP ?
The LED1 flash and then the LED2, and so on ...when the VDIP is resetting.
The LED2 on, indicate that the VDIP is ready and waiting for some command.
The LED2 flashing mean that there is data to be read, or you not read all data available in the VDIP.
The LED1 flash one time when the VDIP are reading a file.
Check your board and connections the code must work. Or try with another disk.
Check this code is smalller.
I got no flashing at all. I redid my connections and I got the same. Perhaps I have a problem, I will check my connections yet again, I hope my module is not broken.
Your assembly code looks fine from what I can see, try a test with an led and switch.
First of all, I'm using a different MCU. But I have the same trouble as you have.
I'm currently trying the Vinculum VDAP. The v2.19, firmware is not stable. It sometimes freezes with a blinking LED. The older 2.08 is still working, but it seems to have bugs too.
I need to store an PNG image (1.2-1.5MB) within a few seconds, so I decide to use the FIFO mode together with the "shortened command set" (SCS).
To do so, I started playing with SCS and the UART interface on a VDIP1 device. The SCS interface is really ugly. It is a mix of an ASCII and an binary interface. Not very clear.
But most worth, it didn't work correctly. I couldn't write any data into a file. I don't get an error, the VDIP1 simply do not write anything.
What are your experiences with SCS?
I've tried the VDIP1 together with a handmade FIFO adapter, but here I have the problem, that the VDAP firmware don't configure the pins previously used for the UART. These pin are at high level and can't be pulled down. The jumpers are correctly setup. The LEDs are flashing.
Graham, I will check all my connections and pass to you them. but I repeat...you must get the two LEDs flashing ..only connecting the power to the VDIP.
joede, I use the code that I post here succesufully, with VDAP 2.19 that FTDI sents to me two days ago. I'll post it here.
Theres s an issue in the VDAP datasheet, to change to "short" mode you MUST use the command in 'LONG' mode, the command $10,$0D DON'T WORK..... I sent in FIFO mode: $73 $63 $73 $0D and it changes the VDIP to short mode correctly. If you reset the system, you need to change the mode again...the VDIP no memorize it.
Download the code... you'll see the connections here, (don't forget to have a pin to reset the VDIP).
How to reflash the VDIP:
To change the Firmware you must do the following:
1- Put this attached file in the root directory of the flash disk.
2- Rename it to:··FTRFB.FTD
3-· Turn on the VDIP by aplying + 5Vcc to it.
4-· Wait about 2 secconds and connect the flash disk to the VDIP.
After this, you''ll see the following (If checking the VDIP messages)
If then you erase the frimware file·from the flash disk...you'll not see again the: "Found it" message. Device Detected P2 Found It Change MAIN Reflasher Active ...............................................................................
................. Rebooting · Ver 02.19VDAPB On-Line: Device Detected P2 Found It No Upgrade \>
Quattro.
Absolutely NOT !!
I only got about 45-45 Kbytes/sec. in·my final try in assembler
That's so bad·expecting to get about 500Kbytes/s.
So at this momment, I'm trying to get a mortuary to veil to the VDIP dead.
Same way then I'll post the code in assembler, so many experts in programming can improve it.
My next step, is begin to test wih the Rokicki's SD code.
If that fails, my head will have·a price here in my country.........
Alberto,
If you pre-allocate the file space, you can use either Rokicki's or my low level routines to write a group of 512 byte blocks in one operation (certainly up to 32K). The program loader in FemtoBasic works this way by calling the mid-level routines with a filename to get the starting absolute block number and file length then calling the loader with the block number, file length, and RAM address to do the actual loading from a cog. The same thing can be done with reading or writing a group of blocks with data. Rokicki's low level assembly routines are faster than mine, but I've not timed either of them.
My routines are designed to allow double buffering if you have the memory available, so you can overlap the writing of one perhaps 8-12K block with the filling of a second one from some other source.
If you do decide to go with my stuff, 800KB/sec is really going to be pushing it, but it should be possible. It probably will *not* be possible with the
code I have posted though.
I need to know more about the application, why you need such speed. Also, the throughput will depend on the card to a certain extent; some cards
are faster than others at responding to a block read request. You will probably need to use a fair bit of memory for buffering (perhaps
start with 8K or something). And you will need the super assembly routines I have not yet published (nor perfected, primarily due to time)
in order to get the data to move that fast. These routines actually do 32-bit words and use WRLONG to write four at a time to the hub RAM to
help speed things up.
Currently I see between 274KB/sec and 400KB/sec (but that's just using big reads, and not actually doing *anything* with the data itself). This
includes some amount of file system overhead but it's not too much.
Are you willing to ensure the file is completely contiguous? (Generally, if you format and then write the files one by one, they will be
contiguous). If so, this will enable you to essentially bypass the entire filesystem and just do massive block reads as fast as possible.
Thanks so much Mike !
It's a possible solution, but it's too much for me, due to· my level of knowledge of· programming.
I will need too, that the same Pchip, execute another task with the read data, and send it to a 16 slave Pchips more.. (that is another thread ).
So you can see, my head just is getting price here.
All this for middle of June.
Graham.
Let me check the conneections NOW, and I'll answer you.
Rokicki.
I'm thinking that perhaps with 500-600 Kb/s is· ok, the idea is to save·the data in Pchip ram, while another task send it out to the slaves.
I need to save and send in packets of 1152 bytes each time.
I'll explain it, in more detail later.
Graham.
I've two VDIPs in my hand, one with VDAP 2.08 Firmware the another with 2.19 version.
Both with all pins open, I connect 5Vcc in Pin 1 and GND to pin 7, The LEDs 1 and 2 remain flashing continuosly, stop a few mSec and so on.
I'm so sorry ....it seems that you've a dead VDIP :-((
But it is really stranger... there is a long time ago, that this happened to me with a chip !
BTX said...
joede, I use the code that I post here succesufully, with VDAP 2.19 that FTDI sents to me two days ago. I'll post it here.
Thanx for the code. I'll try it. The lastest Release I have is a 2.19VDAPF. Yours end with an 'B'. Is this important?
BTX said...
Theres s an issue in the VDAP datasheet, to change to "short" mode you MUST use the command in 'LONG' mode, the command $10,$0D DON'T WORK.....
I sent in FIFO mode: $73 $63 $73 $0D and it changes the VDIP to short mode correctly. If you reset the system, you need to change the mode again...the VDIP no memorize it.
I know. I've done this. The 'SHORT' mode works as expected, only the data is not written to the stick. Open + write + close seems to be execeuted (there are no errors).
After this, the file TEST.TXT has a size of 0 bytes.
By the way... I've found my mistake in using the FIFO mode. I've used the RESET of the VDIP module. After a RESET, the VDIP seems to ignore the jumpers and always restart in UART mode. If I don't use the RESET, the FIFO interface is up and running. Hard to believe...
Sorry, I did not test the write file mode...I can't tell you too much about it, ONLY, that the VDAP firmware that you've has errors, change it by the 'B' that I post.
In another message of this thread, BrianCMM said that he must use the 2.08 version for FIFO mode.....I did it too, but with the new 2.19 it works me.
Let me know If you want the 2.08 too.
Your commands looks OK, do you check the messages from VDIP ?? If one command fails, VDIP will say you.... 'CF' (command failed in short mode). So you could found where is failing it.
Check eventually, if the text file that you created with the command, has the correct attribute. (Only to be sure...something strange could not be happend).
I must use the reset to sicronize my code with the messages, I have not noticed that the VDIP ignores the jumpers after start up...perhaps you are sending some command after the disk is ready. I allways wait for the message that confirm this, after send a command to open the file.
Your SD code works me at once, also, I test the speed of it in spin (in poor conditions ), it gaves me about 25Kb/sec reading a file.
Now I'll try to test faster in assembler....but I must think it, because at this time, I don't know how to do it.
First thing is, yes, you'll get 25KB/sec if you use getchar(). So don't use getchar(). Use read on larger blocks.
Even this won't be as fast as we can do, but let's start with this.
So just allocate a 4K block somewhere, and use read to read the entire 4K at once.
(Now if you do *anything* with this data byte by byte, you'll be slow again, so what you want to do is just
read a 4K block and hand it over to the thing that's sending the data to the slaves, and repeat.)
Initially we just want to see if we can read from the SD card fast enough (totally ignoring the actual data). Then, we want to see if we can send to the slave
props fast enough (again, sending dummy data). If we cannot do either one of these, we need to work on improving that aspect in isolation.
The next thing to think about is how you want to separate the sending and receiving. Reading from an SD card as I have implemented it is synchronous; the
read does not return until the data is in the buffer. (We can change the code so this is not the case, but let us keep things simple for now.) Your sending to
the slaves will probably be synchronous too. If both of these are synchronous and executed from the same thread, they cannot run at the same time.
To get them to run at the same time, we want to probably put them in different cogs. If you have enough cogs, it is easy enough to do this directly in spin.
You want one cog that does the reading from the SD cards to a big buffer, one cog that does the sending to the slave from that buffer, and a third cog that sits
there and administrates (starts, stops, etc.) They will all communicate with shared memory. (You do not really need the third cog, by the way, but sometimes
it makes things easier to think about.)
There are a bunch of ways to synchronize them, and it is frequently fun to work out how to do it yourself. So I will stop here and see what you can come up
with.
That looks fine. You should do a few things though:
1. In the read call use 4000 not 4001; you are reading 4001 bytes and overflowing your array. This doesn't seem to be
breaking anything, but it's still dangerous.
2. After the speed test print the return value (r) just to make sure you actually read that many bytes. (The return value
is the count of bytes read.) If it doesn't match something is wrong (maybe the file is too short or something).
3. Not sure what this is here for; you don't need it:
repeat while tbuf[noparse][[/noparse]4000] == $00
That's not a bad speed for a first go. The next thing to test is, how fast can you ship data from one prop to the other.
This will almost certainly take assembly language. It would be interesting to see how fast you can do it in spin though.
By the way: when testing prop->prop communication, I recommend doing it all within a single prop, initially, just using two separate
cogs, one to send the other to receive. This won't be *exactly* the same as going between cogs, but it shouldn't be too far off, and
it will be much easier to develop, test, and debug than doing it across multiple props.
Rokicki.
I think could be simplest to me for understand, if we do the:
One cog that does the reading from the SD cards to a big buffer. One cog that does the sending to the slave from that buffer, and a third cog that sits.
Sorry I·don't understand somethings that you wrote...·like (totally ignoring the actual data)???. I test the SD speed using a text file full wrote of about 11Kbytes. To see at the tv, if it's really correct, and no garbage in the midddle of it. The result was correct file read.
Why could not have Cogs enough ? like you plain, it's·only 3 cogs for all.
I'm thinking about ...HOW after the first read is done, and the data is into the buffer, and the master rutine start to send that data to the slaves, you'll avoid to the buffer be overwrited by new data, after the master runite finish to send the first packet ??
Did you read my previous post ??, I just·see, that I don't see your last post,·when I post mine.
Comments
Thanks so much for your interest and help in this... and thanks for the piece of code too. Like I say...I'm not an academic programmer, but I'll learn more with these simple examples.
I get 11K with the piece of code that I wrote above, and about 21K avoiding the rxf check, although it's not correct, sometimes it work.
I did a check too, of how time takes the spin code by itself (instructions time), and it seems, that almost all the time, is consumed by the spin code.
But, like I don't know, which is the maximun time for the VDIP, to get one byte of data out, I think to do that piece of code in assembler, and try to check, if in many tries if I get the same result of the data read.
VDIP datasheet talk about 50nSec minimun pulse for RD# pin, adding all delays I calculate about 5.5Mb/sec (ideal, and maximun contitions), like I only need about 700k/sec, I think ..perhaps..it will work. I don't now too, the time that the VDIP micro, needs for manage the FAT table of the disk, and also the disk hardware speed.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Regards.
Alberto.
I have wired up my dip module to have a go with it and perhaps join you in doing the assembly.
At the moment it does not seem to be working all communcations are returning ************************
I have wired it up as per your code and the datasheet, is there something I could be missing? Do you have a file on your thumbdrive you are reading, is is b.btx or btx.b or something?
Cheers,
Graham
I have a USB drive with the following, A.btx, B.btx, C.btx, A <DIR> (3 files plus a A directory).
I'm using only one of them to read...the B.btx in my code.
Be carrefully !! I have an mp3 player and it wont owrk with it, it hungs after told me the VDAP Firmware version and the Device Detected P2.
But you must unless get those messages.
I forgot to mention that I've a pin of the Pchip to reset the VDIP look at the code 'RST' pin.
I'm going out now..tonight I'll check the forum again. more or less 3 hours more.
See you later.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Regards.
Alberto.
I'm not getting any messages at all. I will check my connections.
I'm not supposed to be adding pull up resistors all over the place?
What about the problem with swapped pins?
Graham
I'm not interested in messages too, but I noticed that my disk needs some time to get ready, and the VDIP too, (Perhaps you must wait to get ready all before send commands to the VDIP) so in my next sample, I avoid to send the dir command, but at the end, when I need to read the data from the file, the VDIP gives me all messages that I have been ignored.
NOT pullups needed.
The pins are swapped, but in my code are corect.
Look at my code, and there is something not so good, all repeat loops, have a different number to 'repeat', that's why I don't know how many bytes will the VDIP responses to me, so I first try to get it exactly, and then put the correct number of the repeat..
Example: In my case I have 3 files and one directory in the disk, so when I send the command 'dir', the VDIP responses to me with a quantity of bytes, but then if I add one more file to the disk, the code doesn't work, until I change the 'repeats number' in the repeat line to show the dir. (Do you understand ? what I want to say ).
Did you see the LEDs lighting of the VDIP ?
The LED1 flash and then the LED2, and so on ...when the VDIP is resetting.
The LED2 on, indicate that the VDIP is ready and waiting for some command.
The LED2 flashing mean that there is data to be read, or you not read all data available in the VDIP.
The LED1 flash one time when the VDIP are reading a file.
Check your board and connections the code must work. Or try with another disk.
Check this code is smalller.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Regards.
Alberto.
Work it ?
mov t2,outsI ' P10, P11 Outputs P0-7 Inputs mov dira,t2again mov t7,ina 'Check for RXF to be low and t7,RXF tjnz t7,#againIt seems that not.
Why ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Regards.
Alberto.
Regards,
Quattro
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Necessity is the mother of invention'
I got no flashing at all. I redid my connections and I got the same. Perhaps I have a problem, I will check my connections yet again, I hope my module is not broken.
Your assembly code looks fine from what I can see, try a test with an led and switch.
Graham
Graham. You must get flashing the two VDIP LEDs, immediatly you provide +5Vcc to it. (sorry...do you connect the VDIP to +5 Volt ?).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Regards.
Alberto.
Graham
I'm currently trying the Vinculum VDAP. The v2.19, firmware is not stable. It sometimes freezes with a blinking LED. The older 2.08 is still working, but it seems to have bugs too.
I need to store an PNG image (1.2-1.5MB) within a few seconds, so I decide to use the FIFO mode together with the "shortened command set" (SCS).
To do so, I started playing with SCS and the UART interface on a VDIP1 device. The SCS interface is really ugly. It is a mix of an ASCII and an binary interface. Not very clear.
But most worth, it didn't work correctly. I couldn't write any data into a file. I don't get an error, the VDIP1 simply do not write anything.
What are your experiences with SCS?
I've tried the VDIP1 together with a handmade FIFO adapter, but here I have the problem, that the VDAP firmware don't configure the pins previously used for the UART. These pin are at high level and can't be pulled down. The jumpers are correctly setup. The LEDs are flashing.
joede, I use the code that I post here succesufully, with VDAP 2.19 that FTDI sents to me two days ago. I'll post it here.
Theres s an issue in the VDAP datasheet, to change to "short" mode you MUST use the command in 'LONG' mode, the command $10,$0D DON'T WORK.....
I sent in FIFO mode: $73 $63 $73 $0D and it changes the VDIP to short mode correctly. If you reset the system, you need to change the mode again...the VDIP no memorize it.
Download the code... you'll see the connections here, (don't forget to have a pin to reset the VDIP).
How to reflash the VDIP:
To change the Firmware you must do the following:
1- Put this attached file in the root directory of the flash disk.
2- Rename it to:··FTRFB.FTD
3-· Turn on the VDIP by aplying + 5Vcc to it.
4-· Wait about 2 secconds and connect the flash disk to the VDIP.
After this, you''ll see the following (If checking the VDIP messages)
If then you erase the frimware file·from the flash disk...you'll not see again the: "Found it" message.
Device Detected P2
Found It
Change MAIN
Reflasher Active
...............................................................................
.................
Rebooting
·
Ver 02.19VDAPB On-Line:
Device Detected P2
Found It
No Upgrade
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Regards.
Alberto.
I've the assembler code for read a file working, and a assembler code for take out the data from the VDIP working too !!
I'm stopped now, trying to check the final speed of both asm rutines. :-(
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Regards.
Alberto.
Regards,
Quattro
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Necessity is the mother of invention'
Absolutely NOT !!
I only got about 45-45 Kbytes/sec. in·my final try in assembler
That's so bad·expecting to get about 500Kbytes/s.
So at this momment, I'm trying to get a mortuary to veil to the VDIP dead.
Same way then I'll post the code in assembler, so many experts in programming can improve it.
My next step, is begin to test wih the Rokicki's SD code.
If that fails, my head will have·a price here in my country.........
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Regards.
Alberto.
If you pre-allocate the file space, you can use either Rokicki's or my low level routines to write a group of 512 byte blocks in one operation (certainly up to 32K). The program loader in FemtoBasic works this way by calling the mid-level routines with a filename to get the starting absolute block number and file length then calling the loader with the block number, file length, and RAM address to do the actual loading from a cog. The same thing can be done with reading or writing a group of blocks with data. Rokicki's low level assembly routines are faster than mine, but I've not timed either of them.
My routines are designed to allow double buffering if you have the memory available, so you can overlap the writing of one perhaps 8-12K block with the filling of a second one from some other source.
I have 5v and no flashing. I think I have a dead dip.
Graham
code I have posted though.
I need to know more about the application, why you need such speed. Also, the throughput will depend on the card to a certain extent; some cards
are faster than others at responding to a block read request. You will probably need to use a fair bit of memory for buffering (perhaps
start with 8K or something). And you will need the super assembly routines I have not yet published (nor perfected, primarily due to time)
in order to get the data to move that fast. These routines actually do 32-bit words and use WRLONG to write four at a time to the hub RAM to
help speed things up.
Currently I see between 274KB/sec and 400KB/sec (but that's just using big reads, and not actually doing *anything* with the data itself). This
includes some amount of file system overhead but it's not too much.
Are you willing to ensure the file is completely contiguous? (Generally, if you format and then write the files one by one, they will be
contiguous). If so, this will enable you to essentially bypass the entire filesystem and just do massive block reads as fast as possible.
So let us know more about the big picture please.
It's a possible solution, but it's too much for me, due to· my level of knowledge of· programming.
I will need too, that the same Pchip, execute another task with the read data, and send it to a 16 slave Pchips more.. (that is another thread ).
So you can see, my head just is getting price here.
All this for middle of June.
Graham.
Let me check the conneections NOW, and I'll answer you.
Rokicki.
I'm thinking that perhaps with 500-600 Kb/s is· ok, the idea is to save·the data in Pchip ram, while another task send it out to the slaves.
I need to save and send in packets of 1152 bytes each time.
I'll explain it, in more detail later.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Regards.
Alberto.
I've two VDIPs in my hand, one with VDAP 2.08 Firmware the another with 2.19 version.
Both with all pins open, I connect 5Vcc in Pin 1 and GND to pin 7, The LEDs 1 and 2 remain flashing continuosly, stop a few mSec and so on.
I'm so sorry ....it seems that you've a dead VDIP :-((
But it is really stranger... there is a long time ago, that this happened to me with a chip !
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Regards.
Alberto.
Envio editado por (BTX) : 4/5/2007 4:33:52 PM GMT
Thanx for the code. I'll try it. The lastest Release I have is a 2.19VDAPF. Yours end with an 'B'. Is this important?
I know. I've done this. The 'SHORT' mode works as expected, only the data is not written to the stick. Open + write + close seems to be execeuted (there are no errors).
Here is what I've done:
$09$20TEST.TXT$0D
$08 $00$00$00$0A$0D
0123456789$0D
$0E$20TEST.TXT$0D
After this, the file TEST.TXT has a size of 0 bytes.
By the way... I've found my mistake in using the FIFO mode. I've used the RESET of the VDIP module. After a RESET, the VDIP seems to ignore the jumpers and always restart in UART mode. If I don't use the RESET, the FIFO interface is up and running. Hard to believe...
Sorry, I did not test the write file mode...I can't tell you too much about it, ONLY, that the VDAP firmware that you've has errors, change it by the 'B' that I post.
In another message of this thread, BrianCMM said that he must use the 2.08 version for FIFO mode.....I did it too, but with the new 2.19 it works me.
Let me know If you want the 2.08 too.
Your commands looks OK, do you check the messages from VDIP ?? If one command fails, VDIP will say you.... 'CF' (command failed in short mode). So you could found where is failing it.
Check eventually, if the text file that you created with the command, has the correct attribute. (Only to be sure...something strange could not be happend).
I must use the reset to sicronize my code with the messages, I have not noticed that the VDIP ignores the jumpers after start up...perhaps you are sending some command after the disk is ready. I allways wait for the message that confirm this, after send a command to open the file.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Regards.
Alberto.
You're a genius !!
Your SD code works me at once, also, I test the speed of it in spin (in poor conditions ), it gaves me about 25Kb/sec reading a file.
Now I'll try to test faster in assembler....but I must think it, because at this time, I don't know how to do it.
Some help, could be great.....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Regards.
Alberto.
First thing is, yes, you'll get 25KB/sec if you use getchar(). So don't use getchar(). Use read on larger blocks.
Even this won't be as fast as we can do, but let's start with this.
So just allocate a 4K block somewhere, and use read to read the entire 4K at once.
(Now if you do *anything* with this data byte by byte, you'll be slow again, so what you want to do is just
read a 4K block and hand it over to the thing that's sending the data to the slaves, and repeat.)
props fast enough (again, sending dummy data). If we cannot do either one of these, we need to work on improving that aspect in isolation.
The next thing to think about is how you want to separate the sending and receiving. Reading from an SD card as I have implemented it is synchronous; the
read does not return until the data is in the buffer. (We can change the code so this is not the case, but let us keep things simple for now.) Your sending to
the slaves will probably be synchronous too. If both of these are synchronous and executed from the same thread, they cannot run at the same time.
To get them to run at the same time, we want to probably put them in different cogs. If you have enough cogs, it is easy enough to do this directly in spin.
You want one cog that does the reading from the SD cards to a big buffer, one cog that does the sending to the slave from that buffer, and a third cog that sits
there and administrates (starts, stops, etc.) They will all communicate with shared memory. (You do not really need the third cog, by the way, but sometimes
it makes things easier to think about.)
There are a bunch of ways to synchronize them, and it is frequently fun to work out how to do it yourself. So I will stop here and see what you can come up
with.
I do exactly that...please check it, I can believe it ... perhaps I'll be wrong but it gives me about 383Kb/sec.
Look at this code.
My card, is a Kingston 256Mb, at this momment.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Regards.
Alberto.
1. In the read call use 4000 not 4001; you are reading 4001 bytes and overflowing your array. This doesn't seem to be
breaking anything, but it's still dangerous.
2. After the speed test print the return value (r) just to make sure you actually read that many bytes. (The return value
is the count of bytes read.) If it doesn't match something is wrong (maybe the file is too short or something).
3. Not sure what this is here for; you don't need it:
repeat while tbuf[noparse][[/noparse]4000] == $00
That's not a bad speed for a first go. The next thing to test is, how fast can you ship data from one prop to the other.
This will almost certainly take assembly language. It would be interesting to see how fast you can do it in spin though.
cogs, one to send the other to receive. This won't be *exactly* the same as going between cogs, but it shouldn't be too far off, and
it will be much easier to develop, test, and debug than doing it across multiple props.
I think could be simplest to me for understand, if we do the:
One cog that does the reading from the SD cards to a big buffer. One cog that does the sending to the slave from that buffer, and a third cog that sits.
Sorry I·don't understand somethings that you wrote...·like (totally ignoring the actual data)???. I test the SD speed using a text file full wrote of about 11Kbytes. To see at the tv, if it's really correct, and no garbage in the midddle of it. The result was correct file read.
Why could not have Cogs enough ? like you plain, it's·only 3 cogs for all.
I'm thinking about ...HOW after the first read is done, and the data is into the buffer, and the master rutine start to send that data to the slaves, you'll avoid to the buffer be overwrited by new data, after the master runite finish to send the first packet ??
Did you read my previous post ??, I just·see, that I don't see your last post,·when I post mine.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Regards.
Alberto.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Regards.
Alberto.