A multi processor PIC computer :-)
in [Design]
|
Prev: re Goodbye to an era
Next: RF cable connection to board
From: John Larkin on 10 Jun 2010 00:14 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. The Ethernet stack would be a lot of overhead here, I think. 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. 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. John
From: Jan Panteltje on 10 Jun 2010 03:46 On a sunny day (Wed, 09 Jun 2010 18:28:43 -0700) it happened John Larkin <jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote in <sef016hckjmtpgn2ttno4s7mrotnvfv868(a)4ax.com>: >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! > >Multiple CPUs on a chip will be common in all systems some day soon, >embedded included. We don't need no stinkin' RTOS... just run >bare-metal code on each CPU. > >John Yes, although having different chips (as opposed to multicore in one package) has in some cases the advantage that you can put the processor where you want it, next to the I/O, greatly reducing wires. The new LED strips (strings of up to 90 RGB LEDs) already have a SPI controller for each 3 LEDs *in* the strip, all addressable. No high switching currents, more effects, less RFI: http://www.signleds.nl/index.php?item=rgb-ledstrips&action=page&group_id=40&lang=NL Bottom page, see the moving color animation. I dunno what processor it is, or perhaps it is an ASIC, but 'on the spot' computing is here in large quantities. Simple few wires serial connection connects it all. Robotics, processor in each leg... 'cybernetics' I like that word, it got a bit forgotten, multi-CPU sort of gives those sort of things a boost.
From: Spehro Pefhany on 10 Jun 2010 09:51 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... Well, the isolation implies something like a data acquisition system to me, and usually you need to know rather closely when each data point was acquired. If synchronization has to be better than a few milliseconds (maybe 100x that if a PC and Windows is involved), Ethernet can add interesting dimensions to the problem.
From: John Larkin on 10 Jun 2010 11:12 On Thu, 10 Jun 2010 07:46:01 GMT, Jan Panteltje <pNaonStpealmtje(a)yahoo.com> wrote: >On a sunny day (Wed, 09 Jun 2010 18:28:43 -0700) it happened John Larkin ><jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote in ><sef016hckjmtpgn2ttno4s7mrotnvfv868(a)4ax.com>: > >>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! >> >>Multiple CPUs on a chip will be common in all systems some day soon, >>embedded included. We don't need no stinkin' RTOS... just run >>bare-metal code on each CPU. >> >>John > >Yes, although having different chips (as opposed to multicore in one package) >has in some cases the advantage that you can put the processor where you want it, >next to the I/O, greatly reducing wires. >The new LED strips (strings of up to 90 RGB LEDs) already have a SPI controller >for each 3 LEDs *in* the strip, all addressable. >No high switching currents, more effects, less RFI: > http://www.signleds.nl/index.php?item=rgb-ledstrips&action=page&group_id=40&lang=NL >Bottom page, see the moving color animation. >I dunno what processor it is, or perhaps it is an ASIC, but 'on the spot' computing is >here in large quantities. Yeah, it's getting outrageous. Pretty soon simple stuff like voltage regulators will be uPs. Processors will start replacing opamps. 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. John
From: Spehro Pefhany on 10 Jun 2010 11:21
On Thu, 10 Jun 2010 08:12:20 -0700, John Larkin <jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote: >On Thu, 10 Jun 2010 07:46:01 GMT, Jan Panteltje ><pNaonStpealmtje(a)yahoo.com> wrote: > >>On a sunny day (Wed, 09 Jun 2010 18:28:43 -0700) it happened John Larkin >><jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote in >><sef016hckjmtpgn2ttno4s7mrotnvfv868(a)4ax.com>: >> >>>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! >>> >>>Multiple CPUs on a chip will be common in all systems some day soon, >>>embedded included. We don't need no stinkin' RTOS... just run >>>bare-metal code on each CPU. >>> >>>John >> >>Yes, although having different chips (as opposed to multicore in one package) >>has in some cases the advantage that you can put the processor where you want it, >>next to the I/O, greatly reducing wires. >>The new LED strips (strings of up to 90 RGB LEDs) already have a SPI controller >>for each 3 LEDs *in* the strip, all addressable. >>No high switching currents, more effects, less RFI: >> http://www.signleds.nl/index.php?item=rgb-ledstrips&action=page&group_id=40&lang=NL >>Bottom page, see the moving color animation. >>I dunno what processor it is, or perhaps it is an ASIC, but 'on the spot' computing is >>here in large quantities. > >Yeah, it's getting outrageous. Pretty soon simple stuff like voltage >regulators will be uPs. Processors will start replacing opamps. > >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. > >John > Aside from the astronomical price, what do you have against MATLAB? You can generate C code or synthesizable HDL, and practically all the newly minted EEs know how to use it. |