Quantcast
Channel: TCP Stack support for LAN9303
Viewing all 32 articles
Browse latest View live
↧

TCP Stack support for LAN9303 (Andy123)

August 17, 2012, 11:24 pm
$
0
0
Hi everybody
It is been a while since I visited this forum, so bear with me please ;)

Curently I have a design that uses PIC32MX with LAN8720 transceiver for some simple industrial application.
I was asked if it will be possible to replace LAN8720 with a managed switch type preferably LAN9303 and add micro-SD card to it.
 
The goal is to set switch port mirror, enable promiscuous mode, capture Ethernet traffic and save it to SD in a format that Wireshark can read.
Capture duraton does not have to be long, few minutes is OK, but it has to be broken into multiple files ~10MB each
 
So I have multiple questions:
- <edit: first question removed, found in forum that I answered it mysef some time ago wink" />>
- can current TCP stack support LAN9303? I did not try to load current stack.
- will PIC32MX be fast enought to handle ~25000 packets (100-500-byte each) per second and safe data to SD?
 
Any ideas are welcome, except why in a world you do this?
↧
Search

Re:TCP Stack support for LAN9303 (HowardSchlunder)

August 18, 2012, 10:12 am
$
0
0

- can current TCP stack support LAN9303? I did not try to load current stack.

Yes, but there is no native support for the LAN9303. You'll have to write your own "PHY driver" for it in order to control the non-IEEE 802.3 features, like port mirroring. Fortunately, this will likely be extremely simple. See for example, the ETHPIC32ExtPhySMSC8720.c file.
 
Having said this, your application description doesn't require a TCP/IP stack at all and a TCP/IP Stack won't help you do any of the required packet copying tasks. It would be better to simply write your application from scratch using the C32 Ethernet peripheral library (or direct PIC32MX7XX/6XX MAC peripheral registers) plus an SD card/file system library.
 

- will PIC32MX be fast enought to handle ~25000 packets (100-500-byte each) per second and safe data to SD?

No. 25000 packets per second @ 500 bytes each is the full 100Mbps that is possible through Fast Etherent. Getting the data into the PIC and adding the necessary Wireshark formatting is quite doable when you skip the TCP/IP stack processing. However, pushing 100Mbps of data out to an SD card won't be possible. Many (most?) SD cards can't write anywhere near this fast. For those that can, you would have to beam the data over using the 4-bit SD Bus interface, which would require specialized PIC hardware to achieve 100Mbps. Bit banging this interface would almost certainly be slower than using the SPI interface. The PIC32MX7XX/6XX can operate the SPI at 25MHz maximum, which means your max possible data rate is going to be appreciably lower than 25Mbps.
↧
↧

Re:TCP Stack support for LAN9303 (Andy123)

August 18, 2012, 10:30 am
$
0
0
25,000 pps is extreme, realistically I need maybe 1000 pps, but SPI bus will definately be a limitation since every byte on the wire needs to be writtent to SD along with some timing information.
I guess I need to do som calculations first and figure out how to store data.
Thanks
 
↧

Re:TCP Stack support for LAN9303 (HowardSchlunder)

August 18, 2012, 10:50 pm
$
0
0
1000 pps is a lot more realistically achievable bus bandwidth wise. However, now I feel compelled to point out your next significant bottle neck/problem. Earlier you mentioned 10MB files. This implies you want the SD card to have an ordinary file system like FAT32 on it. This file system is your next problem and will make 1000 pps difficult or impossible.
 
Writing Ethernet packets could theoretically be done sequentially in 512 byte, sector aligned blocks and therefore incur no excess SPI overhead. However, with the addition of a filesystem like FAT32, you must also periodically read and write to the File Allocation Table as new clusters are required. This will add a great deal of overhead and likely crater your write throughput, especially when trying to find free clusters on a multi-gigabyte SD card that's mostly full and has freespace fragmentation. PCs can get around this performance problem by caching the whole FAT in RAM (several megabytes of data for modern volume sizes). For you to get around this problem, you'll likely have to custom talor your file system implementation to find, allocate and cache the locations of the needed free clusters in the FAT before starting the Ethernet capture. I.e. you probably cannot use the Microchip MDD library. There is additional information on this problem and MDD performance in this thread: http://www.microchip.com/forums/m647201-print.aspx
 
Without a FAT32 implementation that is specifically designed for high speed embedded write performance, I expect less than 100 pps could be saved. Under worst case SD card conditions, even 10 pps might be challenging. This wouldn't be a problem if you didn't have a file system.
↧

Re:TCP Stack support for LAN9303 (Andy123)

August 19, 2012, 12:02 am
$
0
0
Thank you Howard
Again, I just started my research and I completely missed possible SD bottleneck concentrating on the Ethernet side of the issue
Now it appear that it Ethernet side will not be a problem.
I will shift my research to SD now.
SD card area is not the one I am very familiar with. FAT system may be another issue
From what I remember ~10 years ago, my old company was forced to by Microsoft FAT license to use FAT formatted CF cards in their products, I am not sure what situation is today with SDs and I don't want to deal with any licensing or any other legal issues.
 
In any case I really appreciate your help for steering in SD direction.
Thanks! 
↧
↧

Re:TCP Stack support for LAN9303 (Andy123)

February 24, 2013, 10:35 am
$
0
0
I want to bring this old thread back since I finally got time to work on this and made a functional prototype.
 
Yes, but there is no native support for the LAN9303. You'll have to write your own "PHY driver" for it in order to control the non-IEEE 802.3 features, like port mirroring. Fortunately, this will likely be extremely simple. See for example, the ETHPIC32ExtPhySMSC8720.c file.

I was able to read and write registers 0-31 of all 3 PHYs, but I am not sure how to access registers that mapped to higher numbers?
 
↧

Re:TCP Stack support for LAN9303 (Andy123)

February 25, 2013, 5:09 am
$
0
0
I figured this out - manual page 127:)
It uses combined fields of Phy address and attribute number to create a memory address 
Two 16 bit operations require to get 32 bit value
I did not try this yet, but it looks straigh forward
↧

Re:TCP Stack support for LAN9303 (roundrocktom)

March 6, 2013, 10:58 pm
$
0
0
Andy - How are you managing the SMSC LAN9303?   SMI  or I2C?
 
Web Page:
http://www.smsc.com/Produ...tches/LAN9303_LAN9303M
 
Click "download" to get to the documents (datasheet, reference design).
LAN9303/LAN9303i datasheet  (revision 1.5  07-08-11)
 
section 2.3.4 management modes, there are four management modes:
P0_Mode [2:0]  and MNGT1_LED4P & MNGT0_LED3PST will set the modes.
Table 3.4 Port 0 MII/RMII pins will list how to set Port 0 straps
 
 
Nice thing about the LAN9303 is you can set it up in Virtual PHY mode, which allows the software that was running the LAN8720 to think it is a just a single port PHY sitting there.  [registers 0-15 are common to all IEEE PHys;  16-31 are device specific....  LAN9303 Virtual PHY uses 0-6 & 31]   This makes life easy to get up and running,  just make sure your strapping is correct for things like PHY address and strapping MII/RMII, etc.
 
Let me know what mode you are using, glad to give pointers.
 
 
 
 
 
 
 
 
 
 
 
↧
Search

Re:TCP Stack support for LAN9303 (Andy123)

March 7, 2013, 1:44 am
$
0
0
 roundrocktom
 
As I pointed in my previous post - I am all set, I already moved on
My prototype with LAN9303 is working great and I am doing other tasks now based on the switch functionality
 
to answer your questions:
Yes, I set it for virtual PHY and using SMI to manage it.
I can read and write any registers without any problems
Earlier I had some issues with 18xx regisrters but quicky realized that I must ready both High and Low of 32 bit register even only Low portion has data
 
I can email my register read/write routines if somebody needs them.
 
↧
↧

Re:TCP Stack support for LAN9303 (pluto55)

April 7, 2013, 1:06 pm
$
0
0
Hi, Andy:
I use STM32+LAN9303 for my project , the device mode of LAN9303 is SMI Managed Mode & RMII PHY Mode(Table 4.3 from Revision 1.3),
I want to write SWE_BCST_THROT to configure the broadcast input rate throttling, but I don't know how to
write 1848h,can you give me one example
thank you very much
↧

Re:TCP Stack support for LAN9303 (Andy123)

April 7, 2013, 10:05 pm
$
0
0
I am not sure about STM32, here are routines I have for PIC32 and LAN9303.

for indirect write to CSR reg that is not mapped to memory see page 162 of the user manual
writes also can be done via regs 200-2dc page 167

 unsigned long EthReadRegister(int reg) {
  unsigned long temp;
  unsigned int phy, address;
  phy=((reg & 0x3fc)>>6)| 0x10;
  address= (reg & 0x3c)>>1;
  EthMIIMReadStart(address+1, phy);
  temp= EthMIIMReadResult()<<16;
  EthMIIMReadStart(address, phy);
  return temp+EthMIIMReadResult();
 }
 
 
 void EthWriteRegister(int reg, unsigned long value) {
  unsigned int temp, phy, address;
  phy=((reg & 0x3fc)>>6)| 0x10;
  address= (reg & 0x3c)>>1;
  temp= (unsigned int)(value>>16);
  EthMIIMWriteStart(address+1, phy, temp);   
  temp=(unsigned int)(value&0xffff);
  EthMIIMWriteStart(address, phy, temp );   
 }
 
 // indirect write to CSR reg that is not mapped to memory
 // See page 162
 
 unsigned long EthReadCSRRegister(int reg) {
    EthWriteRegister(0x1b0,(0xc00f0000 | reg));
    while(EthReadRegister(0x1b0) & 0x80000000); // wait for busy to clear
    return EthReadRegister(0x1ac);
 }
  
 void EthWriteCSRRegister(int reg, unsigned long value) {
    EthWriteRegister(0x1ac,value); // prepare data
    EthWriteRegister(0x1b0,(0x800f0000 | reg)); // write command
    while(EthReadRegister(0x1b0) & 0x80000000); // wait for busy to clear
 }
 
 // writes also can be done via regs 200-2dc page 167


↧

Re:TCP Stack support for LAN9303 (pluto55)

April 8, 2013, 4:55 pm
$
0
0
   thank you for your attention, I can't find the defination of these three functions:EthMIIMReadResult()、EthMIIMReadStart()、EthMIIMWriteStart().
does these functions defined in the lib for PIC32 from Microchip?
  would you please tell me the defination of the functions?
 
  
↧

Re:TCP Stack support for LAN9303 (Andy123)

April 8, 2013, 9:35 pm
$
0
0
Functions:EthMIIMReadResult()、EthMIIMReadStart()、EthMIIMWriteStart() are part of Eth library, used to read Phy registers 0-31 and should be available in your compiler.
with LAN 9303 they are using the same functions to read mapped registers - first two routines above do it.
Unmapped registers read/write use other two routines.
↧
↧

Re:TCP Stack support for LAN9303 (pluto55)

April 9, 2013, 4:44 pm
$
0
0
Andy123, thanks a lot ,now I can read and write the register I need .
↧

Re:TCP Stack support for LAN9303 (Andrew Frazer)

August 23, 2014, 11:21 am
$
0
0
Hi,  just wondering if there was any movement by Microchip to put the LAN9303 in the IP stack?
↧
Search

Re:TCP Stack support for LAN9303 (freebsd)

August 24, 2014, 4:29 pm
$
0
0
Harmony v1.0 supports LAN9303  driver.
 
and it is available on the web.
↧

TCP Stack support for LAN9303 (Andy123)

August 17, 2012, 11:24 pm
$
0
0
Hi everybody
It is been a while since I visited this forum, so bear with me please ;)

Curently I have a design that uses PIC32MX with LAN8720 transceiver for some simple industrial application.
I was asked if it will be possible to replace LAN8720 with a managed switch type preferably LAN9303 and add micro-SD card to it.
 
The goal is to set switch port mirror, enable promiscuous mode, capture Ethernet traffic and save it to SD in a format that Wireshark can read.
Capture duraton does not have to be long, few minutes is OK, but it has to be broken into multiple files ~10MB each
 
So I have multiple questions:
- <edit: first question removed, found in forum that I answered it mysef some time ago wink" />>
- can current TCP stack support LAN9303? I did not try to load current stack.
- will PIC32MX be fast enought to handle ~25000 packets (100-500-byte each) per second and safe data to SD?
 
Any ideas are welcome, except why in a world you do this?
↧
↧

Re:TCP Stack support for LAN9303 (HowardSchlunder)

August 18, 2012, 10:12 am
$
0
0

- can current TCP stack support LAN9303? I did not try to load current stack.

Yes, but there is no native support for the LAN9303. You'll have to write your own "PHY driver" for it in order to control the non-IEEE 802.3 features, like port mirroring. Fortunately, this will likely be extremely simple. See for example, the ETHPIC32ExtPhySMSC8720.c file.
 
Having said this, your application description doesn't require a TCP/IP stack at all and a TCP/IP Stack won't help you do any of the required packet copying tasks. It would be better to simply write your application from scratch using the C32 Ethernet peripheral library (or direct PIC32MX7XX/6XX MAC peripheral registers) plus an SD card/file system library.
 

- will PIC32MX be fast enought to handle ~25000 packets (100-500-byte each) per second and safe data to SD?

No. 25000 packets per second @ 500 bytes each is the full 100Mbps that is possible through Fast Etherent. Getting the data into the PIC and adding the necessary Wireshark formatting is quite doable when you skip the TCP/IP stack processing. However, pushing 100Mbps of data out to an SD card won't be possible. Many (most?) SD cards can't write anywhere near this fast. For those that can, you would have to beam the data over using the 4-bit SD Bus interface, which would require specialized PIC hardware to achieve 100Mbps. Bit banging this interface would almost certainly be slower than using the SPI interface. The PIC32MX7XX/6XX can operate the SPI at 25MHz maximum, which means your max possible data rate is going to be appreciably lower than 25Mbps.
↧

Re:TCP Stack support for LAN9303 (Andy123)

August 18, 2012, 10:30 am
$
0
0
25,000 pps is extreme, realistically I need maybe 1000 pps, but SPI bus will definately be a limitation since every byte on the wire needs to be writtent to SD along with some timing information.
I guess I need to do som calculations first and figure out how to store data.
Thanks
 
↧

Re:TCP Stack support for LAN9303 (HowardSchlunder)

August 18, 2012, 10:50 pm
$
0
0
1000 pps is a lot more realistically achievable bus bandwidth wise. However, now I feel compelled to point out your next significant bottle neck/problem. Earlier you mentioned 10MB files. This implies you want the SD card to have an ordinary file system like FAT32 on it. This file system is your next problem and will make 1000 pps difficult or impossible.
 
Writing Ethernet packets could theoretically be done sequentially in 512 byte, sector aligned blocks and therefore incur no excess SPI overhead. However, with the addition of a filesystem like FAT32, you must also periodically read and write to the File Allocation Table as new clusters are required. This will add a great deal of overhead and likely crater your write throughput, especially when trying to find free clusters on a multi-gigabyte SD card that's mostly full and has freespace fragmentation. PCs can get around this performance problem by caching the whole FAT in RAM (several megabytes of data for modern volume sizes). For you to get around this problem, you'll likely have to custom talor your file system implementation to find, allocate and cache the locations of the needed free clusters in the FAT before starting the Ethernet capture. I.e. you probably cannot use the Microchip MDD library. There is additional information on this problem and MDD performance in this thread: http://www.microchip.com/forums/m647201-print.aspx
 
Without a FAT32 implementation that is specifically designed for high speed embedded write performance, I expect less than 100 pps could be saved. Under worst case SD card conditions, even 10 pps might be challenging. This wouldn't be a problem if you didn't have a file system.
↧
Viewing all 32 articles
Browse latest View live
Search
<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>