 |
 |
| View previous topic :: View next topic |
| Author |
Message |
Guest
|
| US232 / USB / ETHERNET ? |
 Posted: Wed Aug 02, 2006 7:35 am |
 |
|
Hi,
I must read 4 Mbytes from a flash memory and then send it (as faster as posible) to my PC. I spend about 20 seconds just for reading all bytes and I'd like to spend no more than 30 additional seconds to transmit it to my PC.
I think rs232 will be too slow, but what about USB or ETHERNET. what do you recommend and why?
I am reading about Microchip's ENC28J60 ethernet controller, I think it would be a good choice and just using 3 PINS.
Ps. Im using a PIC18F452 at 40mhz clk
Thanks for comments.
leto |
|
 |
rwyoung
Joined: 12 Nov 2003
Posts: 563
Location: Lawrence, KS USA
|
|
| Posted: Wed Aug 02, 2006 7:50 am |
|
|
4Mbytes = 4 * 1024 * 1024 = 4,194,304 bytes
The PIC18F452 (I suggest you consider the 18F4520 + FT245 or one of the PICs that has a full-speed USB stack built-in) does not have USB capability.
Assuming you use something like the FT245 USB FIFO chip, you can expect to get a sustained transfer rate of about 8Mbit/sec from that chip (native mode library on PC and careful programming). But if you are using the PIC to shuttle the data from flash to USB, you won't be able to keep the USB FIFO full. Roughly you can expect maybe 2Mbit/sec, probably less.
4,194,304 * 8 / (2Mbit/sec) = 17 seconds. That is being VERY generous with speed estimates. A more reasonable estimate might be about 3 times that long.
If you use the FT232 (USB to serial UART) you can expect maybe 200kbit/sec sustained transfers. Lots fewer pins than the FT245 required but much, much slower.
Not sure what kind of sustained speeds the Microchip USB stack can handle but you are might just meet your 30 second transfer criteria.
I don't think you can get a high sustained rate from the ENC28J60's SPI interface, maybe 200kbit/second to 500kbit/second but I'm only guessing on that one. Several people on this forum have experience with that chip and can provide a better estimate.
_________________
Rob Young
The Screw-Up Fairy may just visit you but he has crashed on my couch for the last month! |
|
|
asmallri
Joined: 12 Aug 2004
Posts: 1635
Location: Perth, Australia
|
|
| Posted: Wed Aug 02, 2006 6:16 pm |
|
|
| rwyoung wrote: | | I don't think you can get a high sustained rate from the ENC28J60's SPI interface, maybe 200kbit/second to 500kbit/second but I'm only guessing on that one. Several people on this forum have experience with that chip and can provide a better estimate. |
The ENC28J60 will drive the SPI bus at 10Mbps. It will easily meet the performance criterial you have outlined.
The PIC18F97J60 (and variants) have an embedded ENC28J60 and they will deliver even higher performance as they do not have the SPI bus 10Mbps limitation.
_________________
Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
rwyoung
Joined: 12 Nov 2003
Posts: 563
Location: Lawrence, KS USA
|
|
| Posted: Thu Aug 03, 2006 7:06 am |
|
|
The ENC28J60 may be able to drive the SPI bus at 10Mbps but I was refering to data moving FLASH to PIC to ENC28J60 and I doubt the average PIC18 could keep things running along that fast.
Rougly, and from memory I think the minimum SPI clock low and clock high times for PIC18s with MSSP modules is something like 1.25Tcy+30ns.
Assuming you are running a 40MHz clock/crystal/PLL Tcy = 100ns so your SPI clock period is 2*(125+30)ns = 310ns or just a bit faster than 3.2MHz. Since you need one clock per bit, I don't think you can hit the 10Mbps mark. Plus you need some cycles to move data around inside the PIC too.
The PIC18F97J60 looks quite exciting though! Quick glance at datasheet and I spotted DMA features for filling the 8K ethernet buffer. Sounds good.
Just watch out for the usual "J" series gotchas I suppose. That and availability, hitting the Buy/Sample button comes up blank, no parts available.
_________________
Rob Young
The Screw-Up Fairy may just visit you but he has crashed on my couch for the last month! |
|
|
asmallri
Joined: 12 Aug 2004
Posts: 1635
Location: Perth, Australia
|
|
| Posted: Fri Aug 04, 2006 1:08 am |
|
|
| Quote: | | Rougly, and from memory I think the minimum SPI clock low and clock high times for PIC18s with MSSP modules is something like 1.25Tcy+30ns. |
Your right - these are the numbers in the data sheet. Yet also in the data sheet "In Master mode, the SPI clock rate (bit rate) is user programbable to be one of the following:
[list=]FOSC/4 (or TCY)
FOSC/16 (or 4 x TCY)
FOSC/64 (or 16 x TCY)
Timer2 output/2[/list]
The first option contradicts the timings. I run the SPI clock at 10MHz as does the Microchip Stack.
| Quote: | | The PIC18F97J60 looks quite exciting though! Quick glance at datasheet and I spotted DMA features for filling the 8K ethernet buffer. Sounds good. |
The DMA engine in the 97J60 functions identically to the DMA engine in the DMA engine in the 28J60 and is used for functions internal to the Ethernet controller. The advantage with the 97J60 is that the Ethernet registers are memory mapped as opposed to accessed via the SPI bus however all other registers are accessed indirectly (similar to ENC28J60) but without the memory map.
| Quote: | | I doubt the average PIC18 could keep things running along that fast. |
Depending on how you build you application. I am running this at 2.5Mbps sustrained throughput with my own stack which is admittedly high optimised for this specific application.
Going back to the original question that was posted at the start of this thread, the ENC 28J60 and PIC can easily hit the performance numbers for the stated problem.
I use FT245 and Ethenet controllers (Realtek and ENC) in several designs. Developing for the FT245 is easier and quicker than developing for Ethernet but Ethernet is the easiest to support. Consider for example you have a terminal session open to the FT245 and reboot the PIC for whatever reason. Windows will see the USB device go away and then come back again. It will see the devices at the same virtual comm port address (assuming you use this method) but you cannot continue to use hypertem (or any other device using the serial subsystem) because windows has a assigned a new handle for the new device. You have to close and reopen you application in order to again attach to the device.
It is also possible to stall the USB subsystem of the FT245 and possibly the PIC is for example you closed the application on the PC. Without the PC having an application associated with the USB port the FT245 buffer fills and, depending on how the code is written, the FT245 does not return ready to the PIC and therefore the application locks up. I have a third party USB device that whenever I plug it into the system the ICD2 debugger has to be reinstalled.
I have found it is far easier to support customers with Etherent attached devices than with USB. USB IMHO should moe accurately be describes as sometimes-plug-and-play, sometimes-plug-and-pray and sometime-completely-useless
_________________
Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
rwyoung
Joined: 12 Nov 2003
Posts: 563
Location: Lawrence, KS USA
|
|
| Posted: Fri Aug 04, 2006 7:07 am |
|
|
| Quote: |
Your right - these are the numbers in the data sheet. Yet also in the data sheet "In Master mode, the SPI clock rate (bit rate) is user programbable to be one of the following:
[list=]FOSC/4 (or TCY)
FOSC/16 (or 4 x TCY)
FOSC/64 (or 16 x TCY)
Timer2 output/2[/list]
The first option contradicts the timings. I run the SPI clock at 10MHz as does the Microchip Stack.
|
It always makes me nervous when the spec says one thing but then the chip is used out-side the spec. But if it works under all the conditions for your design, then fine.
| Quote: |
I use FT245 and Ethenet controllers (Realtek and ENC) in several designs. Developing for the FT245 is easier and quicker than developing for Ethernet but Ethernet is the easiest to support. Consider for example you have a terminal session open to the FT245 and reboot the PIC for whatever reason. Windows will see the USB device go away and then come back again. It will see the devices at the same virtual comm port address (assuming you use this method) but you cannot continue to use hypertem (or any other device using the serial subsystem) because windows has a assigned a new handle for the new device. You have to close and reopen you application in order to again attach to the device.
|
Having trouble following this one. The PIC shoud not be resetting the FT245 unless you have the PIC driving the FT245's RESET# line. Is that the case? RESET# should be driven by the Vcc from the USB port at all times (with pull-down resistor for self-powered configuration). The RSTOUT# pin can be used (buffered so it doesn't screwup the signaling mechanism on D+ when the chip enumerates) to supply a system reset to other chips if needed.
I don't use the VCP driver (or VCP mode in the new unified driver) as it just isn't fast enough anyway. The native mode drivers are pretty robust but I have noticed problems (call it stuttering) when used behind some cheap hubs. Not sure of the failure mechanism as haven't laid hands on a full-speed USB analyzer yet. I use the watchdog timer and some intellegence in the design of the subroutine for writing data out to the FT245 so that if it decides the FT245 FIFO has filled and isn't emptying at an appropriate rate the firmware will fail gracefully.
Anyway, I do agree that Ethernet would probably be the easier mechanism to support in the long run.
I still question the 10MHz SPI clock business.  One of these days when I have the time, it would be something to test (cold, hot, low Vcc, etc).
_________________
Rob Young
The Screw-Up Fairy may just visit you but he has crashed on my couch for the last month! |
|
|
asmallri
Joined: 12 Aug 2004
Posts: 1635
Location: Perth, Australia
|
|
| Posted: Fri Aug 04, 2006 7:25 am |
|
|
| Quote: | | Having trouble following this one. |
Poor choice of words on my part. When I said reboot the PIC I meant power cycle the target platform which includes the USB controller.
| Quote: | | I still question the 10MHz SPI clock business. Cool One of these days when I have the time, it would be something to test (cold, hot, low Vcc, etc). |
Yes interesting. I did not notice this discrepancy until you pointed it out.
_________________
Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
Ttelmah
Guest
|
|
| Posted: Fri Aug 04, 2006 7:45 am |
|
|
Hint:
The '1.25Tcy+30' spec is talking about _slave_ SPI.
The master spec is still borderline for 10MHz (look at the required setup & hold times for the input data), but not quite so badly...
Best Wishes |
|
|
rwyoung
Joined: 12 Nov 2003
Posts: 563
Location: Lawrence, KS USA
|
|
| Posted: Fri Aug 04, 2006 7:49 am |
|
|
| asmallri wrote: | | Quote: | | Having trouble following this one. |
Poor choice of words on my part. When I said reboot the PIC I meant power cycle the target platform which includes the USB controller. |
Yes, cycling the power in a self-powered application can cause the device to re-enumerate. It is the responsibility of the driver to handle such things. This is another reason I don't use the VCP driver. Too easy to confuse it and the hooks don't exist to fix the trouble.
If at all possible, I try and power the design from the USB bus but this has a set of problems all its own... I'm just glad that all my USB interfaced designs have been meant for use in laboratory/industrial settings not commercial. At least that way I have some control over the final configuration of the system.
_________________
Rob Young
The Screw-Up Fairy may just visit you but he has crashed on my couch for the last month! |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
