I took a look at using the DP83848C as was used on the STM3240G-EVAL. There are many conflicts in pin usage when using the full MKII interface. Even the reduce RMii interface has a pin conflict. ETH_RMII _CRS_DV conflicts with the SDI input for the Accelerometer (LIS302DL)
At this point I think using the ENC28J60 with an SPI interface is the simplest option. Any Comments??
There is a third party stack which was developed for the STM32F107 which I think is basically the same as in the STM 32F407 http://www.st.com/internet/com/TECHNICA ... 255062.pdf The app note covers the TCP/IP stack as well a a basic web server
The recent release of the STM32F4 discovery board either as a "free" sample or lost cost at distributors like Mouser($17) raises interesting possibilities if there was an complete Ethernet interface. At less than $20 this would make a great base for a Web Server. What is needed is a cheap daughter or breakout board with the Ethernet physical interface. Possibilities are the likes of National’s DP83848C with is used on STM’s STM3240G-EVAL board or Marvell’s?? This would be a heck more capable than the processor planed for the Web platform V2 at potentially same or less cost If someone with the experience to do the hardware, could help out here that would be fantastic!
For your application of 3m in a home the simplicity of RS232 should work fine. Although the technical spec for RS232 is limited to 50 feet it is commonly exceeded for example, RS232 cable length specifications according to Texas Instruments are: Baud rate Maximum cable length (ft) 19200 50 9600 500 4800 1000 2400 3000
I have personally run RS2332@ 115kb over a 100 ft without problems in quiet environment such as a home as opposed to an industrial plant with major power components
Before I undertake this effort I would like to hear comments from those familiar with the Web platform as to if they see any obvious reason this would not work. I understand this is a non trivial adaptation Thanks
Jack, has any futther testing been done at the highr sampling rates and suppression of the glitches previously observed?
I was looking at the open LA site ( http://sigrok.org/wiki/Main_Page) in particular at the pictures they have included for the various commercial logic analyzers. Although, not knowing the design one can not be sure of the purpose, I thought it was very interesting that all have resistor located near the probe connector.
I bring this to your attention , because I firmly believe serier termination resistors should be added to any revision/upgrade.
[quote author="jack.gassett"] The results are that it looks like the 200Mhz sampling frequency is able to capture the 100Mhz signal on both the buffered and unbuffered pins. The unbuffered pins seem to have less noise and glitches than the buffered pins. [/quote] Jack: Would it be posible to check with serial termination resistors, to see if that would clear the glitches?
As I suggested to Jackeariler, if you rotate the chip 180 deg on both the sch/brd (because the transceiver is symetrical it will not change the I/O pin assinments) the pin 1 of the buffer can be easily routed to the FGPA pin 11 Note Dir tr2 now is attached to 3v3
On second thought it looks to me, routing TR1 following "tdi" signal to pin 11 on the FPGA is not bad, and minimal impact to ground plane. If a feature can be added for no cost ....why not?? opps should have gone to TR2
With the recent routing the FPGA Pins 88 & 89 have been used (which are input only) thus only the first 8 bits: TR1 can be bi directional. As Ian pointed out there are no pins available on the right side, so routing the TR1 to a top FPGA pin would not be clean. Therefore, I suggested control by way of a jumper. NOTE: Not as clean, if holes were provided near the TR1 and at a top available FPGA pin, a jumper wire could be added if the user needed this feature to be controled by the FPGA.
Ian stated my opion its a "feature" that is basically free
Am I only one that would like to see 8 bit assignable to outputs?? For use as a function genrerator extension to SUMP. Although it would be great if I/O control was under the FPGA, I accept that routing would be difficult now. What I see as possible woud be to add a 3 pin selection header/jumper near the bottom right corner routed to pin 1 on the transceiver(direction). Just an idea.
