PDA

View Full Version : Vinculum Speed ?



BTX
02-14-2007, 04:57 AM
I'm trying a project, that uses vinculum VDIP1 modul, to read data from a USB disk, I think to use it by Parallel FIFO mode, to get more speed reading the data, the code for the propeller in assembly (of course).
Does anybody knows, how faster, could I read the data from the disk ? Which is the delay from the VDIP to get FATxx work ?
I ask vinculum support, but it is not clear their answer.....http://forums.parallax.com/images/smilies/cry.gif
Some suggests Mike ?
I'll need about 800Kbyte/seccond data rate.

Thanks in advance.





▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Regards.

Alberto.

BTX
02-14-2007, 10:28 PM
Hi!!
Some feedback will be apreciated, or another idea of 'how to transfer data to a propeller, from a disk, at 800Kbytes/seccond'.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Regards.

Alberto.

QuattroRS4
02-14-2007, 11:38 PM
BTX,
Well information seems thin on the ground at the moment - I was looking at these some time ago also but went with Rokicki SD card option instead ... simply because there was not enough info at the time on Vinculum stuff - maybe that has changed now ?

Not specifically what you requested but the following may be an option for you :

http://tomas.rokicki.com/fat16work/

Mike Green
02-14-2007, 11:53 PM
800 KByte/s is at least 6.4MBit/s leaving an average of maybe 150ns/bit. That's only 3 instructions per bit if the transfers are done using SPI, not doable. Using the FIFO mode, the minimum time per byte is 100ns. Vinculum's documentation doesn't say what their transfer rates are, particularly the rate on/off the USB flash drive.

I suspect you're going to have to test it yourself using a particular USB flash drive since whatever you get will likely not be the same for most other USB drives.

rokicki
02-15-2007, 12:22 AM
I believe it is possible to write SD support that will read at 1MB/sec or very very close. Of course, it depends on the
card being that fast in SPI mode and many are not. With a reasonably fast card, the existing FAT16 work will get you
past 400KByte/sec. The main trick to speeding it up past that is to do the low-level transfers at 32 bits and use a
single WRLONG to write that back to hub memory. The inner loop of the SPI read routine is two instructions per bit,
which is a 10MHz clock and a bulk rate of 1.25MBytes/second; the key is to eliminate all the overhead.

Multiblock reads may also help.

On the other hand, the Vinculum chip can use USB host controllers that drive the flash chips much faster, so it
*should* be quite a bit faster than this. I'm waiting for someone to test it and report their results.

Tom Bampton
02-15-2007, 01:25 AM
Whilst it doesn't help you now, we are planning on doing some testing with the Vinculum in the next few weeks. I'll post the results when we are done.

Of course, I won't complain if someone beats me to it, since then I won't have to do it ;)

T.

BTX
02-15-2007, 04:38 AM
Nothing has changed Quattro....

Like Mike said, i'll try by myself the test's with a USB drive in FIFO mode, it'll take me a bit more of time, because I have to setup first a protoboard for the circuit.

Rokicki..., until I've some time I would like to try with your code too, not enought time to do all together now. (or if vinculum fails in 800K/sec... ).

Tom...Same I'll be waiting for your results....this project will take me many months.

Thanks again to all.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Regards.

Alberto.

QuattroRS4
03-07-2007, 10:45 PM
BTX,
Not extremely informative but 'Elektor' mag. had some info this month on Vinculum VDRIVE2 using a VNC1l for usb host interface...

Have a read anyway

Quattro

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Necessity is the mother of invention'

BTX
03-08-2007, 03:39 AM
Thanks so much Quattro
I'll read it.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Regards.

Alberto.

BTX
03-08-2007, 05:08 AM
I've just read the text, and it could be great for me, if vinculum chip is really cappable of read data files at 12Mbytes/sec.
Well I suppose that, I could be get that using the FIFO mode, I'm just doing the tests PCB's for the VDIP1 and the propeller involved to 'test' that working cappabilities, I also add a SD socket to that PCB, to test the results with the Rokciki's code.
I will post that results and some code when I've done it. (I'm doing many projects togheter at this time, so only a bit of time for each one).

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Regards.

Alberto.

QuattroRS4
03-08-2007, 11:04 AM
Alberto,
Keep us Posted

Regards,
Quattro

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Necessity is the mother of invention'

BrianCMM
03-13-2007, 10:46 PM
FYI:

I have been 'trying' to use the VNC1L-VDAP for weeks now.
The sample VDIP1 which I have received works fine and has
V2.08 firmware on it.· I have tried it in both FIFO and UART modes.

But the VNC1L chips that we ordered and have implemented into our design
are·not working out so well.· First off the documentation is horrendous, not to
mention incorrect!!· If using FIFO mode,·you should be·aware that the RD and WR
pins have been swapped!
> Pin ACBUS2 is RD#
> Pin ACBUS3 is WR
Also note that RD is inverted, while WR is not.
And be aware that these chips come with no firmware installed (contrary to the documentation)!

This was discovered after MUCH trial and error and some emails from FTDI support,
which also sent incorrect info!· Why is there no Erratta sheet on this?

Further more, I can only get firmware version 2.19 on their website and I can't
get my implementation to work with that firmware (maybe works 5% of the time).
95% of the time I get hung while trying to read a file or send an IDD command?
But DIR commands work fine?· I can't get a hold of firmware V2.08 to see if that
is the problem.· I have tried both FIFO and UART mode with the same result.

I will post any new info here as I get it and would appreciate any feedback from
anyone using this chip.

Thanks,
Brian

PointDog
03-22-2007, 12:13 PM
BrianCMM,
I am using the vdap firmware in a design I am testing at the moment, I decided on a pic24 for the design, as when I started there was no ICD/ICE for the propeller, but I'm sure the info will help you anyway. I will keep you informed of the progress, as I have been unable to get this device to work either. thanks for the heads up on the RD/WR crossover, that's a major!

A small note that I missed was the fact that you need a pll filter on the pllfilter pin (yeah, i'm not too bright :)) and you need to pull pin 48 (acbus7) to ground via a 47k resistor to select a 12 Mhz crystal clock, if you pull acbus7 to +3.3v the chip will select 48mhz as its clock input frequency.

Another thing to note (you've obviously worked this out, but for anyone else browsing this thread) you need to re-flash ft232 devices to use them to put firmware in the vinculum.

BrianCMM
03-22-2007, 07:47 PM
I have contacted FTDI customer support again and have received V2.08 firmware. (attached)

I have flashed this version onto the VNC1L chip in my project and all seems to be working fine now.

So it would seem that V2.19 has introduced a bug...but then I flashed V2.19 onto the
sample VDIP board and it also worked fine?· The only difference is that the VDIP was
configured for UART mode and my project is configured for FIFO mode.

So I assume there was a bug introduced after V2.08 that affects FIFO mode only.

If you are using FIFO mode and having problems...use V2.08 firmware.
If using UART or SPI (untested by me), you should be ok either V2.08 or V2.19 firmware.

Good luck.

BTX
03-22-2007, 07:47 PM
Hi guys.
I'll try directly with a VDIP1 modul....the tests are comming soon, I believe that using the VDIP chip, will avoid this kind of sticky issues of the design, than directly with the VNC1L.
I'll keep posted.
Thanks for the details. !!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Regards.

Alberto.

BTX
04-02-2007, 12:39 AM
BrianCMM.
Is there a possibility that you share with me the Pchip FIFO code ?
I'm trying since two days, and it's impossible.....I can't get read any form VDIP still, TOO BAD !! doccumentation from FTDI.
Thanks so much.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Regards.

Alberto.

BTX
04-02-2007, 08:40 AM
At the momment, I only get to read the initials messages from the VDIP in FIFO mode, I'm still trying to send commands to it, it allways answer: Bad Command

When I start the object, I get:

Ver 02.08VDAPF On-Line:
Device Detected P2
No Upgrade
D:\>

Like BrianCMM said, the WR and RD# pins are swapped in the datasheet. (Such a error !!!)
Now I'm trying, and I'm sure of nothing about I read...I'm getting crazy :-(

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Regards.

Alberto.

Jamesx
04-02-2007, 11:50 AM
I tried to get the Vinculum to work. I cracked it open slightly, but eventually gave up due to frustration. Also, the SD work by Rokicki was so elegant (and it worked too!) that I moved on.

Jim C

BTX
04-02-2007, 12:02 PM
Thanks so much... Jim.
The point, is that I need about 700-800 Kbytes/sec, I'd a hope in the Vinculum, that it gets more than those values, but it seems that noboby get it work fine yet.
Except BriamCMM, he talk in this thread about get it work fine in FIFO mode...so I would like that he share his code, at least to see if really is faster.

I need to send an AVI (non compresed and "adapted") file, to some electronics to get the final 30fps (not easy), I never tried with ethernet, so I've no time to deal now with such a difficult task, (It's hard than a simple VDIP).

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Regards.

Alberto.

Tom Bampton
04-02-2007, 04:38 PM
Well, that would at least partly explain why I couldn't get the VDIP1 working in FIFO mode a few weeks back :) Higher priority stuff got in the way so it is currently on the shelf, but I intend to revisit it at some point soonish.

BTX,

As you are actually getting a response from your VDIP1, you are clearly close to getting the thing to work. Why don't you post your code and see if anyone can help you fix it?

On the other hand, if you are getting a Bad Command response back when you send it a command, clearly you are also at least writing something to it. Have you have checked that you are using it in the right mode ? For example, are you sending commands in ASCII when it wants them in hex ?

T.

BTX
04-02-2007, 08:58 PM
Hi Tom.
I too really thought that I was close to get it work, but after two days of trying, really now I'm getting frustrated, yesterday Sunday, I get the VDIP response, but only that in all day of work again.....
The code is in spin I 'll post it.......but it's only pieces of code 'not nice' .
Now, that you talk about ASCII or HEX commands.......I'm asking myself....How to send the data in both ways ????? Which is the difference ???? VERY GOOD POINT THAT !

I'll post the entire and final code, when I get it work fine too (hope ......)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Regards.

Alberto.

BTX
04-03-2007, 12:53 AM
Hi friends !!

I just get to send commands to the VDIP succesufully !!!!!!!!!!!!!!!!!!!!! in FIFO mode.

Again more, there is some miserunderstanding or bad data in the firmware datasheet.

I will post some code early, of what, I'm doing. I PROMESS.

Thanks all for your support.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Regards.

Alberto.

Graham Stabler
04-03-2007, 01:24 AM
Great news!

Graham

BTX
04-03-2007, 03:02 AM
Thanks Graham !!

I'm testing now, the read speed in FIFO mode working in spin, .....I think I'll have it early !

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Regards.

Alberto.

BTX
04-03-2007, 05:10 AM
Hi all.
Here's the code in spin, to read data from the VDIP in FIFO mode.


Note:
IT IS NOT the final code !, be carrefully, it is very simple, and the programming technics are poor, but WORKS fine. You probably need, to to it all better, just for the method that I used to read the VDIP responses, perhaps it wont work with another pen drive than mine.
But....this is the way to get the VDIP work in this FIFO mode.

Good Luck.

·

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Regards.

Alberto.

Tom Bampton
04-03-2007, 08:47 AM
Awesome! I am glad you got it working :)

I have been intending to get back to the VDIP1 next week so I will definately be looking at this then. There is just the "small" matter of shipping an alpha of our secret project first ... you'll find out what is next week, but I think you guys are going to like it :)

T.

BTX
04-03-2007, 10:58 AM
Thanks Tom.
But only I get is about 10-20Kbytes/sec in spin, now I'll be testing it in assembler, perhaps on Wednesday morning.
At the momment, I'm not so happy with the VDIP, I'd hope to get more speed in spin.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Regards.

Alberto.

rokicki
04-03-2007, 11:34 AM
Could you post the full archive of the code you are using to time things? Maybe we can speed things up.

It looks like the actual read-a-byte code is simple enough that it should work pretty quickly even in Spin.
But there are some elite spin hackers watching this who I am sure would be able to squeeze out a lot of
performance from the Spin loop.

Anyway, good to see progress on this! Many people are waiting, I am sure.

Tom Bampton
04-03-2007, 11:41 AM
The low speeds with the Spin version are not entirely surprising. I was going to do something similar to the full duplex serial driver, that is have a cog running an asm driver that handles reading/writing to/from a buffer in hub ram. Actually, come to think of it, it should be a less than 5 minute job to hack the full duplex serial driver to talk to a VDIP1 in FIFO mode. You'd probably want to increase the buffer size a bit, though.

BTX
04-03-2007, 08:31 PM
Rokicki:
The code that I used to test the speed is basically the same as I post except that in the last read loop I put two variables storing the cnt value at this time, one before and one after the repeat loop, then I saw which is the difference between them in "number of cycles" so I know the speed (with a not so good precision). Something like this: (the code reads 1152 bytes of data from the file)
·

su := cnt


repeat 1160
temp := INA[RXF]
repeat while temp <> 0
temp := INA[RXF]

!outa[VRD] '
dato[x] := INA[7..0] 'To read data sent by the VDIP
!outa[VRD] '
x := x + 1


sd := cnt
time := sd-su ' Time is about 11Kbyte/sec. 21Kbyte/sec max in spin
tv.dec(time)

I prefeer to put some code more, but with a piece of·it in assembler, the last code that I use in spin is basically who I post, but optimized.

Tom: I'm not a good programmer, it could take to me 5 months ! not 5 minutes, I'dont know why you say to increase the buffer size ?
at this time I don't remember if I·post a code reading only 15 bytes of data (Could be for that ?).
I think to use an assembler rutine method, similar that I did for TLC5940, to share data in main memory.


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Regards.

Alberto.

rokicki
04-03-2007, 11:20 PM
The code looks okay, but there are some minor optimizations; the inner loop might be a bit faster if coded like:




repeat 1160
repeat while ina [ rxf]
!outa [ vrd]
dato [ x++] := ina [ 7..0]
!outa [ vrd]




But I'm not sure how much of a difference that would make. Certainly worth a try.

You also mention that you get "about 11Kbyte/sec, and 21Kbyte/sec max in spin"; these
numbers are different by a factor of two. Have you seen both measurements?

BTX
04-04-2007, 12:14 AM
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.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Regards.

Alberto.

Graham Stabler
04-04-2007, 03:16 AM
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

BTX
04-04-2007, 04:30 AM
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.

See you later.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Regards.

Alberto.

Graham Stabler
04-04-2007, 04:45 AM
I noticed the RST pin.

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

BTX
04-04-2007, 08:57 AM
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.

BTX
04-04-2007, 12:09 PM
I'm getting crazy with the assembler version Graham.
Work it ?


mov t2,outsI ' P10, P11 Outputs P0-7 Inputs
mov dira,t2



again mov t7,ina 'Check for RXF to be low
and t7,RXF
tjnz t7,#again


outsI long 3072 'For pins P10 and P11 as out
RXF long 256

It seems that not.
Why ?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Regards.

Alberto.

QuattroRS4
04-04-2007, 12:19 PM
Well done Alberto - you were chasing this for a bit ..

Regards,
Quattro

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Necessity is the mother of invention'

Graham Stabler
04-04-2007, 04:27 PM
Alberto,

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

BTX
04-04-2007, 07:56 PM
Thanks Quattro.

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 Stabler
04-04-2007, 08:01 PM
I did but I will check it with a volt meter to be sure it is actually 5v and not just a piece of wire :)

Graham

joede
04-04-2007, 08:23 PM
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.

BTX
04-04-2007, 08:51 PM
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
D:\>


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Regards.

Alberto.

BTX
04-05-2007, 12:42 AM
Guys.
I've the assembler code for read a file working, and a assembler code for take out the data from the VDIP working too !! http://forums.parallax.com/images/smilies/smile.gif

I'm stopped now, trying to check the final speed of both asm rutines. :-(

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Regards.

Alberto.

QuattroRS4
04-05-2007, 01:50 AM
You really stuck with that task Alberto - fair play .Is the VDIP as good as you thought it would be ?

Regards,
Quattro

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Necessity is the mother of invention'

BTX
04-05-2007, 04:25 AM
Quattro.
Absolutely NOT !!
I only got about 45-45 Kbytes/sec. in·my final try in assembler http://forums.parallax.com/images/smilies/sad.gif
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.........http://forums.parallax.com/images/smilies/rolleyes.gif

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Regards.

Alberto.

Mike Green
04-05-2007, 05:43 AM
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.

Graham Stabler
04-05-2007, 07:15 AM
Alberto,

I have 5v and no flashing. I think I have a dead dip.

Graham

rokicki
04-05-2007, 07:15 AM
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.

So let us know more about the big picture please.

BTX
04-05-2007, 09:24 AM
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.


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Regards.

Alberto.

BTX
04-05-2007, 11:49 AM
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 !

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Regards.

Alberto.

Envio editado por (BTX) : 4/5/2007 4:33:52 PM GMT

joede
04-05-2007, 05:39 PM
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).

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. http://forums.parallax.com/images/smilies/cry.gif

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...

BTX
04-05-2007, 08:19 PM
joede.

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.

BTX
04-06-2007, 12:37 AM
Rokicki.
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.

rokicki
04-06-2007, 01:12 AM
Howdy!

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.)

rokicki
04-06-2007, 01:24 AM
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.

BTX
04-06-2007, 01:46 AM
Howdy ?????????????????????????????? What's this ?

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.

rokicki
04-06-2007, 03:09 AM
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[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.

rokicki
04-06-2007, 03:24 AM
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.

BTX
04-06-2007, 03:25 AM
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.




▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Regards.

Alberto.

BTX
04-06-2007, 03:30 AM
Sorry ..my forum seems to be not synchronized with my answers. Just see you last two posts.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Regards.

Alberto.

rokicki
04-06-2007, 03:31 AM
That's the fun thing, and the thing I think you can figure out, but I will help if you really want me to, is how to coordinate the
reading and the sending. It's not that hard; think of how you'd do it if you had a friend doing the reading and another friend
doing the writing and a big old shared memory; what would you guys have to say to each other to arbitrate use of that buffer.

I only mentioned the cog limitation in case you were doing a bunch of other things at the same time. (For instance, the SD
assembly itself takes a cog, the TV takes a cog, the keyboard takes a cog---you have eight to work with total.)

I'm not trying to be coy, and I'd be happy to offer suggestions on how to do the arbitration, but I think it will be fun for you
to figure it out and play with it. It is, after all, your design.

Mike Green
04-06-2007, 03:33 AM
On question is whether you have enough memory available for a second buffer. If you have memory for two buffers (or one buffer of twice the needed size), you can have your routines alternate buffers. The SD read routine reads into one buffer while the master-to-slave routine transmits from the second buffer. When they're both done, they swap buffers (actually swap buffer addresses).

rokicki
04-06-2007, 03:38 AM
Right, but don't limit your thinking to two buffers. Consider using three or four, for instance, or even eight, or more, in order to compensate for reading jitter.

Or just a big ring buffer.

Essentially, you want to be prepared for the fact that some reads may occur slower than others. If you use the high-level SD read routines, every once in a
while it needs to actually read *two* blocks to get one block of data (the second block is the appropriate FAT table entry) and this will introduce jitter.
(If you guarantee that the file is contiguous, and you skip the filesystem code and just read sequential blocks, this source of jitter goes away.)

I will note that the SD read routines do do a memory copy to load the data, and this slows things down a bit. That memory copy can be eliminated in some
cases (I just haven't added the code to do so) if the reads are always in chunks of 512 bytes or multiples thereof.

Post Edited (rokicki) : 4/5/2007 7:48:31 PM GMT

BTX
04-06-2007, 04:26 AM
Rokicki said...

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).

The (r) value is 4001 in the example, like we hope.... just I ask for read 4001 bytes.


Rokicki said...

3. Not sure what this is here for; you don't need it:
repeat while tbuf[4000] == $00

I implement that, to know the exactly momment, that the SD rutine wrote the last byte of data in the buffer. Is that not correct ?

If I erase that line, I will be reading the time, that the last instruction takes in·spin ? don't ? Or the code:

····· r := sdfat.pread(@tbuf, 4000)
is still, while reading the data ?


Rokicki said...



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.

To test how fast I can send the data from one prop to another, I'll have some problems now, because I've not still designed that board.
I only could try to do it, by connecting my actual board, to the 'demo board', but would be complicated the connections between them (wire lenghts) and will have differents clocks each props, (Chip reccomend me, to use one "chip·oscillator" for all master and slaves).

To do that comunication, I think to send a first·byte "of address" plus·a "logic one" in a ·common line to all props, indicating that the byte at the bus is an address, then send the bytes for the addresed prop. The addresed prop will respons too, with a another common line·between them (OR'ed with diodes)·to let the master to send the next byte.
Another way, could be, to use one I/O of the master for each slave (16 I/O total for this) plus eight for bus, plus four for SD, plus two for the EEPROM....although it coul be a faster code, I think that's better to have more I/O pins free...·(so, an easy PCB design and safety under noises ...taking in care that it'll be single side PCB).

What do you think about it ?






▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Regards.

Alberto.

BTX
04-06-2007, 04:28 AM
Sorry guys I'm lefting now, I'll come back at night .... for answers.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Regards.

Alberto.

rokicki
04-06-2007, 04:44 AM
Alberto,

To test sending between props, at least for now, just do it all on the demo board with a single prop. Use one cog for writing, and one cog for
reading, and have them communicate just like they would if they were separate props. At the speeds you will probably be working at, this
is probably just fine (especially if you use a simple asynchronous signalling mechanism such as the one you describe).

By the way, no need for diodes; instead of transitioning the acknowledges between 0 driven and 1 driven, transition them between 0 driven
and undriven, and use a pullup resistor.

BTX
04-06-2007, 09:24 AM
HI.

Mike, Excellent idea !! in that way I can be working at the same time with both rutines....

Rokicki, Excellent idea too !! I don't need the board made, to test the master-slave code.... (I also will not use diodes)

I take out·mine 'repeat xxxxxxxx' line of the code.

About the buffers, I see that the maximun speed that·I get, is when the buffer size is 4000 bytes. (don't know why...but is about your code 'I suposse'). More bytes decrease·my read speed and minus too.

To have more than two buffers will take a lot of memory too, but if in example we have 'N' buffers, I think a 'mix' of the Mike idea and mine.

Flags to indicate the state of·each one of the·'N' buffers, when·the card·finish reading some data and the buffer is full, check for a valid flag and·get that buffer, for the next data. The master-slave rutine must do some similar, except that it choice the previous buffer used by the SD code to get the data. So, more small buffers,·and·there is not· lose time. In fact, I need to send with·each slave, 1152 bytes out/time.· I could aplicate the same method for the slaves, to comunicate with the rest of the electronics.

The file/s that will be in the card, are longer/s like 20Mb, ·How ?·I guarantee that the file is contiguous.

If you mean that is not necessary the FAT file system in that case, I could not copy the file·easily from a PC ? I must do a rutine to send it by USB port and save to the card with the SD code...It will take me more cogs, memory, pins, and time to pass the data from the PC and save it in the card. is that correct ?

Another point...you give me a great idea...perhaps I could use a keyboard and a TV, to have a screen showing me, some info·about the system state. All that, in the Master prop, but only while it wont take my speed down.









▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Regards.

Alberto.

rokicki
04-07-2007, 02:01 AM
Adding keyboard/monitor support will not slow things down. It will increase power consumption marginally, but no big deal.

To guarantee the file is contiguous, simply freshly format the card and then copy the file and it should be contiguous.
(You only will get noncontiguous files if you ever delete or overwrite a file.) But I wouldn't worry about this right now.
Just stick with exactly what you are doing. 20MB is not a problem at all.

If I were you I would probably start with a ring buffer of 8K, as 16 512-byte blocks. Or if it's easier for you to think about
just do it as 4 2048-byte blocks. Use 2048, though, not 2000 and not 2001. (It should be a multiple of 512 for the best
speed.) The reason to use more than two buffers is in case one operation is occasionally slow; since you only have the two
buffers, you don't have any real ability for the reading routines to get far enough ahead to make a difference.

Later on I can make a special version of the SD routines for you that will eliminate the memory copy in read() and thus be
a tad faster than what you are using.

BTX
04-07-2007, 03:29 AM
Rokicki.
All understood. You've the things very clear...I tried with 512, 1024, 2048, etc and it read faster...390 Kb with my card.

Rokicki said...
Later on I can make a special version of the SD routines for you that will eliminate the memory copy in read() and thus be
a tad faster than what you are using.
That will be great for me!!!!! I suposse so, that I must solve the·master and slave code now, testing it with the actual speed, and leave the faster version for later, correct ?.
I'm trying just now to do the master code with·'shared memory' between·'abuf and a bbuf', but i'm stopped now at secondary assembler problem, due my low experience with it.

Let me know please,·If·this code work ?


Sending mov adrrptr,par ' adrrptr address of the abuf
add adrrptr,toadd ' add 2048/4 to the address of abus to know if data was read by SD
rdbyte status,adrrptr wz ' read that address pf the abuf
if_nz jmp #use_abuff ' uses the: use_abuf piece of code to send data to slaves from abuf
add adrrptr,toadd ' add 2048/4 more to the address (same as before)
rdbyte status,adrrptr wz ' same
if_nz jmp #use_bbuff ' same
jmp #Sending ' If there are not data in abuf or bbuf loop
·In this piece of code, I read the data, and put it in the apropiate buffer, and then save a aditional byte of data in that buffer, to check when the data was full save, so If I have a buffer of 2048 to save the file data, I do it 2049 to save the 'flag' in the aditional location. Each time the SD code·save the data in the buffer, I do: abuf[2048] := 1, if not abuf[2048]·:= 0, since SD code save the data from locations 0 to 2047.
This is NOT working....why ?




▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Regards.

Alberto.

Envio editado por (BTX) : 4/6/2007 7:45:41 PM GMT

Mike Green
04-07-2007, 03:44 AM
Alberto,
When you display code fragments, it helps to also show the variables. Based on the comments (like "add 2048/4"), you're mixing up main memory addresses (byte addressing) with cog addresses (long addressing). You should add 2048 to adrrptr the first time and 2049 the second time.

BTX
04-07-2007, 04:00 AM
Sorry Mike ..
I've this:


var
'
long cog

PUB Start(Adrr) : Success


Stop
Success := (Cog := cognew(@Sending, Adrr) + 1) ' El dato contenido en direc tiene que ser = 0 para que no mande data a los TLC


PUB Stop
{{Stop toggling process, if any.}}


if Cog
cogstop(Cog~ - 1)


dat
org
Sending mov adrrptr,par '
add adrrptr,toadd
rdbyte status,adrrptr wz
if_nz jmp #use_abuff
add adrrptr,toadd
rdbyte status,adrrptr wz
if_nz jmp #use_bbuff
jmp #Sending



use_abuff nop ' still doing


use_bbuff nop


call #delay ' Only temporary to check if work it with the spin rutine
mov temp,par
add temp,toadd
wrbyte zero,temp '
jmp #Sending


'------------------------------------------------------------------------------------------------------------------------------
Delay
mov t8,delt '
reta nop
djnz t8,#reta ' Lose 200 clk cycles
Delay_ret ret
'------------------------------------------------------------------------------------------------------------------------------
delt long 100000
zero long 0
toadd long 512
adrrptr byte 1
status res 1
t8 res 1
temp res 1



·The code must loop at 'Sending' unless the SD code save all data in·abuff, In the spin code there is a abuf[2048]:=1 to indicate this. after the SD code finish to read.
Hope it is clear now.





▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Regards.

Alberto.

BTX
04-07-2007, 04:17 AM
Great Mike ..!!
Correct, I fix it....why to say the you're a genius too ?... all forum members know it.
Thanks.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Regards.

Alberto.

Mike Green
04-07-2007, 04:24 AM
Alberto,
You've declared adrrptr as a byte. It's not a byte. You need to declare it as a long.

rokicki
04-07-2007, 05:23 AM
Frankly, I was hoping you would do the top-level management with a spin routine (it's not performance critical after all).
Only the lowest-level SD I/O and prop->prop communication routines should be in assembly, I think. Why mess with
assembly when you don't have to? Spin code is generally more compact anyway.

And I would even start by writing the prop->prop routines in spin, to tell the truth.

What I was hoping to see was a prop->prop sender routine, in Spin, and a prop->prop receiver routine, in Spin, and
a top-level object to start both of these and then report on their speeds/progress. Once this works well we can
recode each in assembly (and test them, spin vs assembly and assembly vs spin, rather than trying to debug both
simultaneously).

BTX
04-07-2007, 05:24 AM
Mike.
You're right again...... "that's an address and can't be a byte" unless the address is under 255. (but I'm not sure too, if it never can....)

I just correct it, I don't know now...how it seems to work ?? (perhaps, like I was checking only the abuf, and it got an address under 255 ??..i'm not a lucky man..) but don't care of that, It is working too, in the correct way.

Thanks.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Regards.

Alberto.

BTX
04-07-2007, 01:07 PM
Here's my first try in spin to read the data in the card, I get 368Kb, not so bad to be in spin.
I'll go by the Master code on Saturday.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Regards.

Alberto.

BTX
04-08-2007, 07:35 AM
Hi All !!
Here is the Master code in spin.
At this·time, I have the SD reader code, working togheter with the Master code, only two cogs are still used.
I'm going now, for the 'Slave' code, I'll do it in the same prop, to let check the speed, after.

It seems·to work fine, but I was unable to find the way to check the speed of it all (SD and Master), "supossing that the·'Slaves', will answering faster·the requests from the Master".

Here's the actual code.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Regards.

Alberto.

BTX
04-08-2007, 10:04 AM
Hi again..I'm speedy this time.
Here is all the code, Master and Slave.

Tom.
Please, check it for me. ok?
Too much hours programming...seems to be ok, but.........
Thanks !.


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Regards.

Alberto.

BTX
04-10-2007, 12:23 AM
Some suggest about it ?
Thanks.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Regards.

Alberto.

PointDog
04-12-2007, 12:27 PM
Hi, all,
Sorry to butt in, and I know that BTX has since decided to use an SD card instead of the Vinculum VDAP chip, but as I mentioned on my earlier post I am using one, and if any other propeller-heads are searching for answers, they'll probably come across this thread. I have the vdap working perfectly and would like to share some gotchas. I haven't posted my driver code because it's in MPLAB C30, but this info will help propeller users anyway.

First BIG thing that can cause MAJOR headaches is power supply. I put a 1uf and a 100nf in parallel near the chip, because it would randomly stop working. This seemed to fix it.

The reset pin is extremely sensitive to noise, perhaps an RC setup would be good rather than tying the pin directly to the power supply rail, but remember, you _WILL_ need to have a way to re-set the vdap from your code (connect the reset to an IO pin on the prop, with a capacitor to ground) because certain errors can cause the vinculum to lock up irrecoverably.

The transfer speed is dependent on the device attached, I tried an old 128mb flash disk that i got as a freebie and got 56kB/sec write and 88kB/sec read. But my code is more focused on robustness and error handling than speed. I noticed also that using the command "WRF 256" got abut 14kb/s write, but increasing the block size to "WRF 1024", increased the speed to the 56kb/sec mentioned above.

The 0x90 (IPA) and 0x91 (IPH) commands do not work in shortened command mode. (Using VDAP firmware version 2.19 with the command monitor port in FIFO mode.) Even though they are listed in the datasheet.

The command 0x10 will never be used because the chip must already be in shortened command mode to use it.

The comand ECS will never be used because the chip must already be in extended command mode to use it.

The FIFO RD and WR pins are switched on the ver 1.07 VDAP Firmware data sheet. -- Thanks for pointing this out BTX!

the 0x08 command (WRF) actualy returns 2x <prompt>, after the data has been written. This can cause the expected data stream to be offset by 1 byte on microcontroller systems.

The WRF command will return a prompt if the first part of the command is ok. (WRF<space><size><0x0D>) and then a "Bad Command<0x0D>" if there was a problem with the <data><0x0D> part of the command. So a good WRF command will return <prompt><0x0D><prompt><0x0D>, but a bad command will return <prompt><0x0D>BC<0x0D>, and I assume that a failed write will return <prompt><0x0D>CF<0x0D>.

Nowhere in the datasheet is the maximum size of a write (or read) operation mentioned. In actual fact, when using ECS command mode, and IPA input mode the maximum write size using WRF is 9,999,999 bytes because the chip automatically starts to write data to the open file after 8 ascii characters, regardless of whether it sees an 0x0D character at the end of the command or not. This behavior should be doccumented, or better still the chip should return a "Command failed" when it recieves the 0x0D byte, if the data size requested is longer than the allowed number of characters. The current behavior can result in an unrecoverable "lock up" if the WRF command format is incorrect, because the chip will not abort a write operation, even if the disk is removed.

If the flash disk is removed during a WRF operation the chip will lock up unrecoverably, requiring a reset, or power down. This behavior should be doccumented, or changed.

The VDIF (Ver 1.06) had to be used to get some of the required information, because the VDAP 1.07 datasheet did not contain all of the information about the disk interface, some of the discrepancies are:

a)The information in section 2.3 (Start Sequence) of the VDIF datasheet is not in the VDAP datasheet.

b)The information on Page 9 of the VDAP datasheet, regarding the difference between ASCII and HEX input mode is not in the VDIF datasheet.

I hope this helps someone.http://forums.parallax.com/images/smilies/smile.gif

BTW are there any ICD or ICE tools available for the prop yet?

Mike Green
04-12-2007, 12:47 PM
Thanks PointDog, that's very helpful.
Mike

BTX
04-12-2007, 09:22 PM
Thanks so much PointDog for the info..
But i've decided to use the SD, beceause no enough speed for me with vinculum, I obtain only about 45-48Kb reading it, and I know, that with some code improvements would be possible to obtain more, but, how much more ?, sure it will be far from my needs. (500Kb - 700Kb)
I was thinking that, if VMUSIC reads at least 128K to get the data (I don't know which firmware it uses), there will be a way to do it, but not much more of that speed.

The problem of "why I can't get more speed with it", I think it becames from the time to read the FAT with the VDIP (FTDI people confirm it to me), once your command had readed the data, you could extract it from the VDIP faster, in FIFO mode.
Like you comment it depends of the disk used....and with the last 2.19 firmware it works ok, I've included too, a reset pin directly from the propeller, if not, was impossible to syncronize my code with the hardware.

About the 0x10 command you are right too, I was broking my head until some people from FTDI told me that.
And is correct too, a "CF" message is sent from the VDIP, if a command failed.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Regards.

Alberto.

bambino
04-12-2007, 09:44 PM
PointDog said...
BTW are there any ICD or ICE tools available for the prop yet?
There are no hardwire tools other than a debug terminal. Their is some success with GEAR, and POD.
I may be wrong but I think Gear is a ICE and POD is an ICD.

PointDog
04-13-2007, 02:20 PM
BTX,
you are definitely right, if USB 2.0 full speed is used, the bus runs at 12Mbits/sec, even with a standard serial protocol with no error checking, and no retries, framing etc the max speed is 1.2Mbytes/sec. I think that the "real" transfer rate of the Full speed USB bus is probably down around the 800kb a second anyway, taking into account all the other data that is passed along the bus to control and sync the devices. If you change your mind I can do a test run with a read of a large file, using large blocks, but I think it will still be well below your requirements.

All the best with your project, and to all members of this forum, keep it up. This is probably the most active and helpful microcontroller forum around, If I could bear to forget my years of experience with PIC's and C, I'd be using props for everything.