Ethernet Gateway: Subsystem of PICs vs 32bit micro/RTOS?

[MikeValencia]

I have always wondered about the design approach to a somewhat complex embedded system, which combines a lot of interfaces. Let's say an X-to-Ethernet gateway.

Where "X" can be any or more of the following:
- CAN
- Zigbee 802.15.4
- modem
- etc. etc.
--- don't forget the user interface which would consist of a combination of a simple http server, rs232 interface, and perhaps an LCD display.

A typical approach would be a 32-bit ARM or Coldfire to handle it all. You then have to worry about:
- OS/RTOS:
----- RTOS #1: Licensing fee $$$ (e.g. uCOS-II) or
---- uCLinux: buy ready-made distro $$$ vs. sorting thru several websites to ftp and figure out 2.dot.dot.x.dot.etc. from several CVS repositories.
---- Buy CodeWarrior ($$$$) or go figure out the GNU/GCC freeware tool chains available and read several HOWTOs online ($$$$ in time).
---- What about a TCP/IP stack? Free (?) with some watered-down embedded linux distribution. Add-on cost ($$$$) if you are using an RTOS.
--- Buying a 3rd party demo board ($$$) vs. prototyping your BGA or 164+ pin LQFP hardware
--- Emulation (ICE) tools: $$$$
--- BSP for your target hardware
--- Porting to make it work

Some open source freaks would love to take on the above challenge, and "port" whatever distribution 2.dot.x.dot.x.dot.etc. they can freely find on the net, have a host box running some Linux distro, VI editor, and the latest GCC, a couple Makefiles. Some cash-strapped enthusiasts might even download Cygwin so he can turn his Windows computer into a Linux-like box, only to break the registry and never being able to uninstall it ever again.

~~~~~~~~~~~~~~

But then I think: What about a subsystem of PICs ?
--- PIC1 has an ENJxx single-chip ethernet chip (the smallest solution, and it's all Microchip). ($)
--- PIC2 would be a stripped down version of the PICDEM Z, but then you'd have to wait for Microchip to come around and offer a router/coordinator 802.15.4 stack. ($)
--- PIC3 would have one or more CAN interfaces on it. ($)
--- PIC4: to handle user input and LCD ($)
--- PIC5 (optional): controls the rest of the PICs, so they can do their own thing.

String PICs 1 thru 5 together via SPI, i2c, or CAN, and you now have a multiprocessor solution, simplified thru divide-and-conquer. Furthermore, a subsystem of PICs has the added benefits:
* multiprocessor solution -- no RTOS/OS necessary, probably just need a while(1) loop as your RTOS.
* plug-n-play IP stack from Microchip
* free Zigbee stack (though not complete yet for router or coordinator)
* Ethernet interface is (ENJxx) part is probably one of the most efficient and cheap solutions out there.

~~~~~~~~

I don't really have a programming problem today, since it's Saturday. But I was just wondering on the rest of your thoughts on how to approach a somewhat complex design of an embedded system. It seems that a subsystem of independent PICs doing their own thing but acting in concert is a feasible solution. But all I usually see out there are RTOS-based 32-bit systems.

[newguy]

I don't think there is a problem with this approach.

Personally, I've done the same thing (divide & conquer) on a device I've been working on for 4 years now. Yes, it's finally done.

I can't tell you what the product is, but I needed to do some intensive signal processing. That usually means a DSP. Then add on the special C compiler (like TI's for the TMS320 family), and you're looking at $$$$$. Not a viable solution for someone trying to start a company out of their basement. The upside is that the DSP could handle everything, comms, user interface, signal processing, etc.

I broke the problem up into two basic parts: the master pic, which orchestrates the entire system and is responsible for comms, the user interface, etc., and the signal processor pic, which is responsible for the signal processing (obviously.)

I first made sure that a pic could handle the signal processing, and I helped to streamline things by optimizing the calculations that it had to perform. Then I prototyped it, using a commercial pic experimenter's board, and a regular old student's breadboard. It worked.

Another big upside to this approach, which you mentioned, is that a hobbyist/tinkerer can actually solder most pic packages themselves using a soldering iron. Anything more than about a 64 TQFP, and I start to go cross-eyed.

[Mark]

Why on earth would I want to use 5 pics to do the job of one LCP21XX ARM7 device? Heck the arm7 micro is already cheaper than a high end pic today.

But depending on what the actual project is, you can probably do most of what you want in a single pic. Microchips webserver stack fits in a 18F452 already. Use a 18F6720 and you have tons of room to spare.

As far as an RTOS goes:

www.freertos.org

Probably not the most efficiently but works just fine.

[treitmey]

As far as RTOS, I got the beta CCS rtos a day ago.

[bscogg]

Where can I obtain a copy of the CCS RTOS advertised at Master's last week?

Thanks,
Brad

[Steve H.]

As fas as LAN goes - I've found that the Z-World SBC's are really nice: Low cost, LAN built in, free compiler (with purchase of demo board), etc.

www.zworld.com

HTH....

Steve H.

[DragonPIC]

This is just the type of appliction I have been saying the Ubicom ip2k would be great for. The ip2k is a great chip to replace multiple PIC's or other microcontrollers with. If you can afford their demo board kit (Advanced Wireless Kit), it's great for anything you would use multiple PIC's for and more. www.ubicom.com

With a simple 80-pin chip you can interface ethernet with just about any of the communitcation protocols you have mentioned. The ASM is much like PIC and 8051 and the demo board comes with a GNU toolchain based compiler environment "Unity". If you have any calculations to do, you get a single instruction cycle multiply instruction. There is a 1 cycle PUSH and POP stack. The chip runs at 150MIPS while running out of 16KB SRAM program memory that is loaded from 64KB flash. All on a single chip. I beleive it sells for about $12 a chip too.

The only thing bad about the whole deal is the poor Ubicom support policy and their inability to fill a niche in the market. They are too involved in D-Links GamerLounge wireless 108G gaming router that contains their higher end ip3K chip. Someone needs to form a partnership with them (like parallax, that already sell the 50+MIPS SX chip) and get the ip2k out there where it can be noticed.
_________________
-Matt