PDA

View Full Version : Ethernet UDP from Video shifters ?



heater
01-15-2009, 01:12 PM
Bear with me for a bit as I have no experience in Ethernet hardware or the Props video capabilities.

I just woke up with this crazy idea in mind that if the Prop can generate video scan lines at whatever enormous frequency that is, then those same video shifters must be able to generate 10MHz Ethernet packets. Given that UDP only needs one way transmission, Prop to PC say, this would be a very simple and fast connection to make for data gathering applications, PropScopes, video capture etc etc. Or use it for sending notifications, alarms say, from remote "things" to a PC. Like SNMP does.

So anyone know:

1) What is the minimum hardware required to connect Prop pins to an Ethernet cable ? I'm guessing there are some ready made physical interface devices available. Can this be home made from junk parts ?

2) Can the Props video shifters be seconded into blasting out ethrnet packets, are they fast enough etc ?

3) I presume that the Prop would only need to know the Ethernet and MAC address of the destination to do this. As we will have no ARP that will have to be fixed for a given installation.

4) Is there some other show stopping reason this can't be done ?

Now I know there are "real" networking chips that can connect to the Prop via serial I/O but they are slower and I would guess more expensive.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Ale
01-15-2009, 01:32 PM
I think it is gated at something like 20 MHz. No problem for the video shifters. Now, the substitution in the fram of hsync and vsync can be a bit of a concern,but it may just work http://forums.parallax.com/images/smilies/smile.gif. It is a matter of finding how is the info encoded (Wkipedia has a nice article) and have a couple of test packets sent. Some old network card with a transformer can be used, just scrap those parts.

BradC
01-15-2009, 01:34 PM
Do a search for a thread by hippy where it git it to bit bash UDP a while back. That will give you a start.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.

heater
01-15-2009, 01:44 PM
@Ale, what do you mean about the hsync and vsync ? As I say I need to get into the video on the Prop.

If Hippy was doing bit banged UDP I feel sure he must have thought of this already. Did he not think of it or reject the idea already for some reason I wonder ?

The speed of CRC calculation worries me as it seems to hold up USB. But we don't have any packet turn around times to worry about.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

jazzed
01-15-2009, 01:50 PM
The video generator does not make very good layer 1 ethernet compliant signals.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve

Phil Pilgrim (PhiPi)
01-15-2009, 01:53 PM
Here (http://forums.parallax.com/showthread.php?p=682147) is the thread that Hippy started.

-Phil

Ale
01-15-2009, 04:34 PM
Well, that thread... I forgot about it... says everything you wanted to know, almost http://forums.parallax.com/images/smilies/smile.gif. It sorts of work.

heater
01-15-2009, 05:04 PM
jazzed said...
The video generator does not make very good layer 1 ethernet compliant signals.


Why is that ? Please elaborate, excuse my ignorance on this.

These guys www.fpga4fun.com/10BASE-T0.html (http://www.fpga4fun.com/10BASE-T0.html) seem to have luck just hooking up two pins of an FPGA as a differential signal. Odd because I though at least a transformer was required.

I have yet to find a 10baseT interface schematic out on the net.

Or is it a timing problem you are referring to.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

jazzed
01-15-2009, 09:15 PM
Layer 1 is physical interface, signal encoding, etc....
If you look at the output of the vidgen examples on a scope you will see encoding bit errors.
It's been a long time since I looked, so I don't remember exactly what the problems were.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve

Ale
01-15-2009, 10:18 PM
Realtek's datasheet have circutis, it may be of interest if it is what you are looking for http://forums.parallax.com/images/smilies/smile.gif

http://pdf1.alldatasheet.com/datasheet-pdf/view/142973/ETC/RTL8019AS.html

(Not available at realtek's web site anymore :-(

Edit: Sorry the schematic was in the reference design pdf that now is ... not available :-(

Post Edited (Ale) : 1/15/2009 3:24:12 PM GMT

kwinn
01-15-2009, 11:05 PM
The video circuits are fast enough to generate a signal compatible with ethernet, but that is only the first part of what is required. The physical protocol is CSMA/CD (Carrier Sense Multiple Access/Collision Detection). CSMA requires that each device must first listen to the bus to be sure no other device is transmitting before it starts to send data.
CD requires that it must listen to it's own data to make sure it matches what is being sent. If more than one device started to transmit at the same time the data will be scrambled and both devices must stop for a short random time before attempting to transmit again. This is the more difficult part of the physical protocol to perform on the prop, and still leaves all the other layers of the full protocol to implement.

Beau Schwabe (Parallax)
01-16-2009, 12:59 AM
heater,

"Odd because I though at least a transformer was required." - It should be for proper balancing, and to avoid any ground loops, but for very short runs you might be able to get away without using one.· I would advise against it though.



Using a partial chipset solution with a SerDes (serializer/ deserializer)·and Magnetics/Optics (transformer or·Optic-Transceiver)·would give you an advantage, but you still need to negotiate with a MacPhy of some kind.· Even if you implemented a very basic MacPhy solution within the Propeller·I think that the Propeller·would be able·to send data ok but I'm not sure if the Propeller could receive data fast enough.




▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe (mailto:bschwabe@parallax.com)

IC Layout Engineer
Parallax, Inc.

Post Edited (Beau Schwabe (Parallax)) : 1/15/2009 6:13:12 PM GMT

Bob Lawrence (VE1RLL)
01-16-2009, 01:38 AM
Both references show transformers. Is is possible that some of the R45 sockets for Ethernet include the transformers? I'm sure I have one somewhere.

Microchip ref: Schematic with transformer on page 6 + 9. ( and maybe others)

ww1.microchip.com/downloads/en/DeviceDoc/39662c.pdf (http://ww1.microchip.com/downloads/en/DeviceDoc/39662c.pdf)


Serial Ethernet board from .mikroe.com " Make Ethernet network with ENC28J60 Stand-Alone Ethernet Controller with SPI Interface" ( I actually have this board to try later......... ) http://forums.parallax.com/images/smilies/jumpin.gif

Board schematic and UDP examples included.

www.mikroe.com/en/tools/serialeth/ (http://www.mikroe.com/en/tools/serialeth/)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Aka: CosmicBob

lonesock
01-16-2009, 05:43 AM
I have a vague idea for a method of sending out the data at 20MHz, without using the video HW (not that this is a _good_ idea [8^)

Requirements:
- prop running at 80MHz (so PASM instructions execute at 20MHz)
- 2 cogs
- TX+ and TX- need to be on either P0/P1 or on P30/P31
- output data already Manchester encoded (so a word of data actually takes a long in HUB RAM)

Both cogs set the pins to be outputs, and start with OUTA=0
Then each cog takes a turn reading the next long into a temporary variable (staggered longs).

The PASM would look something like this:


send_at_20MHz
mov data_ptr, ???
mov data_count, ???
preload
rdlong tmp_data, data_ptr
add data_ptr, #8
wait_for_my_turn
' ???
hack_send ' assuming the data is going out on lines P0/P1
mov OUTA, tmp_data
shr OUTA, #2
shr OUTA, #2
...
shr OUTA, #2
' OK, other cog takes over now
djnz data_count, #preload
send_at_20MHz_ret
ret


Would this work? I know this ties up twice the resources of using the video HW _and_ requires the 80MHz clock speed. Not to mention I don't know how to do the exact synchronization btwn the two cogs (without tying up a data line and using a waitpeq command). So, even I'm not sure I see the benefit of this method, other than I don't have to learn about the video HW quite yet http://forums.parallax.com/images/smilies/wink.gif.

Jonathan

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.

Beau Schwabe (Parallax)
01-16-2009, 01:20 PM
Just a thought...

Using a SerDes (serializer/ deserializer) chip will help to lower the bandwidth that the Propeller would normally need if trying to handle the serial stream entirely by itself. With a SerDes you could process a BYTE (7-bits) , WORD(14-bits) , or a LONG (28-bits) at a time within the Propeller instead of bit banging 1 BIT at a time.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe (mailto:bschwabe@parallax.com)

IC Layout Engineer
Parallax, Inc.

Post Edited (Beau Schwabe (Parallax)) : 1/16/2009 6:32:30 AM GMT

Cluso99
01-16-2009, 02:09 PM
@lonesock: It is easy to synchronise cogs using waitcnt. The value is passed via a hub memory location.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Prop Tools under Development or Completed (Index)
http://forums.parallax.com/showthread.php?p=753439

My cruising website http://www.bluemagic.biz

heater
01-16-2009, 04:02 PM
@kwin: You worry to much:) If we have an ethernet cable from Prop to PC or Prop to router we don't need any CSMA/CD there is no one else to collide with on a point to point link. Even when sharing the net with a hub or switch we can get away with it. Provided we are only transmitting occasionally other nodes on the net will just see collisions and recover.

As for "other layers of the full protocol", well, would be nice and is probably not going to happen. We don't need ARP if we can configure MAC addresses manually. However there are some very small IP stacks around www.sics.se/~adam/uip/index.php/Main_Page (http://www.sics.se/~adam/uip/index.php/Main_Page)

@Beau: Any suggestions for such SER/DES chips and magnetics ? I like this idea.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Beau Schwabe (Parallax)
01-16-2009, 11:36 PM
heater (http://forums.parallax.com/member.php?u=52350),

One of the first things I did when I worked at National Semiconductor was to design a Fiber-Optic Ethernet card based off of an existing Ethernet over copper design.· The SerDes that we used was an HDMP-1636A... it has a fair number of pins, but many are connected to either power or ground.· The Fiber-Optic connector used was an HFBR-53D5.



Reference:
http://www.datasheetcatalog.org/datasheet2/d/0kjuo0ocrr7jp8l3l6ayhkyod0fy.pdf
http://www.datasheetcatalog.org/datasheet2/4/081a2czpcl7aawqot831lhlw6yky.pdf

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe (mailto:bschwabe@parallax.com)

IC Layout Engineer
Parallax, Inc.

hippy
01-17-2009, 12:46 AM
heater said...
If Hippy was doing bit banged UDP I feel sure he must have thought of this already. Did he not think of it or reject the idea already for some reason I wonder ?


It worked ( sort of ) and I think it's entirely feasible if one can find an application where UDP out only is what's needed. Cannot recall if I eventually used WAITVID or just bit-banged.


heater said...
These guys www.fpga4fun.com/10BASE-T0.html (http://www.fpga4fun.com/10BASE-T0.html) seem to have luck just hooking up two pins of an FPGA as a differential signal. Odd because I though at least a transformer was required.


This is where I had to give up because the simple direct / pasisve connection did not work well and I don't have the knowledge / tools to know what is actually happening on the lines or how to design / build a proper interface with magnetics. I also wasn't prepared to risk damaging the Propeller chip.

Someone else should be able to do better than me. The theory works, an implementation works in part. That needs to be made to work well and then it's just a case of doing it better, faster, cheaper etc.

heater
01-17-2009, 12:56 AM
Great, Hippy is still around !

I'll have to go through your UDP thread.

What does jazzed mean by "encoding bit errors" is that from Hippy's output?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

jazzed
01-17-2009, 01:02 AM
The waitvid generated manchester encoding I tested from that thread was missing bits. Not sure who wrote the source.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve

Leon
01-17-2009, 01:06 AM
Here's how XMOS implemented 100 Mbit/s ethernet in software:

www.xlinkers.org/projects/ethernet_mac (http://www.xlinkers.org/projects/ethernet_mac)

It's a full MAC, but might be of interest. The code for the current version is available.

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

lonesock
01-17-2009, 01:10 AM
@Cluso99: Thanks for the elegant solution, and for not using the phrase "you idiot" [8^)

I was thinking I could also do the Manchester encoding by alternating the commands:

shr OUTA, #2
xor OUTA, #3

So you could send 16 actual data bits per HUB long (instead of only 8 as before). But I would still need the interleaved TX+ and TX- bits.

I'm also trying to think of a way to read a word from the HUB RAM, then interleave all 16 bits with their negative in PASM. The fastest unrolled way I can think to do it requires 15 instructions or so. I think that would actually work, as I have a total window of 32 instructions to read a word, interleave into a long, and do a waitcnt while the other cog is busy sending out the last 16 actual data bits.

The nice thing about this setup is that all of the encoding is performed in the 2 sending cogs in PASM, so it should be the fastest possible, _and_ you use no extra HUB RAM, just store your UDP/IP packet as-is and send it out.

Any thoughts on this scheme?

Jonathan

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.

Baggers
01-17-2009, 02:55 AM
lonesock, for getting the 16bits interleaved into 32bits, can you do a 256 word table and take each byte and get it's corresponding word?
RDWORD temp,ptr
mov temp2,temp
and temp2,#255
shl temp2,#1
add temp2,table
rdword temp2,temp2
shr temp,#7
and temp,#510
add temp,table
shl temp2,#16
rdword temp,temp
or temp,temp2

that gives you it in 12 instructions but the hubop overhead takes it to 15, and that's not increasing the pointer, nor doing anything with the data.

Baggers

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite

·

Cluso99
01-17-2009, 10:24 PM
Hippy - thought you got lost !

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Prop Tools under Development or Completed (Index)
http://forums.parallax.com/showthread.php?p=753439

My cruising website http://www.bluemagic.biz

simonl
01-17-2009, 10:51 PM
Yay, hippy - you're still with us http://forums.parallax.com/images/smilies/jumpin.gif

Someone asked about RJ45 & magnetics - Sparkfun do this: MagJack (http://www.sparkfun.com/commerce/product_info.php?products_id=8534) and breakout (http://www.sparkfun.com/commerce/product_info.php?products_id=8790)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
-------------------------------

www.norfolkhelicopterclub.com (http://www.norfolkhelicopterclub.com)

You'll always have as many take-offs as landings, the trick is to be sure you can take-off again http://forums.parallax.com/images/smilies/wink.gif
BTW: I type as I'm thinking, so please don't take any offence at my writing style http://forums.parallax.com/images/smilies/smile.gif

hippy
01-17-2009, 11:58 PM
Yes, still around, busy on other things but I've not deserted. Great to see all the activity which is still going on, great to see the forum still very lively and pushing the boundaries - though it does mean quite a haul to catch up !

lonesock
01-18-2009, 02:22 PM
Here is a test framework for my idea. If anybody has the hardware and the inclination to test this out, you are welcome to it. This seems to do what I want it to (looking at GEAR simulations), but I do not have the HW here to test it yet. Also, I am not constructing a valid UDP/IP packet...I need to "borrow" that code from Hippy's earlier work (hope you don't mind, Hippy!).

To review: requires 80MHz & 2 cogs, performs the Manchester encoding and interleaving of TX+ and TX- automatically.

Thanks to everybody helping me out...I'll have some time near the end of the coming week to do some more development and test it out (I have an actual mag/jack for use with an ENC28J60 project).

Jonathan

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.

hippy
01-18-2009, 10:20 PM
@ lonesock : Help yourself to any of my code I put on here, if there are any restrictions they'll be noted in the source, otherwise it's there for people to build on and use as they feel fit - borrow away, improve where you can. Assume anything I publish is 'fair game for any use' unless it says otherwise. I can't afford lawyers anyway http://forums.parallax.com/images/smilies/smile.gif

One thing I'd suggest when playing with magnetics ( or anything which could damage a Propeller I/O etc ) is run lines through buffers. That hopefully limits any damage to the buffer and not the Propeller.

Good luck.