Ethernet Booster Pack

[SugarAddict 227]

(zif not required, I've got a boatload of sockets laying around, just hate pulling chips out of sockets lol)

[RobG 1,892]

I can make the holes bigger, but there is not enough space to accommodate ZIF.

I will remove TSSOP once I get the files back from Joachim and off to Seeed

 

@bluehash,

thanks for the offer but given your Seeed orders track record, I will ship it to my address.

Ha, ha, just kidding, I will PM you.

[zeke 693]

I think you should dump the DIP and go TSSOP.

 

But when you're done, you should make this with it.

[cubeberg 540]

Or this

[RobG 1,892]

One thing at a time

 

First version, booster pack with DIP (though I am with you zeke on TSSOP.)

Second version, standalone, smaller, TSSOP, and some snazzy little features (TBD.)

[SugarAddict 227]

Second version, standalone, smaller, TSSOP, and some snazzy little features (TBD.)

 

Builtin LCD.

[RobG 1,892]

Yes, LCD header is a must.

 

It will look something like this (1" x 2")

 

[cubeberg 540]

Stacking headers and a HD44780 Booster might be a more universal idea. I know I've got plenty of character LCD's sitting around. Just make sure the two are stackable - or compatible with SA's LCD booster.

 

**Edit**

 

Maybe I should revise that. A snazzy enclosure and LCD could also be a big boost for the 43oh store

[RobG 1,892]

It's final! Ready for Seeed.

 

Joachim, thanks a lot for your help!

[RobG 1,892]

Since the hardware part is done, now it's time to write a sample server.

 

What I am working on is a server that will take simple commands and return XML response (an AJAX enabled page can send those commands as a GET request and parse XML response.)

 

Here's are few examples of how the command will look like:

 

http://192.168.253.43/s?t=p&n=1&v=3  // set port 1 to 3 ( P1OUT = 0x03)

http://192.168.253.43/s?t=p&n=1&f=r&v=1  // set resistor enable on port 1 to 3 ( P1REN = 0x03)

http://192.168.253.43/g?t=p&n=1 // get port 1  (P1IN)

http://192.168.253.43/a // get ADCMEM

 

The responses will look like this (draft xsd is attached below):

// status OK after some command like set port 1...

<?xml version="1.0" encoding="UTF-8"?>

0

// get ADCMEM

<?xml version="1.0" encoding="UTF-8"?>

1023

// get ADC channel 1 & 2

<?xml version="1.0" encoding="UTF-8"?>

1023
1023
1023

// get port information, depends on what was requested

<?xml version="1.0" encoding="UTF-8"?>



7f
00


01

// get pin information, depends on what was requested

<?xml version="1.0" encoding="UTF-8"?>


1
0
true
false

false

 

msp430xml.zip

[xpg 127]

Since the hardware part is done, now it's time to write a sample server.

 

What I am working on is a server that will take simple commands and return XML response (an AJAX enabled page can send those commands as a GET request and parse XML response.)

 

Looks good. Have you consideret using JSON instead of XML? It's quite easily parsed by any web browser, and is a less verbose than XML. As JSON block ends don't depend on their start (compared to XMLs ), I believe that it would be easier to generate the responses.

[4jochen 12]

I like to add some information regarding the PCB design.

On the PHY (inside W5200) the connection to the transformer (inside the RJ45 'MagJack') some critical signals exist and some features of the PHY makes life more easy.

 

Most important is to have the signals the same length inside the RX signal pair and the TX signal pair, and hold this signals as close together as possible. You can see very good in RobG's new picture compared to the older one.

 

Some advice:

a) There is no polarity on the 100mbps PHY signals - means you can turn around the TX+ and TX- signals and also you can exchange the RX+ and RX- with each other. ! dont mix TX.. and RX.. !

Yes, the 10mbps signals have a polarity but PHY automaticaly turns them internally 'auto polarity' feature. => no polarity.

the RX and TX pair can be exchanged the same way, because the PHY knows 'auto-cross-over, MDIX' function. So you don't care about standard or cross patch-cable.

For PCB design this means:

=> it's easy to avoid vias in PHY signals - easy straight forward to the MagJack.

c) more tricky ! you need the 50ohm (49 is OK) resistors as close to the PHY as possible.

I did that using vias and put the 50ohm R's on the bottom side of PCB.

d) inside the transformer is a center connection 'CT' = 'center tab' that must be connected to analog Vcc here 3.3V.

This voltage must be as stable and noise free as possible. Therefor we added C's right under the MagJack on bottom side.

Normally this CT voltage is only needed for the TX pair, but because of auto crossover, also needed for RX pair.

Sometimes (like here) this two CT are connected internally already so there is only one CT at this MagJack.

e) every PHY has an external R for 'Bandgap' or 'Bias' adjustment. This must be perfectly match the manufactureres recomendation better 1% ! we used two R's in series so you can select cheap R's just out of standard E12 or E24.

 

Now, it's on you to give live into it. Have fun with coding.

 

BR, Joachim

[RobG 1,892]

Looks good. Have you consideret using JSON instead of XML? It's quite easily parsed by any web browser, and is a less verbose than XML. As JSON block ends don't depend on their start (compared to XMLs ), I believe that it would be easier to generate the responses.

 

Yes, I am considering JSON as well.

The reason I like XML better is because it is more versatile and has better support.

In any case, I will try to make generating response as abstract as possible, so you can switch from JSON to XML as needed.

 

{
  "msp430":{
     "status":0,
     "adcmem":1023,
     "adcs":[
        {
           "channel":0,
           "label":1023
        },
        {
           "channel":1,
           "label":1023
        }
     ],
     "ports":[
        {
           "name":"p1",
           "dir":"0f",
           "in":"7f",
           "ifg":"00"
        },
        {
           "name":"p2",
           "out":"01"
        }
     ]
  }
}

[xpg 127]

Yes, I am considering JSON as well.

The reason I like XML better is because it is more versatile and has better support.

In any case, I will try to make generating response as abstract as possible, so you can switch from JSON to XML as needed.

 

In the end I guess it's all about preferences. Being able to switch between the two would be a really nice thing, if it can be done without too much effort. After all, it's quite trivial to convert between XML and JSON

 

Oh, and I wonder how difficult it would be to UPnP-enable such a system -- not that I think it's fun to parse XML on a small MCU :-)

[RobG 1,892]

Found some time to work on the server today and it is mostly finished.

I am still having some problems with the chip's buffer (as you can see on the image) and after they are resolved, I will create a simple page that will hide the "ugliness" of the request parameters and XML.