Jump to content
43oh

4jochen

Members
  • Content Count

    6
  • Joined

  • Last visited

Reputation Activity

  1. Like
    4jochen got a reaction from RobG in MSP430F5438A internet connectivity   
    Hello Apr30,
     
    OK, I fully agree that the W5200 in QFN is not maker friendly, but the W5500 in QFP with 0.5mm pitch - is possible also for makers.
    I know that small "drawback" and I'm sorry we can not offer any wide body package.
    But, we offer the W5500 also in the WIZ550io bread-board friendly v.1.1 Module and many makers like RobG here offer Booster-Pack, Shields and plug-in modules....
    I like RobG's Booster Pack : http://forum.43oh.com/topic/4490-ethernet-booster-pack-v3/
     
    I think the 10min more longer soldering on the W5500 with the fine pitch QFP package contrast to +100h to +1000h more longer coding and debugging with the 'other' Ethernet-Controllers ... less performance at the end ...
    ... it's up to you.
     
    BR, Joachim
  2. Like
    4jochen got a reaction from Apr30 in MSP430F5438A internet connectivity   
    I'm from WIZnet Europe - but this is not intended as advertisement.
    Here I just like to make a short tech. comparison:
     
                     W5500            | ENC28J60          | CS8900A
                     ---------------------------------------------
    Temp at work:    40
  3. Like
    4jochen got a reaction from RobG in MSP430F5438A internet connectivity   
    I'm from WIZnet Europe - but this is not intended as advertisement.
    Here I just like to make a short tech. comparison:
     
                     W5500            | ENC28J60          | CS8900A
                     ---------------------------------------------
    Temp at work:    40
  4. Like
    4jochen reacted to spirilis in Ethernet Booster Pack v3   
    Ok, my totally reworked version of RobG's G2553 example.
     
    A number of changes have occurred here to Rob's core code:
    1. Some minor bugs in the Sn_IMR macros in w5500.h were fixed (although I don't use them)
    2. A "piecemeal I/O" infrastructure has been added-
    BSS bloated by 32 bytes as we now track a local copy of the RX_RD and TX_WR variables, since these variables can be written to but not read back; reading back their values actually gives us the original values, until Sn_CR_RECV or Sn_CR_SEND respectively are submitted; the whole idea behind this "piecemeal I/O" is that we're not doing this, we don't want the buffers to change yet.
    u_int _tx_wr_cache[8], _rx_rd_cache[8]; /* Used for "piecemeal" writes & reads when * we update TX_WR or RX_RD but the WizNet still * gives us the old value until we perform a CR * command action on the socket. */ A pair of functions update this value for a specified socket:
    void refreshTXBufferCache(u_char s); void refreshRXBufferCache(u_char s); For the most part you don't have to worry about it, as I've peppered those calls inside the existing stuff like socket() et al.  But do know that if you submit an Sn_CR_SEND or Sn_CR_RECV yourself, you may want to update the internal "state" of those cached variables if you happen to be using the Piecemeal I/O functions.
     
    The piecemeal I/O functions consist of:
    void writeToTXBufferPiecemeal(u_char s, u_char* array, u_int length); void fillTXBufferPiecemeal(u_char s, u_char value, u_int length); void readFromRXBufferPiecemeal(u_char s, u_char* array, u_int length); void flushRXBufferPiecemeal(u_char s, u_int length); // u_int getTXVirtualFreeSize(u_char s); u_int getVirtualRXReceived(u_char s); writeToTXBufferPiecemeal writes the specified array of length bytes to the buffer, updates TX_WR both on the chip and in the local cache, but does not send the data just yet.  It always starts writing from the current value of the "local cached copy" of TX_WR, so that you can continuously append to the buffer without committing the packet.
     
    fillTXBufferPiecemeal is similar, but it writes a single byte length # of times.  I added a fillMemoryArray() call likewise to support that.
     
    readFromRXBufferPiecemeal is as you'd expect... it reads those bytes, updates Sn_RX_RD and a local cached copy of it.  Further reads from that use the local cached copy of RX_RD as the address to start from.
     
    flushRXBufferPiecemeal merely advances RX_RD without reading; advancing the "local cached copy" likewise.
     
    getTXVirtualFreeSize computes the "amount of free space available" using the chip's copy of TX_RD and our local cached copy of TX_WR.
    getVirtualRXReceived computes the "amount of unread data" using the chip's copy of RX_WR and our local cached copy of RX_RD.
     
    Also to make it feel more unix-y, I've added these:
    u_int ntohs(u_char *array); void htons(u_int val, u_char *array); which are used extensively within the DHCP code.
     
    There is a printf-style debugging infrastructure used extensively throughout the dhcplib code, and you can use it in your own software as well.
    See wizdebug.c and wizdebug.h.  It has a hierarchical "debug level" of aliases called wiznet_debugN_printf() where N goes from 1 to 6, and if the WIZNET_DEBUG #define is less than N, that function is #define'd away as a simple ";", with WIZNET_DEBUG 0 removing it entirely.
    From wizdebug.h:
    /* Debug levels: * 1 - Basic information from libraries * 2 - Error reporting from libraries * 3 - Gratuitous information from libraries * 4 - Pedantic information from libraries * 5 - Extraneous detail from base socket library * 6 - Low-level I/O dump from SPI transfer functions * * Each debug level includes information from all levels below. */ #define WIZNET_DEBUG 4 void wiznet_debug_init(); void wiznet_debug_printf(char *format, ...); void wiznet_debug_putc(unsigned int); void wiznet_debug_puts(const char *); #if WIZNET_DEBUG > 0 #define wiznet_debug1_printf(...) wiznet_debug_printf(__VA_ARGS__) #else #define wiznet_debug1_printf(...) ; #endif #if WIZNET_DEBUG > 1 #define wiznet_debug2_printf(...) wiznet_debug_printf(__VA_ARGS__) #else #define wiznet_debug2_printf(...) ; #endif #if WIZNET_DEBUG > 2 #define wiznet_debug3_printf(...) wiznet_debug_printf(__VA_ARGS__) #else #define wiznet_debug3_printf(...) ; #endif (etc and so forth)
     
    You may want to inspect wiznet_debug_init() in wizdebug.c to make sure it supports your UART or other peripheral correctly.  Likewise, the source is all there, you can change it to spit the data out over SPI or I2C or whatever if you'd like.
    The printf function is based on @@oPossum 's code... minor addition is a "%h" type exists to print 8-bit hex only, whereas "%x" does 16-bit hex.
    The '\n' char is expanded to '\r\n' for UART use; see the bottom of wiznet_debug_printf() for that code, which can be changed.
     
    Also note that none of this has been tested on CCS yet, so I'll be looking for folks to try it out.
     
    Ok... DHCP library.
     
    dhcplib.h has a tunable: 
    /* User-tunable options. */ #define DHCP_LOOP_COUNT_TIMEOUT 500 The main while() loop in dhcp_loop_configure() does a _delay_cycles(250000) if nothing else is happening, and it will time out after DHCP_LOOP_COUNT_TIMEOUT iterations.
     
    The dhcp library has one simple function for the user to call:
    int dhcp_loop_configure(uint8_t *); // Perform DHCP configuration, optionally reporting back DNS server The uint8_t * pointer argument is a user-supplied buffer where 4 bytes will be written containing the first DNS server entry reported by the DHCP server; if this argument is NULL ( (uint8_t *)0x0000 ), the DNS server info will be ignored.
    If this function returns -1 (0 = success, -1 = error), an extern global called "dhcplib_errno" may be analyzed to discover the cause; a function:
    char *dhcp_strerror(int); // Return descriptive string of dhcplib_errno value has been provided to interpret this, passing a "char *" casted pointer to a const char string declared inside dhcplib.c.
     
    If dhcp_loop_configure returns successful (return value = 0), then your IP, subnetmask and gateway will be automatically configured in the WizNet's system registers.
    Also, the code currently has socket #7 hardcoded as a #define in dhcplib.h
     
    Code: robg-w5500-with-dhcplib.zip
  5. Like
    4jochen reacted to RobG in Ethernet Booster Pack v3   
    Yes there is. You can use W5500's memory as extra RAM.
    @@spirilis was working on DHCP but I am not sure what the status is.
     
    BTW, EBP v2 has space for SRAM memory, so DHCP is also a possibility.
  6. Like
    4jochen reacted to RobG in Ethernet Booster Pack v3   
    My server software is not ready for prime time yet, so here is the driver part.
    This should be enough to get things going for those who have my v3 BP or use W5500.
     
    UPDATE: there was a little bug in the code, now fixed, thanks Besi.
     
    W5500.zip
     
     
     
  7. Like
    4jochen reacted to RobG in Ethernet Booster Pack v3   
    The firmware is not that much different.
    There are few minor differences (related to registers) and one major one, which is the way you communicate with the chip.
    I am using my W5200 code and only had to make few changes.
  8. Like
    4jochen reacted to RobG in Ethernet Booster Pack v3   
    Code is almost ready, BP seems to work as expected, ordering 50 sets ( should have them ready right before Xmas )
     
     

     
  9. Like
    4jochen reacted to RobG in Ethernet Booster Pack v3   
    Buy: The 43oh Store or Rob's Tindie Store.
     
    The newest version of the Ethernet BoosterPack is based on the newest chip from WIZnet, W5500.
     
    P1.5 - SCLK
    P1.6 - MISO
    P1.7 - MOSI
    P2.3 - /CS
    P2.4 - /INT
    P2.5 - /RST
     

     
    Configuration jumpers are on the bottom, PMODE1-PMODE3, LINK LED, and ACT LED.
    LED jumpers control which LEDs are used, on board or socket.

     
     
    Available on Tindie.
  10. Like
    4jochen reacted to spirilis in WizNet W5200 C library   
    Ok well, the code's a bit piggish, and I found a bug in one of the foundation lib functions, but I got a successful connection!!
    Init- Send DHCPDISCOVER: Our MAC: 54520000F801 Check for DHCPOFFER... Found packet: dhcp_read_option opt = 53, len = 1 Packet is DHCPOFFER dhcp_read_option opt = 1, len = 4 dhcp_read_option opt = 58, len = 4 dhcp_read_option opt = 59, len = 4 dhcp_read_option opt = 51, len = 4 dhcp_read_option opt = 54, len = 4 DHCP server = 0A6808C9 dhcp_read_option opt = 3, len = 4 gateway = 0A687301 dhcp_read_option opt = 6, len = 8 DNS = 0A6808C9 dhcp_read_option opt = 255, len = 0 Send DHCPREQUEST: Check for DHCPACK... Found packet: yiaddr_ack = 0A687329 siaddr_ack = 00000000 dhcp_read_option opt = 53, len = 1 Packet is DHCPACK dhcp_read_option opt = 58, len = 4 dhcp_read_option opt = 59, len = 4 dhcp_read_option opt = 51, len = 4 dhcp_read_option opt = 54, len = 4 siaddr_ack = 0A6808C9 dhcp_read_option opt = 1, len = 4 dhcp_read_option opt = 255, len = 0 DHCPACK contents processed; DNS was provided Configuring WizNet IP settings DHCP completed: Main registers: Mode: 0x00 Sys IRQ: 0x00 Sock IRQ Mask: 0x00 Retry Count: 0x08 Sock IRQ Pending: 0x00 PHY status: 0x27 Sys IRQ Mask: 0x00 Socket #0: Mode: 0x00 IRQ: 0x00 Status: 0x00 Source port: 0x0000 Dest IP: 0x00000000 Dest port: 0x0000 MSS: 0x0000 IP TOS: 0x00 IP TTL: 0x80 TX buffer free: 0x0800 TX readptr: 0x0000 TX writeptr: 0x0000 RX recvsize: 0x0000 RX readptr: 0x0000 RX writeptr: 0x0000 IRQ Mask: 0xFF wiznet_socket(): 6 connect(74.112.203.145): send: GET / HTTP/1.0 Host: spirilis.net recv loop: line: 17 HTTP/1.1 200 OK line: 37 Date: Wed, 26 Feb 2014 19:27:47 GMT line: 70 Server: Apache/2.2.9 (Debian) PHP/5.3.6 mod_ssl/2.2.9 OpenSSL/0.9.8g line: 46 Last-Modified: Mon, 11 Jan 2010 15:10:11 GMT line: 35 ETag: "35446f1-168-47ce4ef003ac0" line: 22 Accept-Ranges: bytes line: 21 Content-Length: 360 line: 23 Vary: Accept-Encoding line: 19 Connection: close line: 25 Content-Type: text/html line: 2 line: 7 <html> line: 7 <head> line: 18 <title>hi</title> line: 7 <body> line: 22 <h1>spirilis.net</h1> line: 16 <p>welcome.</p> line: 8 </body> line: 10 <address> line: 126 <a href="http://ubuntucounter.geekosophical.net" title="The Ubuntu Counter Project - user number # 960"><img src="http://ubuntline: 120 ucounter.geekosophical.net/img/ubuntu-user2.ph> line: 11 </address> line: 8 </html> recv error: Not connected Successful DHCP register, followed by HTTP client request.  Damned program ballooned to 14KB though.  I do have some strerror() type of functions defined, including a dnslib_strerror() and dhcp_strerror() though with their corresponding rodata descriptions.
     
    This example program looks like this for the init & DHCP portion:
    int main() { int sockfd, i; uint8_t netbuf[128]; uint16_t myip[2], dns[2]; WDTCTL = WDTPW | WDTHOLD; ucs_clockinit(16000000, 1, 0); __delay_cycles(160000); uartcli_begin(uartbuf, 8); uartcli_println_str("Init-"); if ( (sockfd = wiznet_init()) < 0) { // borrowing 'sockfd' for storing return value uartcli_print_str("FAILED: "); interpret_senderror(sockfd); LPM4; } w52_portoffset = 0; while (wiznet_phystate() < 0) __delay_cycles(160000); dns[0] = dns[1] = 0xFFFF; i = dhcp_loop_configure(1, dns); // The DHCP step if (i < 0) { uartcli_print_str("dhcp_loop_configure error: "); interpret_senderror(i); uartcli_print_str("dhcplib errno: "); uartcli_println_str(dhcp_strerror(dhcplib_errno)); LPM4; } dnslib_resolver = dns; uartcli_println_str("DHCP completed:"); wiznet_debug_uart(0); if (dns[0] == 0xFFFF || dns[1] == 0xFFFF) { uartcli_println_str("DHCP completed but DNS not configured."); LPM4; } sockfd = wiznet_socket(IPPROTO_TCP); if (sockfd < 0) { uartcli_print_str("wiznet_socket failed: "); interpret_senderror(sockfd); LPM4; } ...yadda yadda...
  11. Like
    4jochen reacted to RobG in Ethernet Booster Pack   
    They are on their way to the store right now.
    I am not planning to make any more at this time, maybe if I get an oven.
    Another board with 0805 parts sold as kit is a possibility.
     
    Almost forgot, many thanks to Joachim and SugarAddict for their help with this project!
  12. Like
    4jochen reacted to bluehash in Wiznet WizFi210 Wifi Wirefree Booster Pack   
    Just came in along with the SDCard BoosterPacks.
     

     
    Footprint(unsoldered) checks out perfectly.

  13. Like
    4jochen reacted to RobG in Ethernet Booster Pack   
    Here's a version of my Ethernet board with on board G2553.
    0.05" programming header, 0.1" header with 8 GPIOs , and an LDO are also included.
     

  14. Like
    4jochen got a reaction from grojguy in Ethernet Booster Pack   
    Hello Rob,
     
    very good. This PCB looks briliant. :thumbup:
    Nevertheless - the PHY signals are critical.
    I'm sure it will work, but maybe I can try an improvement on schematic and PCB layout.
    There are some small things that can be improved between W5200 and MagJack.
    Maybe you can send me your eagle lbr, sch and brd files -I'll send back my version and you decide.
    I'm actual working on an official WIZnet.lbr (all parts in one lbr) so I can also crosscheck your footprint.
     
    As this is my first posting here I like to introduce myselfe.
    I'm Joachim, WIZnet member & FAE in Europe and graduated engineer in electronic and IT.
    In the past sometimes 8051, Cortex M3 and Renesas coder, but Hardware is my first place.
    Sorry, but I never met the MSP430 MCU but maybe in the future - your board...
     
    ...like to have one ! order !
     
    best regards, Joachim W
  15. Like
    4jochen reacted to RobG in Ethernet Booster Pack   
    Almost there
     

  16. Like
    4jochen got a reaction from GeekDoc in Ethernet Booster Pack   
    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
  17. Like
    4jochen got a reaction from oPossum in Ethernet Booster Pack   
    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
  18. Like
    4jochen got a reaction from RobG in Ethernet Booster Pack   
    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
  19. Like
    4jochen got a reaction from gordon in Ethernet Booster Pack   
    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
  20. Like
    4jochen got a reaction from xpg in Ethernet Booster Pack   
    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
  21. Like
    4jochen got a reaction from zeke in Ethernet Booster Pack   
    Hello Rob,
     
    very good. This PCB looks briliant. :thumbup:
    Nevertheless - the PHY signals are critical.
    I'm sure it will work, but maybe I can try an improvement on schematic and PCB layout.
    There are some small things that can be improved between W5200 and MagJack.
    Maybe you can send me your eagle lbr, sch and brd files -I'll send back my version and you decide.
    I'm actual working on an official WIZnet.lbr (all parts in one lbr) so I can also crosscheck your footprint.
     
    As this is my first posting here I like to introduce myselfe.
    I'm Joachim, WIZnet member & FAE in Europe and graduated engineer in electronic and IT.
    In the past sometimes 8051, Cortex M3 and Renesas coder, but Hardware is my first place.
    Sorry, but I never met the MSP430 MCU but maybe in the future - your board...
     
    ...like to have one ! order !
     
    best regards, Joachim W
  22. Like
    4jochen got a reaction from RobG in Ethernet Booster Pack   
    Hello Rob,
     
    very good. This PCB looks briliant. :thumbup:
    Nevertheless - the PHY signals are critical.
    I'm sure it will work, but maybe I can try an improvement on schematic and PCB layout.
    There are some small things that can be improved between W5200 and MagJack.
    Maybe you can send me your eagle lbr, sch and brd files -I'll send back my version and you decide.
    I'm actual working on an official WIZnet.lbr (all parts in one lbr) so I can also crosscheck your footprint.
     
    As this is my first posting here I like to introduce myselfe.
    I'm Joachim, WIZnet member & FAE in Europe and graduated engineer in electronic and IT.
    In the past sometimes 8051, Cortex M3 and Renesas coder, but Hardware is my first place.
    Sorry, but I never met the MSP430 MCU but maybe in the future - your board...
     
    ...like to have one ! order !
     
    best regards, Joachim W
  23. Like
    4jochen got a reaction from cubeberg in Ethernet Booster Pack   
    Hello Rob,
     
    very good. This PCB looks briliant. :thumbup:
    Nevertheless - the PHY signals are critical.
    I'm sure it will work, but maybe I can try an improvement on schematic and PCB layout.
    There are some small things that can be improved between W5200 and MagJack.
    Maybe you can send me your eagle lbr, sch and brd files -I'll send back my version and you decide.
    I'm actual working on an official WIZnet.lbr (all parts in one lbr) so I can also crosscheck your footprint.
     
    As this is my first posting here I like to introduce myselfe.
    I'm Joachim, WIZnet member & FAE in Europe and graduated engineer in electronic and IT.
    In the past sometimes 8051, Cortex M3 and Renesas coder, but Hardware is my first place.
    Sorry, but I never met the MSP430 MCU but maybe in the future - your board...
     
    ...like to have one ! order !
     
    best regards, Joachim W
×
×
  • Create New...