![](templates/subSilver/images/CCSLogo.jpg) |
![CCS C Software and Maintenance Offers](templates/subSilver/images/forumAd6.jpg) |
View previous topic :: View next topic |
Author |
Message |
stoyanoff
Joined: 20 Jul 2011 Posts: 375
|
Many interfaces on one controller simultaneously |
Posted: Thu Apr 02, 2015 11:56 am |
|
|
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! |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9176 Location: Greensville,Ontario
|
|
Posted: Thu Apr 02, 2015 1:42 pm |
|
|
'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 |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19375
|
|
Posted: Thu Apr 02, 2015 2:26 pm |
|
|
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.... |
|
![](templates/subSilver/images/spacer.gif) |
asmboy
Joined: 20 Nov 2007 Posts: 2128 Location: albany ny
|
|
Posted: Fri Apr 03, 2015 11:00 am |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19375
|
|
Posted: Sat Apr 04, 2015 12:15 am |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
jgschmidt
Joined: 03 Dec 2008 Posts: 184 Location: Gresham, OR USA
|
|
Posted: Sat Apr 04, 2015 11:21 am |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
asmboy
Joined: 20 Nov 2007 Posts: 2128 Location: albany ny
|
|
Posted: Sat Apr 04, 2015 6:44 pm |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
|
|
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
|