Fastest method of communicating with the computer?

Vaati · 2011-04-02 09:22

What is the fastest method for the propeller to send data to the computer? FullDuplexSerial is too slow for my liking...

davidsaunders · 2011-04-02 09:26

The fastest method would be to make a custom PCI card to communicate at 4MB/s parallel, baring this use a high speed Parallel port.

What type of speed do you need?

DynamoBen · 2011-04-02 09:54

Ethernet or USB (FT245) might also be a viable option, depending on how much speed you need.

Vaati · 2011-04-02 09:55

Well, I'm aiming for at least 1MB/s, but a little below that would also be fine. It's just that the FDS ended up slowing down my program too much. Maybe I'm just using it wrong, but still, I'd like something faster anyways. ;-)

DynamoBen · 2011-04-02 10:00

A wiznet module would be able to do that via ethernet, see spinneret project for code. And I believe the FT245 should be able to keep up, there is code somewhere in the forums and maybe even in the OBEX of it.

Vaati · 2011-04-02 10:08

Well... I want to do this with as little external hardware as possible, so I'm looking more along the lines of this, except for communicating with the computer, a little slower, and not so much cog usage. Oh, and one other requirement -- I have 4 spare I/O, so it needs to be simple. ;-)

I don't know if this is possible anymore, after writing this all down...

DynamoBen · 2011-04-02 10:11

Vaati wrote: »

Well... I want to do this with as little external hardware as possible, so I'm looking more along the lines of this, except for communicating with the computer, a little slower, and not so much cog usage. Oh, and one other requirement -- I have 4 spare I/O, so it needs to be simple. ;-)

I don't know if this is possible anymore, after writing this all down...

The PropPlug is technically capable of communicating at up to 3Mb/s, you will need to write you own driver to get the speeds you are hoping for. I would suggest either a half-duplex driver or using two cogs to get full-duplex.

JonnyMac · 2011-04-02 10:11

FDS is slower than you want because it's dividing time between two processes, and the TX process -- even when not transmitting -- has to check the hub to see if there's anything in the TX buffer. You can speed up comms by using separate TX and RX cogs, and give them their own pins (you only need two).

Heater. · 2011-04-02 10:20

Vaati,

That USB code you linked to implements the HOST end of the USB protocol. In order to connect your Prop to the PC as a DEVICE you need to implement the DEVICe end of the Protocol, the HOST end being your PC.

There is a USB DEVICE implementation for the Prop here http://forums.parallax.com/showthread.php?97027-California-Dreamin

Edit: Improved versions here:http://forums.parallax.com/showthread.php?97328-USB-toys-to-play-with

I believe it can be used as a USB serial device. No idea about the maximum data throughput rate.

davidsaunders · 2011-04-02 10:25

Also according to the specs on the FTDI 232, it should be possible to communicate at up to 3Mbps = 0.375MB/s this is a lot faster than the standard serial drivers, though only about 1 third of what you are shooting for. Using only 4 pins, you would pretty much have to go serial of some form, witch I think limits you to about 4Mbps = 0.5MB/s, sorry. Maybe some one knows a trick I do not. You may be able to use 2 serial connections in parallel (2 pins each), at 4Mbps each = 8Mbps = 1MB/s. Though I do not know how you would interface that to your computer easily.

Vaati · 2011-04-02 10:54

I'll just post my current code so you know what I'm trying to do. Right now, it uses the 1-pin tv text.

con

  _clkmode = xtal1 + pll16x
  _xinfreq = 5_000_000

  OE = 25
  CS = 24

var
  
  word  addr
  byte  data
  
obj

  tv: "Debug_1pinTV"
  pc: "serial_terminal"
  
  
pub start | i

  'OE = output enable on ROM
  'CS = chip select on ROM

  addr:=%0_0_0_0_0_0_0_0_0_0_0_0_0_0_0_0                'set address as first address in memory
  
  dira[OE]~~                                            'make OE an output
  dira[CS]~~                                            'make CS an output
  
  dira[0..15]~~                                         'make P0 thru P15 outputs 
  dira[16..23]~                                         'make P16 thru P23 inputs
  tv.start(26)
  tv.chr(0)                                               'start the tv text object
 
  repeat i from 0 to 65535                         'change the end value to however many memory addresses your rom has
    outa[OE]~                                           'make OE low 
    outa[CS]~                                           'make CS low
    outa[0..15] := addr                               'write address
    Pause(5)
    data := ina[16..23]                                 'read data from rom
    outa[OE]~~                                          'make OE high
    outa[CS]~~                                          'make CS high
    tv.hex(data,2)                                      'display the data stored in the respective address on the screen
    addr++                                              'increment address
    Pause(5)

PRI Pause(us)

  ''Calculates the pause rate in microseconds
  waitcnt((clkfreq/1000000)*us + cnt)

I have it connected like it is shown here except it now uses the USB propstick, and that picture shows it using the standard 3 pin tv interface. I have yet to take new pictures. ;-)

Essentially, I want to have a decent communication speed between the propeller and the computer so I can dump the contents of rom chips to a file.

davidsaunders · 2011-04-02 11:13

Connect through the Prop Plugs FTDI and dump the data at the rate you are displaying it, witch is pretty slow. Or if you need to dump it faster than that, it would only take about 0.7 seconds to dump the whole ROM (assuming that the data sheet is accurate on the abilities of the chip).

Vaati · 2011-04-02 11:22

Davidsaunders,

So, for the pauses between addressing and the pause between display and the next cycle, how small can I make those? the datasheet says the minimum time between addressing and reading is 100 ns, which is 0.1 microseconds. Would I be safe doing that, or would that jeopardize the accuracy of the data I'm getting?

0.7 sounds like a great goal for a 64KByte rom... For that, would I just make the absolute minimum pauses in read cycles?

EDIT: What would I use to communicate using the prop plug? Just JonnyMac's code he posted? Also, I just realized that I have a total of 6 pins available for communication (P26 to P31), but I don't know if that'd make much difference.

davidsaunders · 2011-04-02 11:44

As to your rom I do not know the spec. As to data transfer to the PC from the prop, this would probably require a custom driver on the Prop (unless some one has written one already for the high speed stuff). His code looks a little slower than absolute max.

Vaati · 2011-04-02 12:03

Well, I managed to dump the entire chip in about 26 seconds, just using the normal FDS object. I think I was somehow using it incorrectly before....

Also, I couldn't get any data when the two pauses I have in my code were set to 1 microsecond... I think that's too fast for FDS to handle correctly.

pjv · 2011-04-02 19:57

Vaati;

Sometime ago I posted a thread with very compact assembly code for continuous serial ASCII communications at 5 Mb/s, and would write or read sequentially from hub ram. If that is interesting to you I would find that links for you.

Cheers,

Peter (pjv)

RS_Jim · 2011-04-03 11:04

Vaati;
here is the link the pjv is talking about, I think! http://forums.parallax.com/showthread.php?120125-5Mbit-sec-ASCII-streaming-from-to-Hub-RAM
Jim

dMajo · 2011-04-05 03:37

Vaati, FTDI have a new product FT232H with transfer speed of up to 40 MB/s. Take a look.

davidsaunders · 2011-04-05 14:02

Slightly off topic:
What happens if FTDI discontinues there USB to serial, and USB to FIFO chips? Then is there a good and reliable replacement for the next gen Prop Plug and the like?

DynamoBen · 2011-04-05 14:06

davidsaunders wrote: »

Slightly off topic:
What happens if FTDI discontinues there USB to serial, and USB to FIFO chips? Then is there a good and reliable replacement for the next gen Prop Plug and the like?

Any USB IC that has a virtual com port driver should work fine.

davidsaunders · 2011-04-05 14:12

Thank you. I was only aware of the FTDI devices.

localroger · 2011-04-05 16:07

USB-serial is a big market; a lot of legacy industrial equipment and new embedded stuff simply can't do USB. FTDI is going to be making those chips for a long time.

davidsaunders · 2011-04-05 16:37

I do see that there is a lot of need for serial. Though I think most who need it have a PC, and therefore an RS232 port. I only use the Prop Plug because my RS232 ports are not clean enough at higher speeds (you want some interesting waveforms that should not be?), and I would think that the same is true for all that use the Prop Plug or similar, either that or they need the multi MB/s transfer rates.

localroger · 2011-04-07 17:58

But it's getting very hard to get a new computer, particularly a laptop, with normal serial ports at all. Fortunately the new generation of USB-serial chips (including FTDI) seem to work pretty well (the early generations were prone to lock up and behave erratically). I haven't seen a new computer that wasn't special ordered with a serial port in at least three years, and I'm aware of several situations where the special order was not possible because it simply wasn't an option.

davidsaunders · 2011-04-07 18:36

It is still quite easy to get a Gigabyte MotherBoard with standard serial ports, supporting all the latest gen Intel and AMD CPUs. And if you need a different brand of motherboard that does not provide these, the PCI cards are only about $10 to $15 USD. And this is why I always build my own system. The 'Windows PCs' are supposed to be IBM PC/AT compatible, or IBM PS/2 compatible either one requires standard 25 or 9 pin RS232 ports, thus building one without one does not make any since.

ke4pjw · 2011-04-07 19:32

The fastest method I have seen so far for communication between a prop and a PC is my FullDuplexParallel object. See my signature. Using the default windows driver for the FT245, you should be able to achieve a real 3Mbps throughput. (Provided whatever you have reading/writing to the circular buffer is fast enough)

Beau Schwabe · 2011-04-07 19:36

ke4pjw,

JonnyMac, posted a couple of routines. I didn't look at the Receive, but I did look at the Transmit, and it's very close (identical almost) to one that I have been using that will go to 3Mpbs... and could probably be pushed a little further since I still had NOP overhead to throttle the output.

ke4pjw · 2011-04-07 19:53

Beau,
It's been awhile, but IIRC, in my testing (and it was completely anecdotal) when doing bi-directional communication, most of the serial objects would fall over at about 500kbps when reading large amounts of data. I may take a look at what Johnny has done when I get a chance. It would be nice to reclaim some pins

Though, I am sure you guys have much better skills with such matters than me

I just decided to write something that worked for my project. It's the only communications channel I have had between the PC and prop that just let's you set the com port to it's maximum setting and everything "just works". YMMV

Beau Schwabe · 2011-04-07 19:59

ke4pjw,

This would only be valid for Transmission from the Propeller at that speed, not sure it could keep up for Receiving.

The 'key' transmission loop in JonnyMac's code is copied below... the only difference I had was that the waitcnt was substituted with NOP's

txbit                   shr     txwork, #1              wc      ' move bit0 to C

                        muxc    outa, txmask                    ' output the bit

                        waitcnt txtimer, bitticks               ' let timer expire, reload   

                        djnz    txcount, #txbit                 ' update bit count

Vaati · 2011-04-16 10:17

Well...

I got back to working on this project yesterday, and I switched from using the simple_serial.spin to just the fullduplexserial.spin, and it cut off 6 seconds. (now it takes around 20 seconds to read it)

I had also tried using JonnyMac's tx object, but for some reason, it gives me either more or less data then the propeller is actually reading. I tried it twice just now and it gave me around 3Kbytes less the first time, and 20Kbytes more the second time.

I'll check some of the links you posted and see if those speed things up a bit.

lonesock · 2011-04-16 10:25

Beau Schwabe (Parallax) wrote: »
ke4pjw,

This would only be valid for Transmission from the Propeller at that speed, not sure it could keep up for Receiving.

The 'key' transmission loop in JonnyMac's code is copied below... the only difference I had was that the waitcnt was substituted with NOP's
txbit                   shr     txwork, #1              wc      ' move bit0 to C

                        muxc    outa, txmask                    ' output the bit

                        waitcnt txtimer, bitticks               ' let timer expire, reload   

                        djnz    txcount, #txbit                 ' update bit count

You can shave an instruction off that loop using the standard "put a counter in NCO mode, and SHL data out using the high bit of PHSx". You can prep the value to have the start and stop bits as well, and also invert all bits if needed, then just send out all the bits at once.

Jonathan

Fastest method of communicating with the computer?

Comments