I do not think a Propeller has enough oomph to bit-bang each bit in and would ideally need something like a reverse-waitvid ( cue a "what the Prop II should have" discussion ).
1) Is the source of the Manchester modulation timing always a crystal?
Almost certainly. The transmission line distorts the signals though. Being Manchester Encoded the stream is self-clocking so it should be possible to reconstitute a decent enough, constant rate, bit stream, even if that needs external hardware. It may be possible to create a 10MHz raw bit-stream rather than the 20MHz Manchester Encoded stream which would take some weight of the Propeller.
2) What is the minimal Vpp level on the RX+,RX- signals?
On an ideally balanced line it should be +/-2.5V differential.
3) What is the maximal size of a packet for tcp/ip?
1526 packet bytes / 24416 Manchester Encoded Bits. There are also potentially 'jumbo packets' ( 9K ? bytes ) but I do not think they are likely to be encountered on most networks.
4) How long is the minimal time between 2 packets?
9600nS. That gives enough ( over 32-bits ) for a Cog to determine nothing is being sent to detect the end of packet.
1) My idea was to take an incoming bitstream like a asynchrone one. Synchronisation is done only one time at the end of the preamble. If the sender and the receiver are crystal based, they stay in phase for a short time (with 50ppm crystals for some 100 bittimes, theoretically). The attached picture shows what I mean.
2) This is very good.
3) OK this is a little to long for my approach. But if I only communicate with my one application on the PC, I can define the Packetsize much shorter.
4) It's long enough to detect the end, but not to copy the whole packet in the HubRam! But again my one Application can decide how long to wait until the next packet will be sent.
So it seems not possible to make a full featured Ethernet 2-way communication only with software. But for my application I need to send only some parameters to the propeller, and perhaps this is possible.
I think the largest "normal" packet is 1544 bytes if memory servers (let's ignore jumbo frames); thats 12352 bits.
If you sample once per frame, the maximum drift you could handle would be a bit less than half of a bit, so roughly 1/25000, or .004%, which is roughly 40 parts per million; this means that both the propeller's and the sender's crystals would have to be 20ppm or better in accuracy, and not be subject to different temperature drift.
Ofcourse the situation is MUCH better with shorter frames.
Personally, I picked up a few of the Microchip ENC28J60's
Ofcourse, I fully expect that Chip will put in Manchester encoding/decoding and high speed serial input/output modes into the next propeller (or I am hoping anyway!) so that it will be easy to do Ethernet, USB etc just with a prop v2
Actually, for a v2 prop, if it has manchester encoding/decoding and high speed serial I/O (simple mod to timer regs) 100mbps Ethernet ought to be quite doable [noparse]:)[/noparse] [noparse]:)[/noparse] [noparse]:)[/noparse] and high speed 480mbps USB 2.0 may also be feasible.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ www.mikronauts.com - a new blog about microcontrollers
Generating a 10MHz Manchester-encoded serial data stream.
__________________________________________________
Method 1: Here's a test program I wrote to try the chroma clock idea for generating the Manchester coding. It works, but it requires pushing the PLL output frequency to 160MHz, since the chroma clock is the PLL clock divided by 16. Also not all combinations of 180-degree phase changes yielded glitch-free Manchester coding, for some reason. The two that I ended up using (%0001 and %1001), however, are glitch-free on my system. I programmed the video level so I'd get complementary outputs on pins A1 and A2.
Here's the code. Note that no data conditioning and no external circuitry is required, since the Propeller hardware does the Manchester encoding. The waitvid period is 3.2µS, or 64 instructions, so there should be plenty of time in between to fetch data.
[b]CON[/b]
[b]_clkmode[/b] = [b]xtal[/b]1 + [b]pll[/b]16x
[b]_xinfreq[/b] = 5_000_000
pin_group = 0
[b]PUB[/b] start
[b]cognew[/b](@manchester, 0)
[b]DAT[/b]
manchester [b]mov[/b] [b]ctra[/b],_ctra 'Set up counter and video.
[b]mov[/b] [b]frqa[/b],_frqa
[b]mov[/b] [b]vcfg[/b],_vcfg
[b]mov[/b] [b]vscl[/b],_vscl
[b]mov[/b] [b]dira[/b],#$0f
:loop [b]waitvid[/b] colors,data 'Send test data.
[b]or[/b] [b]outa[/b],#8 'Sync for oscilloscope.
[b]andn[/b] [b]outa[/b],#8
[b]jmp[/b] #:loop
_frqa [b]long[/b] 1<<29 'Base frequency is 10MHz.
_ctra [b]long[/b] 1<<26|7<<23 'Video mode: PLL = base * 16 = 160MHz.
_vcfg [b]long[/b] %0_10_0_01_000_00000000000_000_0_00000110 'Output video on bits A2..A1.
_vscl [b]long[/b] 16<<12|512 '16 clocks/pixel; 512 clocks/long
colors [b]long[/b] %0001_1011__1001_1011 'Add +/-1 to 011 = 100 & 010
data [b]long[/b] $a5a5a5a5 'Test data
Attached is an annotated scope trace of what this code produced. The data comes out LSB first, so the trace is backwards from the definition of data.
__________________________________________________
Method 2: While I was experimenting, I discovered that video can also be produced in mode 2 of the counter — not just mode 1. If the chroma clock method turns out to be too close to the ragged edge, this is very handy, since the PLL clock feeding the video section can be output on a pin. This means that the PLL clock only has to be 10MHz, and that the data (and its complement) can be output on two pins NRZ-style, without involving the chroma clock. Their transistions will always be in phase with the PLL clock, so that clock can be XORed with the NRZ data to get the Manchester encoding — again without any data conditioning required. (I didn't have a chance to test this with an actual pair of XOR gates, since I only had a 4070, and it's too slow. But I was able to observe the correct waveforms on the scope.)
__________________________________________________
-Phil
Post Edited (Phil Pilgrim (PhiPi)) : 10/14/2007 6:43:46 AM GMT
Propeller + small cpld = 10mbit ethernet [noparse]:)[/noparse]
Looks like the prop can generate the bit stream (ok, xor gate needed), and a small cpld should be enough - with say an 80mhz clock - to do clock recovery and convert the serial ethernet data stream to say eight bit bytes; which would certainly slow it down enough for a prop to handle it.
Say an XC9536 or an EPM7032... someone with a Hydra and sram card could try it...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ www.mikronauts.com - a new blog about microcontrollers
There is still my idea of straightforwardly outputting 4 times 8 VGA bits by WAITVID, latched by a PISO which is clocked by Timer-B at upto 160 MHz.
160 MHz means load cycle 20 MHz, means WAITVID = 200 ns = 4 Instructions/LONG
At 160MHz, there are 16 clocks per pixel, though (one entire cycle of the chroma clock), so you have 64 instructions per long, not four.
There is a fly in the ointment, however. The four-bit chroma counter is inaccessible from the program, and I'm not sure there's any way to guarantee what state it starts in. (It's a different counter from the one that counts the clocks per pixel). If the starting state is "wrong", the polarity of the output will be inverted. I've never seen this happen, but there's nothing in the Propeller specs that says it couldn't. In any event, the external XOR gate is a reasonable fall-back position and has the same program-time parameters without needing a 160MHz PLL clock.
In any event, I think it's important for the Manchester encoding to be done by hardware, whether by the chroma clock or by external logic. Doing it in software is much too time-consuming, because the bits have to be treated individually.
Hello Phil
I like both of your methods. The first with the chroma-modulation a little bit more (no extra hardware, not 3 pins). I think the PLL can not have a problem with 160MHz because also the Hydra and the SpinStamp works with a VCO frequency of 160MHz that is divided then to 80 MHz by the PLL divider.
But don't forget, we have also to do a CRC32 checksum calculation over (nearly) the whole bitstream. If we calculate this bitwise, then it's no big task to do also the Manchester encoding in the same routine. If it is done bytewise with a big table (256 longs) then an additional Manchester encoding table (256 words) takes not much more memory.
Generating the bitstream needs anyway a lot of time, the Manchester encoding is not the most time consuming part. And you can use any 2 pins of the selected output-group for the TX+/- outputs with the Soft-Manchester methode...
Version 002 attached. A few changes and bug fixes. - See later post for latest version of code
With my software Manchester encoding I've used the minimal 2x68R connections direct into two hubs ( NetGear and 3com ) and via cross-over cable to a laptop NIC running packet sniffer software. In all cases the link Led comes on, and the Rx Led flashes when a packet is sent. Collision Led no longer coming on, 3com hub notes Network Utilisation on it's bargraph ( <= 1% unsurprisingly ). Altering the NLP and other timing, forcing extra / dropping bits and Rx Led goes out and/or Collision Led comes on so I think I've got the timing / clocking rate right.
Unfortunately the packet sniffer isn't showing any packets. It's in promiscuous mode so should show everything. So either the waveform is too mangled or there's an error in checksumming / encoding and the NIC is rejecting the packet. I'll have to work on the best way to move forward.
@ Phil : I won't pretend to understand exactly how your hardware encoding works but it's a great method. I'd like to make it work with A0/A1 pins, so looks like I have some reading up to do. It gets rid of the intermediate bit buffer needed to hold the Manchester encoded bit stream entirely and would greatly improve throughput, plus gives twice as long between waitvids to process the rdlong buffer data in the Cog.
@ Ariba : The CRC is calculated only from the byte packet / raw bit stream ( not the pairs of Manchester encoded bits ). It can be pre-calculated before streaming starts or could be done on the fly if there is enough processing time. I'm sure it can be calculated a long at a time for speed.
Since the CRC can be computed ahead of time, I don't include it in the overhead required to send a packet at the physical level. Although one could also compute the Manchester encoding ahead of time as well, doing so would double the size of the packet; so I think it's better to save that task for the transmitter.
As it turns out, a 160MHz clock is not necessary to do the Manchester encoding with the chroma generator. An 80MHz clock will do. The idea is to adjust the chroma phase so that a transition takes place at the middle of each bit (pixel). Then you invert every other bit in the data, which can be done in one instruction, before handing it off to WAITVID. Gettng the chroma clock lined up properly is also not so difficult, it turns out. All it requires is a short routine at powerup to adjust the "colors" based on sample output the program can monitor.
I'm not well versed in Ethernet matters, though. Is there some kind of collision detection that has to take place during transmission? What are the implications for doing this in the Propeller?
Unfortunately, the chroma clock method will only work with A1/A2, A5/A6, A9/A10, etc. This is because the chroma clock does not affect the low-order bit of the composite video encoding (i.e. it either adds 1 or subtracts 1).
@ Phil : Thanks. That "Adds one" makes sense now of what you have in your color field ( and explains something I wasn't entirely clear about in the video drivers as well ). I'll modify my code so it can select between software and hardware Manchester encoding depending upon pin-pairs chosen.
Ethernet packet collision would be a problem if such a device were simply plugged into a network via a hub. For UDP send-only, that packet would be discarded/lost and the sender would never know. Other UDP on the network could also be lost but TCP/IP should handle loss of data by requesting re-transmission ( AFIAK ). Could thrash the network but perhaps not too bad if collisions are rare.
Blind UDP sending is best suited to a one-to-one, Propeller to PC NIC, setup, although it could be 'multi-drop' to that NIC using a hub for multiple UDP clients if collisions and loss of data could be tolerated. Ideally a switch ( hardware or software ) should be used rather than a hub so each incoming UDP packet is queued up and put on the main network one at a time.
As a mid-way solution it would be possible to choose a hub which detects collisions and pass that signal ( a tap from the Led driver perhaps ) back down a spare Cat5 wire so all senders gets told it didn't work, send again. Not quite Ethernet standard, but if it sent a collision detect as a Normal Link Pulse back out via magnetics it would be electrically compliant for any Ethernet device.
Phil, where are you getting the information on the "four-bit chroma counter"? I've never seen anything written about it, so clearly I've missed something.
And tell us more about the short routine at power-up to sync up the chroma clock, please!
As deSilva says: a little here, a little there, some experimentation, and a big dose of inference. My most-consulted reference has been a preprint from Andr
Coughing and spluttering but at least I can get ethernet packets from the Propeller through a hub and into a PC running a packet sniffer. The hub Rx Led seems to go into meltdown and it also drifts in and out of collision detected. I need to alter the source to change software Manchester encoding from 0->10/1->01 to 0->01/1->10 every so often to kick it back into shape ( can receiver magnetics get 'polarised' ? ). Not all get through and once it 'loses synch' the packet sniffer reports garbaged packets which have however got through the NIC CRC checking.
In truth, I've no idea what's going on but I put it down to a direct to hub wiring scheme with no magnetics and reasonably high value resistors because I have no intention of losing my Propeller chip if I can help it. What the hub sees is probably far from an ideal signal.
I'm no electronics engineer so I have no idea how to connect the I/O up to magnetics. I've perhaps taken it as far as I can, so if anyone wants to take what I have and build on it they are welcome.
I've discovered a potential issue with the hardware Manchester encoding using chroma shifting; it's perhaps not possible to put an idle state out ( lows on both lines ) and likewise not possible to generate a single 100nS NLP ( only a Manchester encoded pulse ) unless Chroma can be turned on and off on the fly, or suitable colour values which don't get Chroma shifted can be found. Again, this is something beyond my current knowledge.
At least to the question, "Can the Propeller big-bang out ethernet ?", we have an answer; "yes". Getting it to work reliably and accurately is what remains to be done. Latest code attached -
Here's the code for using an 80MHz counter clock. The resulting chroma clock is 5MHz, with edges placed midway through each bit cell. This code does not include the "short routine" alluded to earlier for adjusting the chroma phase. It works consistently on my system, but may not on others whose chroma counter powers up in a different state from mine.
[b]CON[/b]
[b]_clkmode[/b] = [b]xtal[/b]1 + [b]pll[/b]16x
[b]_xinfreq[/b] = 5_000_000
pin_group = 0
[b]PUB[/b] start
[b]cognew[/b](@manchester, 0)
[b]DAT[/b]
manchester [b]mov[/b] [b]ctra[/b],_ctra 'Set up counter and video.
[b]mov[/b] [b]frqa[/b],_frqa
[b]mov[/b] [b]vcfg[/b],_vcfg
[b]mov[/b] [b]vscl[/b],_vscl
[b]mov[/b] [b]dira[/b],#$0f
:loop [b]mov[/b] acc,data 'Get data into scratch register.
[b]xor[/b] acc,mask 'Flip every other bit.
[b]waitvid[/b] colors,acc 'Send data.
[b]or[/b] [b]outa[/b],#8 'Sync for oscilloscope.
[b]andn[/b] [b]outa[/b],#8
[b]jmp[/b] #:loop
_frqa [b]long[/b] 1<<28 'Base frequency is 5MHz.
_ctra [b]long[/b] 1<<26|7<<23 'Video mode: PLL = base * 16 = 80MHz.
_vcfg [b]long[/b] %0_10_0_01_000_00000000000_000_0_00000110 'Output video on bits A2..A1.
_vscl [b]long[/b] 8<<12|256 '8 clocks/pixel; 256 clocks/long
colors [b]long[/b] %1101_1011__0101_1011 'Add +/-1 to 011 = 100 & 010
data [b]long[/b] $a5a5a5a5 'Test data
mask [b]long[/b] $55555555 'Mask to invert every other data bit.
acc [b]res[/b] 1 'Scratch register.
To generate an idle state or the NLP pulse, the Manchester video circuitry can simply be turned off and the outputs set with software.
-Phil
Post Edited (Phil Pilgrim (PhiPi)) : 10/15/2007 6:56:48 PM GMT
I was thinking about a way to detect a missing or double pulse. After some experiments, I found that a "DJNZ PHSA, #$" (with counter set at instruction rate, step > 1, and some phase preset) seems capable of such a thing.
Then I recalled about this thread, and wanted to try to detect the start frame delimiter.
So here it is, a proof of concept of COG to COG transmit + receive (via pins).
- Untested on real hardware, if you want to try it, use GEAR (version 9.10.27.7), serial at 30/31, 230400bps.
- Not sure it's reliable for any frame alignment, needs more testing, and more and better trickery.
- Checksum is fake/ignored. inter-packet gap is large to give GEAR time to print the received packet.
- Didn't use Phil's method to tranmit, because I don't know if GEAR emulates the chroma counter at all (?).
The old posts often have good tricks, and when you add to these tricks with new stuff there is good to come out of it, so I would not worry about a necropost, as it can be a very good thing.
The Propeller 1 still has a lot of life left in it, I would not be surprised to see it produced for another 20 years, even with the Propeller 2 only a few years off.
The Propeller 1 still has a lot of life left in it, I would not be surprised to see it produced for another 20 years, even with the Propeller 2 only a few years off.
Now this is bumped, and the P2 opcodes are stable, I wonder how Bit-Banged Ethernet would port to P2 ?
The Propeller 1 still has a lot of life left in it, I would not be surprised to see it produced for another 20 years, even with the Propeller 2 only a few years off.
Now this is bumped, and the P2 opcodes are stable, I wonder how Bit-Banged Ethernet would port to P2 ?
I hope in that case smartpins would help with triggering.
The optimal solution (for the general problem, not for ethernet) would be waiting for a known serial sync word at every bit shifted in: Open Bench Logic Sniffer has this feature (32bits?) in the trigger modes, also Amiga floppy controller had a 16bit sync word.
I meant to suggest this, but then I didn't want to distract Chip from his own schedule.
Truth is I would have tried DP83848 PHY module from WaveShare on P1 insted, if the friggin' thing didn't have MII D2/D3 unrouted to the header despite lots of NC pins there. How dumb is that? Only RMII is available and that's too fast for P1.
But RMII should be ok on P2, and a better solution, you get 10/100.
1. I got preamble and SFD bytes reversed... just seemed to good to get the whole 48-bits of destination HW address.
In fact, with the correct ordering we are going to lose at least one byte of it before we're able to setup the sample loop.
2. Chroma method seems to work in GEAR (using %1100_1011__0100_1011 palette)... no analog drift though, too much consistency! .
So the manchester encoding table can be replaced by CRC32 table.
3. Using 256 longs table for CRC takes some 40+ clocks per byte, not bad!
So if we shorten the video frame to bytes (64 clocks to shift one), we MIGHT be able to compute CRC on the fly.
Comments
I do not think a Propeller has enough oomph to bit-bang each bit in and would ideally need something like a reverse-waitvid ( cue a "what the Prop II should have" discussion ).
1) Is the source of the Manchester modulation timing always a crystal?
Almost certainly. The transmission line distorts the signals though. Being Manchester Encoded the stream is self-clocking so it should be possible to reconstitute a decent enough, constant rate, bit stream, even if that needs external hardware. It may be possible to create a 10MHz raw bit-stream rather than the 20MHz Manchester Encoded stream which would take some weight of the Propeller.
2) What is the minimal Vpp level on the RX+,RX- signals?
On an ideally balanced line it should be +/-2.5V differential.
3) What is the maximal size of a packet for tcp/ip?
1526 packet bytes / 24416 Manchester Encoded Bits. There are also potentially 'jumbo packets' ( 9K ? bytes ) but I do not think they are likely to be encountered on most networks.
4) How long is the minimal time between 2 packets?
9600nS. That gives enough ( over 32-bits ) for a Cog to determine nothing is being sent to detect the end of packet.
@ Harrison : Thanks for that link.
Thank you for the PDFs
@hippy
Thank you for your respond.
1) My idea was to take an incoming bitstream like a asynchrone one. Synchronisation is done only one time at the end of the preamble. If the sender and the receiver are crystal based, they stay in phase for a short time (with 50ppm crystals for some 100 bittimes, theoretically). The attached picture shows what I mean.
2) This is very good.
3) OK this is a little to long for my approach. But if I only communicate with my one application on the PC, I can define the Packetsize much shorter.
4) It's long enough to detect the end, but not to copy the whole packet in the HubRam! But again my one Application can decide how long to wait until the next packet will be sent.
So it seems not possible to make a full featured Ethernet 2-way communication only with software. But for my application I need to send only some parameters to the propeller, and perhaps this is possible.
Andy
I think the largest "normal" packet is 1544 bytes if memory servers (let's ignore jumbo frames); thats 12352 bits.
If you sample once per frame, the maximum drift you could handle would be a bit less than half of a bit, so roughly 1/25000, or .004%, which is roughly 40 parts per million; this means that both the propeller's and the sender's crystals would have to be 20ppm or better in accuracy, and not be subject to different temperature drift.
Ofcourse the situation is MUCH better with shorter frames.
Personally, I picked up a few of the Microchip ENC28J60's
Ofcourse, I fully expect that Chip will put in Manchester encoding/decoding and high speed serial input/output modes into the next propeller (or I am hoping anyway!) so that it will be easy to do Ethernet, USB etc just with a prop v2
Actually, for a v2 prop, if it has manchester encoding/decoding and high speed serial I/O (simple mod to timer regs) 100mbps Ethernet ought to be quite doable [noparse]:)[/noparse] [noparse]:)[/noparse] [noparse]:)[/noparse] and high speed 480mbps USB 2.0 may also be feasible.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com - a new blog about microcontrollers
__________________________________________________
Method 1: Here's a test program I wrote to try the chroma clock idea for generating the Manchester coding. It works, but it requires pushing the PLL output frequency to 160MHz, since the chroma clock is the PLL clock divided by 16. Also not all combinations of 180-degree phase changes yielded glitch-free Manchester coding, for some reason. The two that I ended up using (%0001 and %1001), however, are glitch-free on my system. I programmed the video level so I'd get complementary outputs on pins A1 and A2.
Here's the code. Note that no data conditioning and no external circuitry is required, since the Propeller hardware does the Manchester encoding. The waitvid period is 3.2µS, or 64 instructions, so there should be plenty of time in between to fetch data.
[b]CON[/b] [b]_clkmode[/b] = [b]xtal[/b]1 + [b]pll[/b]16x [b]_xinfreq[/b] = 5_000_000 pin_group = 0 [b]PUB[/b] start [b]cognew[/b](@manchester, 0) [b]DAT[/b] manchester [b]mov[/b] [b]ctra[/b],_ctra 'Set up counter and video. [b]mov[/b] [b]frqa[/b],_frqa [b]mov[/b] [b]vcfg[/b],_vcfg [b]mov[/b] [b]vscl[/b],_vscl [b]mov[/b] [b]dira[/b],#$0f :loop [b]waitvid[/b] colors,data 'Send test data. [b]or[/b] [b]outa[/b],#8 'Sync for oscilloscope. [b]andn[/b] [b]outa[/b],#8 [b]jmp[/b] #:loop _frqa [b]long[/b] 1<<29 'Base frequency is 10MHz. _ctra [b]long[/b] 1<<26|7<<23 'Video mode: PLL = base * 16 = 160MHz. _vcfg [b]long[/b] %0_10_0_01_000_00000000000_000_0_00000110 'Output video on bits A2..A1. _vscl [b]long[/b] 16<<12|512 '16 clocks/pixel; 512 clocks/long colors [b]long[/b] %0001_1011__1001_1011 'Add +/-1 to 011 = 100 & 010 data [b]long[/b] $a5a5a5a5 'Test dataAttached is an annotated scope trace of what this code produced. The data comes out LSB first, so the trace is backwards from the definition of data.
__________________________________________________
Method 2: While I was experimenting, I discovered that video can also be produced in mode 2 of the counter — not just mode 1. If the chroma clock method turns out to be too close to the ragged edge, this is very handy, since the PLL clock feeding the video section can be output on a pin. This means that the PLL clock only has to be 10MHz, and that the data (and its complement) can be output on two pins NRZ-style, without involving the chroma clock. Their transistions will always be in phase with the PLL clock, so that clock can be XORed with the NRZ data to get the Manchester encoding — again without any data conditioning required. (I didn't have a chance to test this with an actual pair of XOR gates, since I only had a 4070, and it's too slow. But I was able to observe the correct waveforms on the scope.)
__________________________________________________
-Phil
Post Edited (Phil Pilgrim (PhiPi)) : 10/14/2007 6:43:46 AM GMT
Hmm...
Hypothesis:
Propeller + small cpld = 10mbit ethernet [noparse]:)[/noparse]
Looks like the prop can generate the bit stream (ok, xor gate needed), and a small cpld should be enough - with say an 80mhz clock - to do clock recovery and convert the serial ethernet data stream to say eight bit bytes; which would certainly slow it down enough for a prop to handle it.
Say an XC9536 or an EPM7032... someone with a Hydra and sram card could try it...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com - a new blog about microcontrollers
160 MHz means load cycle 20 MHz, means WAITVID = 200 ns = 4 Instructions/LONG
There is a fly in the ointment, however. The four-bit chroma counter is inaccessible from the program, and I'm not sure there's any way to guarantee what state it starts in. (It's a different counter from the one that counts the clocks per pixel). If the starting state is "wrong", the polarity of the output will be inverted. I've never seen this happen, but there's nothing in the Propeller specs that says it couldn't. In any event, the external XOR gate is a reasonable fall-back position and has the same program-time parameters without needing a 160MHz PLL clock.
In any event, I think it's important for the Manchester encoding to be done by hardware, whether by the chroma clock or by external logic. Doing it in software is much too time-consuming, because the bits have to be treated individually.
-Phil
I like both of your methods. The first with the chroma-modulation a little bit more (no extra hardware, not 3 pins). I think the PLL can not have a problem with 160MHz because also the Hydra and the SpinStamp works with a VCO frequency of 160MHz that is divided then to 80 MHz by the PLL divider.
But don't forget, we have also to do a CRC32 checksum calculation over (nearly) the whole bitstream. If we calculate this bitwise, then it's no big task to do also the Manchester encoding in the same routine. If it is done bytewise with a big table (256 longs) then an additional Manchester encoding table (256 words) takes not much more memory.
Generating the bitstream needs anyway a lot of time, the Manchester encoding is not the most time consuming part. And you can use any 2 pins of the selected output-group for the TX+/- outputs with the Soft-Manchester methode...
Andy
With my software Manchester encoding I've used the minimal 2x68R connections direct into two hubs ( NetGear and 3com ) and via cross-over cable to a laptop NIC running packet sniffer software. In all cases the link Led comes on, and the Rx Led flashes when a packet is sent. Collision Led no longer coming on, 3com hub notes Network Utilisation on it's bargraph ( <= 1% unsurprisingly ). Altering the NLP and other timing, forcing extra / dropping bits and Rx Led goes out and/or Collision Led comes on so I think I've got the timing / clocking rate right.
Unfortunately the packet sniffer isn't showing any packets. It's in promiscuous mode so should show everything. So either the waveform is too mangled or there's an error in checksumming / encoding and the NIC is rejecting the packet. I'll have to work on the best way to move forward.
@ Phil : I won't pretend to understand exactly how your hardware encoding works but it's a great method. I'd like to make it work with A0/A1 pins, so looks like I have some reading up to do. It gets rid of the intermediate bit buffer needed to hold the Manchester encoded bit stream entirely and would greatly improve throughput, plus gives twice as long between waitvids to process the rdlong buffer data in the Cog.
@ Ariba : The CRC is calculated only from the byte packet / raw bit stream ( not the pairs of Manchester encoded bits ). It can be pre-calculated before streaming starts or could be done on the fly if there is enough processing time. I'm sure it can be calculated a long at a time for speed.
Post Edited (hippy) : 10/15/2007 5:00:28 PM GMT
As it turns out, a 160MHz clock is not necessary to do the Manchester encoding with the chroma generator. An 80MHz clock will do. The idea is to adjust the chroma phase so that a transition takes place at the middle of each bit (pixel). Then you invert every other bit in the data, which can be done in one instruction, before handing it off to WAITVID. Gettng the chroma clock lined up properly is also not so difficult, it turns out. All it requires is a short routine at powerup to adjust the "colors" based on sample output the program can monitor.
I'm not well versed in Ethernet matters, though. Is there some kind of collision detection that has to take place during transmission? What are the implications for doing this in the Propeller?
-Phil
Unfortunately, the chroma clock method will only work with A1/A2, A5/A6, A9/A10, etc. This is because the chroma clock does not affect the low-order bit of the composite video encoding (i.e. it either adds 1 or subtracts 1).
-Phil
Ethernet packet collision would be a problem if such a device were simply plugged into a network via a hub. For UDP send-only, that packet would be discarded/lost and the sender would never know. Other UDP on the network could also be lost but TCP/IP should handle loss of data by requesting re-transmission ( AFIAK ). Could thrash the network but perhaps not too bad if collisions are rare.
Blind UDP sending is best suited to a one-to-one, Propeller to PC NIC, setup, although it could be 'multi-drop' to that NIC using a hub for multiple UDP clients if collisions and loss of data could be tolerated. Ideally a switch ( hardware or software ) should be used rather than a hub so each incoming UDP packet is queued up and put on the main network one at a time.
As a mid-way solution it would be possible to choose a hub which detects collisions and pass that signal ( a tap from the Led driver perhaps ) back down a spare Cat5 wire so all senders gets told it didn't work, send again. Not quite Ethernet standard, but if it sent a collision detect as a Normal Link Pulse back out via magnetics it would be electrically compliant for any Ethernet device.
And tell us more about the short routine at power-up to sync up the chroma clock, please!
As deSilva says: a little here, a little there, some experimentation, and a big dose of inference. My most-consulted reference has been a preprint from Andr
Coughing and spluttering but at least I can get ethernet packets from the Propeller through a hub and into a PC running a packet sniffer. The hub Rx Led seems to go into meltdown and it also drifts in and out of collision detected. I need to alter the source to change software Manchester encoding from 0->10/1->01 to 0->01/1->10 every so often to kick it back into shape ( can receiver magnetics get 'polarised' ? ). Not all get through and once it 'loses synch' the packet sniffer reports garbaged packets which have however got through the NIC CRC checking.
In truth, I've no idea what's going on but I put it down to a direct to hub wiring scheme with no magnetics and reasonably high value resistors because I have no intention of losing my Propeller chip if I can help it. What the hub sees is probably far from an ideal signal.
I'm no electronics engineer so I have no idea how to connect the I/O up to magnetics. I've perhaps taken it as far as I can, so if anyone wants to take what I have and build on it they are welcome.
I've discovered a potential issue with the hardware Manchester encoding using chroma shifting; it's perhaps not possible to put an idle state out ( lows on both lines ) and likewise not possible to generate a single 100nS NLP ( only a Manchester encoded pulse ) unless Chroma can be turned on and off on the fly, or suitable colour values which don't get Chroma shifted can be found. Again, this is something beyond my current knowledge.
At least to the question, "Can the Propeller big-bang out ethernet ?", we have an answer; "yes". Getting it to work reliably and accurately is what remains to be done. Latest code attached -
[b]CON[/b] [b]_clkmode[/b] = [b]xtal[/b]1 + [b]pll[/b]16x [b]_xinfreq[/b] = 5_000_000 pin_group = 0 [b]PUB[/b] start [b]cognew[/b](@manchester, 0) [b]DAT[/b] manchester [b]mov[/b] [b]ctra[/b],_ctra 'Set up counter and video. [b]mov[/b] [b]frqa[/b],_frqa [b]mov[/b] [b]vcfg[/b],_vcfg [b]mov[/b] [b]vscl[/b],_vscl [b]mov[/b] [b]dira[/b],#$0f :loop [b]mov[/b] acc,data 'Get data into scratch register. [b]xor[/b] acc,mask 'Flip every other bit. [b]waitvid[/b] colors,acc 'Send data. [b]or[/b] [b]outa[/b],#8 'Sync for oscilloscope. [b]andn[/b] [b]outa[/b],#8 [b]jmp[/b] #:loop _frqa [b]long[/b] 1<<28 'Base frequency is 5MHz. _ctra [b]long[/b] 1<<26|7<<23 'Video mode: PLL = base * 16 = 80MHz. _vcfg [b]long[/b] %0_10_0_01_000_00000000000_000_0_00000110 'Output video on bits A2..A1. _vscl [b]long[/b] 8<<12|256 '8 clocks/pixel; 256 clocks/long colors [b]long[/b] %1101_1011__0101_1011 'Add +/-1 to 011 = 100 & 010 data [b]long[/b] $a5a5a5a5 'Test data mask [b]long[/b] $55555555 'Mask to invert every other data bit. acc [b]res[/b] 1 'Scratch register.To generate an idle state or the NLP pulse, the Manchester video circuitry can simply be turned off and the outputs set with software.
-Phil
Post Edited (Phil Pilgrim (PhiPi)) : 10/15/2007 6:56:48 PM GMT
I was thinking about a way to detect a missing or double pulse. After some experiments, I found that a "DJNZ PHSA, #$" (with counter set at instruction rate, step > 1, and some phase preset) seems capable of such a thing.
Then I recalled about this thread, and wanted to try to detect the start frame delimiter.
So here it is, a proof of concept of COG to COG transmit + receive (via pins).
- Untested on real hardware, if you want to try it, use GEAR (version 9.10.27.7), serial at 30/31, 230400bps.
- Not sure it's reliable for any frame alignment, needs more testing, and more and better trickery.
- Checksum is fake/ignored. inter-packet gap is large to give GEAR time to print the received packet.
- Didn't use Phil's method to tranmit, because I don't know if GEAR emulates the chroma counter at all (?).
The Propeller 1 still has a lot of life left in it, I would not be surprised to see it produced for another 20 years, even with the Propeller 2 only a few years off.
Now this is bumped, and the P2 opcodes are stable, I wonder how Bit-Banged Ethernet would port to P2 ?
I hope in that case smartpins would help with triggering.
The optimal solution (for the general problem, not for ethernet) would be waiting for a known serial sync word at every bit shifted in: Open Bench Logic Sniffer has this feature (32bits?) in the trigger modes, also Amiga floppy controller had a 16bit sync word.
I meant to suggest this, but then I didn't want to distract Chip from his own schedule.
Truth is I would have tried DP83848 PHY module from WaveShare on P1 insted, if the friggin' thing didn't have MII D2/D3 unrouted to the header despite lots of NC pins there. How dumb is that? Only RMII is available and that's too fast for P1.
But RMII should be ok on P2, and a better solution, you get 10/100.
In fact, with the correct ordering we are going to lose at least one byte of it before we're able to setup the sample loop.
2. Chroma method seems to work in GEAR (using %1100_1011__0100_1011 palette)... no analog drift though, too much consistency!
So the manchester encoding table can be replaced by CRC32 table.
3. Using 256 longs table for CRC takes some 40+ clocks per byte, not bad!
So if we shorten the video frame to bytes (64 clocks to shift one), we MIGHT be able to compute CRC on the fly.