Transition problem

:(
Hello, dear PIC friends!
My question is quite common, so I shy to post it again. However, due to my bad English or maybe because a topic is so general and wide, I could not find comprehensive answers yet. As most of you I began with 12x devices then moved to 16f84, then to 16f877 and finally to 18F family. Now, I want to build real industrial application with touch screen and graphic display, peripheral devices and sensors connected by CAN or RS485 bus and Ethernet controller. Obviously, such project exceeds capabilities of single 18F microcontroller. So, I have a few options:
1) Switch to PIC 24 or PIC32 family which currently not supported by PICBasic Pro compiler.
2) Investigate others controllers and compilers which mostly use C++ ,C# and Microsoft .NET framework.
3) Try to stack a few PIC 18X as master and slaves controllers to complete the job.
All these options look challenge to me. My knowledge of Assembler not allows programming PIC24 or PIC32 directly. Microsoft .NET is complex and required huge time investment; moreover all those Motorola/Freescale microcontrollers have manuals over 1000 pages, and due to my English such reading my takes some time. Stacking PICs is easy solution, but unfortunately preserve the problem as it not allows to investigate other microcontrollers and generally move forward.
So, my question: are there any possibilities to soft and gradual transition from PIC18 family to other microcontrollers? (Without chances to became fulltime student). Are any chances to build such system by using single PIC18XX and peripheral boards? ( such, applications normally employ advanced PLC or industrial computer)
Maybe someone already built something similar or at least knows how connect all these worlds.
Any input welcome!
Vladimir

I am not very sure if my answer will help you, but, anyway. You can buy development boards from many sources that have the required peripeherals. One company that comes to mind is olimex, another sparkfun. Most of the times, the board you choose comes with example code that helps you off the ground with the peripherals you desire.

I haven't done any colour graphic displays with PIC, but, for a monochrome graphic with a framebuffer(memory image), you need 1kB for a 128x64 LCD. So, what you could need is lots of internal RAM if you are working with graphic lcds depending on how you implement your logic.

Every controller has its own advantages and limitations. The PIC24/32 series seem to match up to your requirement, but, pbp stops at 18F

For the various peripherals you mention, RS485 is nothing more than a USART, for CAN, you need a pic with the CAN peripheral. Ethernet, many have had success with the ENC24J60 which is also integrated into a PIC now.

Complex projects are 'better' handled with a high level compiler rather than assembler. Saves you lots of time and effort. But, if you're an assembler expert, you can do the job even better.

Thank you, Jerson.
I will check out companies you have mentioned.
By the way, you said about frame buffer LCD. How is this work? Please send me a link.
Best regards
Vladimir

I have built a lot of systems that use multiple 18F devices connected together to deal with a problem, but in most cases, the problem was pin count or the shortage of peripherals (I needed 3 hardware RS-232 ports, for example).
In hindsight, I would have probably been better off using a different processor, one that already had the 3 Asynchronous ports.
And if you are doing something complex, like a frame buffer, you can probably find examples already written in 'C' for the more powerful chips. PBP's structure does not make it easy to use someone else's library.

That said, you can get a lot done by hooking several 18F processors together. In the design mentioned above, there are two Ethernet ports (using Lantronix XPorts), and a console (also RS-232) port. There is no way I could bit
bang any one of the 3 (required) RS-232 ports, so I used 2 - 18F8723's. Processor #1 controls both Ethernet ports with its 2 hardware RS-232 ports. Processor #2 connects to the console. The console sent lots of data (which then had to be sent to the Ethernet ports) at 57.6Kbaud. The packet size and data rate meant that the 4K of RAM I had to use as a buffer would not be large enough. I had to pass the data to processor #2 as fast as I received it. I needed a very fast, low overhead, interrupt-driven protocol to talk between the two chips. I first thought of SPI, but the project also needed two separate I2C ports- which (on a PIC) occupies the same peripherals as SPI. I eventually came up with a scheme that uses the PSP ports (which weren't really designed for bidirectional communication) to talk between the two chips. It all works. But I really should have used a chip with more "horsepower". If I had to do it again, I would have picked a processor that had everything I needed in one chip.

Hi Vladimir

Frame buffer is a graphic image in RAM before writing it out the LCD. I haven't really got any links, but, this one I got by a search
http://people.ece.cornell.edu/land/c.../s1999/joelee/

It will give you an idea.

Jerson