Ethernet UDP from Video shifters ?
heater
Posts: 3,370
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.
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.
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
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.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
-Phil
Why is that ? Please elaborate, excuse my ignorance on this.
These guys 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.
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
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
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.
"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
IC Layout Engineer
Parallax, Inc.
Post Edited (Beau Schwabe (Parallax)) : 1/15/2009 6:13:12 PM GMT
Microchip ref: Schematic with transformer on page 6 + 9. ( and maybe others)
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......... )
Board schematic and UDP examples included.
www.mikroe.com/en/tools/serialeth/
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Aka: CosmicBob
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
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
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
IC Layout Engineer
Parallax, Inc.
Post Edited (Beau Schwabe (Parallax)) : 1/16/2009 6:32:30 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Prop Tools under Development or Completed (Index)
http://forums.parallax.com/showthread.php?p=753439
My cruising website http://www.bluemagic.biz
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
@Beau: Any suggestions for such SER/DES chips and magnetics ? I like this idea.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
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
IC Layout Engineer
Parallax, Inc.
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.
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.
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.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
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
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.
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
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Prop Tools under Development or Completed (Index)
http://forums.parallax.com/showthread.php?p=753439
My cruising website http://www.bluemagic.biz
Someone asked about RJ45 & magnetics - Sparkfun do this: MagJack and breakout
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.com
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again
BTW: I type as I'm thinking, so please don't take any offence at my writing style
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.
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.