PIC Microcontrollers and TCP/IP
Discussion
Perhaps a bit heavy for a Friday, but is/has anyone here doing/done anything with PICs and TCP/IP.
Loads of stuff on the Web for 'smallest web server ever' but I'm interested in a PIC supporting two Ethernet interfaces. Remember my killer App? I want to run it on a PIC. One interface will stream data through the system under test, the other will be used as a control channel.
I'm looking to hardwire a heap of these to a patch panel thus instantly creating 100s of clients coming through on individual Ethernet connections. They'll all be managed over a hub/backbone type of interface.
It's a plan... No?
Loads of stuff on the Web for 'smallest web server ever' but I'm interested in a PIC supporting two Ethernet interfaces. Remember my killer App? I want to run it on a PIC. One interface will stream data through the system under test, the other will be used as a control channel.
I'm looking to hardwire a heap of these to a patch panel thus instantly creating 100s of clients coming through on individual Ethernet connections. They'll all be managed over a hub/backbone type of interface.
It's a plan... No?
This sounds like a job for an FPGA!
I'm not entirely sure what you're trying to do, and I have read you previous thread. Either way some of the "structured ASIC" approaches can be pretty cost effective.
Do you have volume in mind? If you do, you certainly don't want to be faffing with PIC's, if you don't then you probably don't want to be faffing with PIC's.
I'm not entirely sure what you're trying to do, and I have read you previous thread. Either way some of the "structured ASIC" approaches can be pretty cost effective.
Do you have volume in mind? If you do, you certainly don't want to be faffing with PIC's, if you don't then you probably don't want to be faffing with PIC's.
Even the fastest PIC will struggle to fill a 10base channel, never mind handling 2 physical channels (do they have to be physically separate?). PICs are designed for control and aren't the best at moving round big data chunks, and most of them don't have DMA. One of the Atmel ARM7 devices running ucLinux would be better, or an ARM9 with "proper" Linux which is much better at coping with 100Mbit data. These have plenty of dev kits around, or alternatively you can get hold of one of the ARM9 based routers and cannibalise it. They already run linux and obviously have multiple channels with all the MAC/PHY hardware.
If you need to go gigabit then yes, it is FPGA time.
FPGA's aren't just about performance. I would agree that there is the potential for a greater NRE, but critically it very much depends on what you're doing. If it's just a whole pile of ethernet and minimal top level control, then theres every possibility that the top level can just be a pretty simple state machine. The interface is easy as an off the shelf job, replicate as the device allows.
Theres a direct migration path to a formal silicon compiler, and if you go the route of using an off the shelf ARM core, then you'll never suffer from obsolescence.
The whole thing fits into the cheapest or the biggest FPGA as you choose.
Looking at what you get in terms of bang for buck with an FPGA, if the key aim is to do lots of ethernet and not much computing, then FPGA must be the way to go.
Theres a direct migration path to a formal silicon compiler, and if you go the route of using an off the shelf ARM core, then you'll never suffer from obsolescence.
The whole thing fits into the cheapest or the biggest FPGA as you choose.
Looking at what you get in terms of bang for buck with an FPGA, if the key aim is to do lots of ethernet and not much computing, then FPGA must be the way to go.
Fascinating stuff guys!
But what you have to remember is that we are trying to investigate satellite services. So generally we are looking at quite low bit bit rates - sub 500 kbps. It would be great if we could gear up for higher bit rates and target LAN and other WAN technologies, but I'm thinking of $35 Terminal Emulators, packaged at ten to the dozen, all wired to the back of a patch panel. So maybe FPGA is a bit over kill?
It's lovely to see how you people run to the big heavy stuff
Dilbert... this FPGA stuff might be a way forward. But I need to get a prototype together very quickly. Performance isn't really an issue, and on top of that, higher level protocols aren't really of much interest either. Imagine black box number 1 and a few hundred clients talking through it to server number 1.
Loadsa Clients ---> Black Box 1 ------> Server 1
Forgetting everything you ever knew about upper protocols, we want to get hundreds of TCP or UDP packets flowging throw Black Box 1 all from individual IP addresses.
Now let's move from a unicast onto a multicast scenario suddenly we need a whole load of MAC addresses and not just IP addresses. We need to physically, (in hardware ??) separate all the 'Loadsa Clients'
One option is VM ware .... but how many clients can we run on a single harware platform.
I want to run a few hundred multicast clients... all I need is a few K of memory and a processor that can put a few hundred Kbytes/sec onto an ethernet wire and all plug individually into a switch.
Do I really go with ARM or FPGA or can I just buy a bucnh of these at $69 each?
www.modtronix.com/product_info.php?products_id=196
But what you have to remember is that we are trying to investigate satellite services. So generally we are looking at quite low bit bit rates - sub 500 kbps. It would be great if we could gear up for higher bit rates and target LAN and other WAN technologies, but I'm thinking of $35 Terminal Emulators, packaged at ten to the dozen, all wired to the back of a patch panel. So maybe FPGA is a bit over kill?
It's lovely to see how you people run to the big heavy stuff
Dilbert... this FPGA stuff might be a way forward. But I need to get a prototype together very quickly. Performance isn't really an issue, and on top of that, higher level protocols aren't really of much interest either. Imagine black box number 1 and a few hundred clients talking through it to server number 1.
Loadsa Clients ---> Black Box 1 ------> Server 1
Forgetting everything you ever knew about upper protocols, we want to get hundreds of TCP or UDP packets flowging throw Black Box 1 all from individual IP addresses.
Now let's move from a unicast onto a multicast scenario suddenly we need a whole load of MAC addresses and not just IP addresses. We need to physically, (in hardware ??) separate all the 'Loadsa Clients'
One option is VM ware .... but how many clients can we run on a single harware platform.
I want to run a few hundred multicast clients... all I need is a few K of memory and a processor that can put a few hundred Kbytes/sec onto an ethernet wire and all plug individually into a switch.
Do I really go with ARM or FPGA or can I just buy a bucnh of these at $69 each?
www.modtronix.com/product_info.php?products_id=196
Edited by TheExcession on Saturday 15th July 00:22
Fear that FPGA learning curve!
I'm a few months into it and it feels like I still need ropes and ladders. It probably doesn't help that I come from a hardware background and see systems as gates rather than VHDL/Verilog scripts. They are amazing things, and effectively leverage the concept of code libraries into the world of hardware, which obviously can lead to dramatically shortened development times and costs. They are still rather scary though!
Edited to add:
Fair enough if you don't need much throughput, I'm just a bit wary of the old "he who only has a hammer sees everything as a nail". I had something more like this in mind:
www.embeddedartists.com/products/boards/lpc2138_100eth.php (100Mb - €65) or
www.embeddedartists.com/products/boards/lpc2138_eth.php (10Mb - €35)
But if you are familiar with PICs, then there is probably nothing to be gained by jumping to a more powerful system with all the hassle that entails.
I'm a few months into it and it feels like I still need ropes and ladders. It probably doesn't help that I come from a hardware background and see systems as gates rather than VHDL/Verilog scripts. They are amazing things, and effectively leverage the concept of code libraries into the world of hardware, which obviously can lead to dramatically shortened development times and costs. They are still rather scary though!
Edited to add:
Fair enough if you don't need much throughput, I'm just a bit wary of the old "he who only has a hammer sees everything as a nail". I had something more like this in mind:
www.embeddedartists.com/products/boards/lpc2138_100eth.php (100Mb - €65) or
www.embeddedartists.com/products/boards/lpc2138_eth.php (10Mb - €35)
But if you are familiar with PICs, then there is probably nothing to be gained by jumping to a more powerful system with all the hassle that entails.
Edited by Zad on Saturday 15th July 03:33
Zad said:
Fear that FPGA learning curve!
I'm a few months into it and it feels like I still need ropes and ladders. It probably doesn't help that I come from a hardware background and see systems as gates rather than VHDL/Verilog scripts. They are amazing things, and effectively leverage the concept of code libraries into the world of hardware, which obviously can lead to dramatically shortened development times and costs. They are still rather scary though!
Edited to add:
Fair enough if you don't need much throughput, I'm just a bit wary of the old "he who only has a hammer sees everything as a nail". I had something more like this in mind:
www.embeddedartists.com/products/boards/lpc2138_100eth.php (100Mb - €65) or
www.embeddedartists.com/products/boards/lpc2138_eth.php (10Mb - €35)
But if you are familiar with PICs, then there is probably nothing to be gained by jumping to a more powerful system with all the hassle that entails.
I'm a few months into it and it feels like I still need ropes and ladders. It probably doesn't help that I come from a hardware background and see systems as gates rather than VHDL/Verilog scripts. They are amazing things, and effectively leverage the concept of code libraries into the world of hardware, which obviously can lead to dramatically shortened development times and costs. They are still rather scary though!
Edited to add:
Fair enough if you don't need much throughput, I'm just a bit wary of the old "he who only has a hammer sees everything as a nail". I had something more like this in mind:
www.embeddedartists.com/products/boards/lpc2138_100eth.php (100Mb - €65) or
www.embeddedartists.com/products/boards/lpc2138_eth.php (10Mb - €35)
But if you are familiar with PICs, then there is probably nothing to be gained by jumping to a more powerful system with all the hassle that entails.
Edited by Zad on Saturday 15th July 03:33
They are seriously sweet! Cheap as chip and they look to be twice as much fun. Thanks for the heads up, I'm off to poke around their site a bit more.
Are you using the full on development kit? At €35 I think I'll get one just for geek factor
TheExcession said:
... Remember my killer App? ...
Whats that then out of interest?
BTW: www.picbasic.co.uk/forum/showthread.php?t=1532 (any good)
TheExcession said:
Fascinating stuff guys!
But what you have to remember is that we are trying to investigate satellite services. So generally we are looking at quite low bit bit rates - sub 500 kbps. It would be great if we could gear up for higher bit rates and target LAN and other WAN technologies, but I'm thinking of $35 Terminal Emulators, packaged at ten to the dozen, all wired to the back of a patch panel. So maybe FPGA is a bit over kill?
It's lovely to see how you people run to the big heavy stuff
Dilbert... this FPGA stuff might be a way forward. But I need to get a prototype together very quickly. Performance isn't really an issue, and on top of that, higher level protocols aren't really of much interest either. Imagine black box number 1 and a few hundred clients talking through it to server number 1.
Loadsa Clients ---> Black Box 1 ------> Server 1
Forgetting everything you ever knew about upper protocols, we want to get hundreds of TCP or UDP packets flowging throw Black Box 1 all from individual IP addresses.
Now let's move from a unicast onto a multicast scenario suddenly we need a whole load of MAC addresses and not just IP addresses. We need to physically, (in hardware ??) separate all the 'Loadsa Clients'
One option is VM ware .... but how many clients can we run on a single harware platform.
I want to run a few hundred multicast clients... all I need is a few K of memory and a processor that can put a few hundred Kbytes/sec onto an ethernet wire and all plug individually into a switch.
Do I really go with ARM or FPGA or can I just buy a bucnh of these at $69 each?
www.modtronix.com/product_info.php?products_id=196
But what you have to remember is that we are trying to investigate satellite services. So generally we are looking at quite low bit bit rates - sub 500 kbps. It would be great if we could gear up for higher bit rates and target LAN and other WAN technologies, but I'm thinking of $35 Terminal Emulators, packaged at ten to the dozen, all wired to the back of a patch panel. So maybe FPGA is a bit over kill?
It's lovely to see how you people run to the big heavy stuff
Dilbert... this FPGA stuff might be a way forward. But I need to get a prototype together very quickly. Performance isn't really an issue, and on top of that, higher level protocols aren't really of much interest either. Imagine black box number 1 and a few hundred clients talking through it to server number 1.
Loadsa Clients ---> Black Box 1 ------> Server 1
Forgetting everything you ever knew about upper protocols, we want to get hundreds of TCP or UDP packets flowging throw Black Box 1 all from individual IP addresses.
Now let's move from a unicast onto a multicast scenario suddenly we need a whole load of MAC addresses and not just IP addresses. We need to physically, (in hardware ??) separate all the 'Loadsa Clients'
One option is VM ware .... but how many clients can we run on a single harware platform.
I want to run a few hundred multicast clients... all I need is a few K of memory and a processor that can put a few hundred Kbytes/sec onto an ethernet wire and all plug individually into a switch.
Do I really go with ARM or FPGA or can I just buy a bucnh of these at $69 each?
www.modtronix.com/product_info.php?products_id=196
Edited by TheExcession on Saturday 15th July 00:22
Only you can say what you're trying to do!
What do I think?
1) If an FPGA is overkill, then it's overkill.
2) I don't think you're going to be saturating any of the links previously described with any of the processors that have been mentioned. I get the impression that's what youre trying to do.
3) The more of those little boards you use, the worse your mechanical problems are, and the greater the cost is.
4) If the whole thing is as smple as this, Is it reasonable to assume that someone else is already doing it?
5) If this is a demonstration programme, and the solution was easy to achieve, what does it actually prove? Worse, if the mechanical issues for the final solution become an overriding problem how badly will it reflect?
I'm not sure who the hammer analogy was beng fired at, but I think it's quite a big assumption. FPGA is not big guns. It's a part of a balanced portfolio!
Finally, by description, isn't what you're trying to do, a hub/router? If it is and a hub/router doesn't offer the capability that you are seeking, it's probably because, they had to cut costs. Maybe there's a lesson there? The only real way to know what you need is to do the sums. Deciding on the hardware before realising that it's not got the grunt you need is really no place to be.
Edited by dilbert on Saturday 15th July 15:26
Nah, I wasn't having a dig at FPGAs. I have a friend who was brought up (in electronic terms) on PICs and seems to think they are the only micro on the market. Now, they are great little beasties (with the added advantage of being free if Microchip trust you) and some of them are getting quite powerful, but they are essentially controllers rather than calculators or data pumps.
I have to admit that I don't have any Embedded Artists' stuff, but I know several developers that do and are more than happy with them. The dev boards are all more or less the same no matter who makes them so there is rarely any reason not to go for the cheapest.
I'm the kind of massochistic nutter that likes to build his own boards though, and you can set up a full software development studio for free (legally) with the Keil IDE, GNU compiler, Cygwin etc. Having said that, Embedded Artists do some amazingly cheap stuff, far cheaper than I could build a PCB let alone a system. Check out their special offer from last Christmas: www.embeddedartists.com/products/boards/lpc2103_pro001.php (€10 including LCD!)
Not just a Christmas tree. Discard the flashy LED part and you have a proper dev board with all the signals available. I can see why it was only a limited production run, they must surely have lost money on it!
I have to admit that I don't have any Embedded Artists' stuff, but I know several developers that do and are more than happy with them. The dev boards are all more or less the same no matter who makes them so there is rarely any reason not to go for the cheapest.
I'm the kind of massochistic nutter that likes to build his own boards though, and you can set up a full software development studio for free (legally) with the Keil IDE, GNU compiler, Cygwin etc. Having said that, Embedded Artists do some amazingly cheap stuff, far cheaper than I could build a PCB let alone a system. Check out their special offer from last Christmas: www.embeddedartists.com/products/boards/lpc2103_pro001.php (€10 including LCD!)
Not just a Christmas tree. Discard the flashy LED part and you have a proper dev board with all the signals available. I can see why it was only a limited production run, they must surely have lost money on it!
Gassing Station | Computers, Gadgets & Stuff | Top of Page | What's New | My Stuff