A multi processor PIC computer :-)
in [Design]
|
Prev: re Goodbye to an era
Next: RF cable connection to board
From: Vladimir Vassilevsky on 10 Jun 2010 12:33 Spehro Pefhany wrote: > On Thu, 10 Jun 2010 08:12:20 -0700, John Larkin > <jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote: > >>Programming will become the biggest overhead. I hate to say this, but >>we need something like LabView, basically a block diagram compiler, to >>do uP control functions, rather than hacking C every time. It would >>probably be a gui C pre-processor. GUI code generation tools are great until you stay within the area of solutions provided by the tool. As soon as you need something even slightly different, the GUI tool becomes a major problem rather then help. Paradoxically, the more universal is the GUI tool, the harder are the limitations. > Aside from the astronomical price, what do you have against MATLAB? "Matlab does all thinking for us" (TM) "If it is not in MatLab, there is no way to do it". "I am not asking how to do it. I am asking how to do it in MatLab" Seen a lot of that. > You can generate C code or synthesizable HDL, and practically all the > newly minted EEs know how to use it. Yes, and those EEs are completely helpless without MatLab, fancy JTAG simulators, logic analysers and other shiny toys. Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com
From: Nico Coesel on 10 Jun 2010 12:57 Spehro Pefhany <speffSNIP(a)interlogDOTyou.knowwhat> wrote: >On Wed, 09 Jun 2010 22:30:56 -0500, the renowned >"krw(a)att.bizzzzzzzzzzzz" <krw(a)att.bizzzzzzzzzzzz> wrote: > >>On Wed, 09 Jun 2010 18:28:43 -0700, John Larkin >><jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote: >> >>>On Wed, 09 Jun 2010 14:18:42 GMT, Jan Panteltje >>><pNaonStpealmtje(a)yahoo.com> wrote: >>> >>>>A multi processor PIC computer :-) >>>> ftp://panteltje.com/pub/multi_processor_PIC_LED_color_controller_hardware_img_2002.jpg >>>> >>>>I modified my LED color controller a bit so it has 3 independent hardware PWM channels. >>>>One PIC is the master, is controlled via ethernet, and its PWM unit drives blue. >>>>It forwards the other color levels via very fast RS232 to 2 other PICs, >>>>one does the red pwm, and the other one does the green PM thing. >>>> >>>>There are 4 clocks in this system, 25 MHz for the ethernet controller, >>>>and 3 x 64 MHz internal clocks for the PICs. >>>> >>>>I was watching the LED strips for interference, you can see it on the scope, >>>>but not in the light output.... >>>>PWM is about 15 kHz, 8 bits resolution, probably with harmonics up to...... >>>>Anyways, multi-processor PIC is here :-) >>>> >>> >>>We just got the first bare board of a VME module that has 13 ARM >>>processors on it, one per i/o channel and one overall manager. The >>>channels are electrically isolated, so we couldn't use a >>>multi-processor chip or a single higher-power uP. An ARM with flash, >>>mux'd ADC, DAC, parallel ports, SPI, timers UARTS... is a lot of stuff >>>for $4. We're throwing away the Ethernet port! >> >>Use the Ethernet port for your interprocessor communications. Using its >>transformer coupling, all the real work is done. > >Well, unless you need to guarantee tight timing, in which case the >real work may be just beginning. Google for 'ethercat' -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico(a)nctdevpuntnl (punt=.) --------------------------------------------------------------
From: Paul Keinanen on 10 Jun 2010 16:37 On Wed, 09 Jun 2010 23:36:45 -0400, Spehro Pefhany <speffSNIP(a)interlogDOTyou.knowwhat> wrote: >On Wed, 09 Jun 2010 22:30:56 -0500, the renowned >"krw(a)att.bizzzzzzzzzzzz" <krw(a)att.bizzzzzzzzzzzz> wrote: >>Use the Ethernet port for your interprocessor communications. Using its >>transformer coupling, all the real work is done. > >Well, unless you need to guarantee tight timing, in which case the >real work may be just beginning. The old 10base2/5 Ethernet was very bad (also 10/100 baseT _hubs_), if you tried to run peer-to-peer communication, due to collisions and the large backoffs. However, with 10/100baseT switches, this is not much an issue. Running traditional master/slave half duplex protocols (such as Modbus/TCP) on dedicated networks (even 10base2/5), the response times are very predictable.
From: Spehro Pefhany on 10 Jun 2010 16:58 On Thu, 10 Jun 2010 23:37:11 +0300, Paul Keinanen <keinanen(a)sci.fi> wrote: >On Wed, 09 Jun 2010 23:36:45 -0400, Spehro Pefhany ><speffSNIP(a)interlogDOTyou.knowwhat> wrote: > >>On Wed, 09 Jun 2010 22:30:56 -0500, the renowned >>"krw(a)att.bizzzzzzzzzzzz" <krw(a)att.bizzzzzzzzzzzz> wrote: > >>>Use the Ethernet port for your interprocessor communications. Using its >>>transformer coupling, all the real work is done. >> >>Well, unless you need to guarantee tight timing, in which case the >>real work may be just beginning. > >The old 10base2/5 Ethernet was very bad (also 10/100 baseT _hubs_), if >you tried to run peer-to-peer communication, due to collisions and the >large backoffs. > >However, with 10/100baseT switches, this is not much an issue. > >Running traditional master/slave half duplex protocols (such as >Modbus/TCP) on dedicated networks (even 10base2/5), the response times >are very predictable. Have you ever measured the latency and jitter of a simple switch?
From: krw on 10 Jun 2010 20:55
On Wed, 09 Jun 2010 21:14:38 -0700, John Larkin <jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote: >On Wed, 09 Jun 2010 22:41:33 -0500, "krw(a)att.bizzzzzzzzzzzz" ><krw(a)att.bizzzzzzzzzzzz> wrote: > >>On Wed, 09 Jun 2010 23:36:45 -0400, Spehro Pefhany >><speffSNIP(a)interlogDOTyou.knowwhat> wrote: >> >>>On Wed, 09 Jun 2010 22:30:56 -0500, the renowned >>>"krw(a)att.bizzzzzzzzzzzz" <krw(a)att.bizzzzzzzzzzzz> wrote: >>> >>>>On Wed, 09 Jun 2010 18:28:43 -0700, John Larkin >>>><jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote: >>>> >>>>>On Wed, 09 Jun 2010 14:18:42 GMT, Jan Panteltje >>>>><pNaonStpealmtje(a)yahoo.com> wrote: >>>>> >>>>>>A multi processor PIC computer :-) >>>>>> ftp://panteltje.com/pub/multi_processor_PIC_LED_color_controller_hardware_img_2002.jpg >>>>>> >>>>>>I modified my LED color controller a bit so it has 3 independent hardware PWM channels. >>>>>>One PIC is the master, is controlled via ethernet, and its PWM unit drives blue. >>>>>>It forwards the other color levels via very fast RS232 to 2 other PICs, >>>>>>one does the red pwm, and the other one does the green PM thing. >>>>>> >>>>>>There are 4 clocks in this system, 25 MHz for the ethernet controller, >>>>>>and 3 x 64 MHz internal clocks for the PICs. >>>>>> >>>>>>I was watching the LED strips for interference, you can see it on the scope, >>>>>>but not in the light output.... >>>>>>PWM is about 15 kHz, 8 bits resolution, probably with harmonics up to...... >>>>>>Anyways, multi-processor PIC is here :-) >>>>>> >>>>> >>>>>We just got the first bare board of a VME module that has 13 ARM >>>>>processors on it, one per i/o channel and one overall manager. The >>>>>channels are electrically isolated, so we couldn't use a >>>>>multi-processor chip or a single higher-power uP. An ARM with flash, >>>>>mux'd ADC, DAC, parallel ports, SPI, timers UARTS... is a lot of stuff >>>>>for $4. We're throwing away the Ethernet port! >>>> >>>>Use the Ethernet port for your interprocessor communications. Using its >>>>transformer coupling, all the real work is done. >>> >>>Well, unless you need to guarantee tight timing, in which case the >>>real work may be just beginning. >> >>I thought we were just interfacing between multiple processors. ...and John >>doesn't like RTOSs, so... > >We're using some Analog Devices logic isolator things, SPI >communications between the master and the 12 slaves. We're evaluating >the drop-in-replacement SiLabs parts, about half the price. We use the ADI parts for this too, but IIRC they're kinda spendy. If I had an Ethernet, free, I'd try to get them to use it. >The Ethernet stack would be a lot of overhead here, I think. We didn't find the one on the PIC too hard. I think it was pretty much drop-in. No RTOS there either. ;-) There were some issues with signal polarities that weren't supposed to be there. Some routers would barf, but that was fairly easy to correct once the problem was identified. >I don't have anything against RTOSs, having written three myself, but >if we had a zillion cores on a chip we wouldn't need to context >switch. I/O still has to be managed. >Here's the board. > >ftp://jjlarkin.lmi.net/V220.gif > >The 12 ARMs run down the middle. To their right are the data >isolators, regulators, jtag connector, and dc/dc converter. The analog >stuff is to the left. > >This is a 12-channel 4-20 mA sort of i/o board. How many I/O per channel? |