Many interfaces on one controller simultaneously

[stoyanoff]

Greetings! I`m going to make a small device with communication interfaces. I want to use pic18F66J60. So there will be a ethernet, SPI to CAN controller, UART to GPRS module and I2C to EEPROM chip. I`m going to use CCS TCPIP stack. Is it possible all these interfaces to run simultaneously? Am I going to have problem with any? I`m concern about SPI and I2C...
Thanks!

[temtronic]

'simultaneously', not , technically not possible as PICS only have one ALU( like all the rest...)

Now if the PIC is fast enough ,and it has enough hardware and and enough RAM for buffers, and you use ISRs properly you'll 'simulate' ,'simultaneous' operation without any concerns

This is how PCs, MACs and 99.99999% of the computer in the World operate and 'appear' to be doing several things at once like 'being on the web', running a spreadsheet, playing solataire and compiling PIC programs.

You'll have to read a lot, decide if the PIC has the hardware resources to do the tasks, has the speed, etc. My 'hunch' is yes....

hth
Jay

[Ttelmah]

And this of course is where interrupt driven buffering is vital.

In the real world, interfaces themselves won't actually be 'simultaneous'. Two serial ports both receiving data 'at the same time', will always have one getting a complete character fractionally ahead of the other. The interface itself has a small amount of hardware buffering, so the interrupt services the first one to receive a character, and then a moment later the second. Meanwhile the hardware buffering handles keeping on receiving the next character on each.

It does become vital to ensure that each interrupt just does the job of receiving/sending a character, and gets out again immediately, so that there is time for the other interfaces to be serviced, and that the main code, can 'by and large' keep up with the work needed on the data.

The original PC, and the later PC-AT, both had single core processors, yet merrily handled multiple serials, displays, keyboard, mouse, disk drives, printer etc. etc.. However you also saw when programs were badly written, and 'hogged' time, blocking events, then things went amiss....

[asmboy]

a couple of tips where lots of potentially overlapping I/O is concerned.

1- avoid using INTS wherever you can-and instead POLL by design when possible.
2- use Handshaking to control external input that can be "held" and accessed
at your convenience.

3- minimize the code in your INT handlers to as few instructions as possible. Never do any math beyond quick simple integer stuff if it can be avoided. Use flags for MAIN() to do heavier computation.

4- though it sounds counter intuitive- if using RS232 the LOWER the baud rate - and always using an INT handler for receive -
will be better for your program.

[Ttelmah]

It does get complex to work out the best routes.

However (for example), I have one system where there are two RS232's at 9600bps from internal UART's, and then another at 9600bps on an external UART, as well as a number of timing tasks.
Because of the timing tasks, there has to be a tick interrupt, and it has to be quite fast.
I used the solution to make the 'tick' occur at 1mSec, and have it service _all_ the other devices. It is very easy to just poll each of the UART interrupts in this timer, This way there is only one set of interrupt latency (and the time this wastes), for a total of 7 different jobs, but all are serviced fast enough to ensure that nothing is missed.

It's very much down to careful design and understanding the costs (in time and code) associated with approaches.

[jgschmidt]

The TCP/IP stack has it's own internal routines for using UART and SPI resources of the PIC. Since the stack is based on the original Microchip stack, there is a lot of direct manipulation of the registers, as opposed to using the built-in CCS routines. Using the TCP/IP librarires by themselves works fine, but when you start adding others, you need to check for overlaps and inconsistencies in function.

Also be aware that not all SPI devices play well together. In my particular situation I was able to use the ENC28J60 and serial memory on the same SPI interface OK. When I added an LCD with SPI interface to the same port, nothing worked. Apparently the CS line didn't completely turn off the LCD interface and it would try to reply to the memory requests. Once I moved it to it's own SPI port everything worked fine. Fortunately there were two SPIs available.
_________________
Jürgen
www.jgscraft.com

[asmboy]

in every case i have ever designed for-including SPI LCD's- i have never had to do more than allocate a unique CS/NOT_CS control pin for each device -- not a whole separate instance of the SPI port-- while using a common clock and data_out line for ALL spi devices--all on the same two pic pins. any issue with mis-addressing must be linked to the CS line management.