A multi processor PIC computer :-)

ftp://panteltje.com/pub/multi_processor_PIC_LED_color_controller_hardware_img_2002.jpg

channels.

Don't need use so high a frequency for LEDs?

I repaired a cricket ball tosser recently, the controller box had two PIC chips in it, there was no manual so I have no idea how they split the work between them. Perhaps it's easier than running multitasking OS in the PICs?

Grant.

ftp://panteltje.com/pub/multi_processor_PIC_LED_color_controller_hardware_img_2002.jpg

channels.

blue.

Using multiple PICs usually is an indication of poor design abilities. I guess Jan is just phreaking to get it working with multiple PICs. A sensible piece of hardware uses a micro with multiple PWM outputs.

re PWM channels.

ves blue.

cope,

....

rk

PICs?

Yes, it is in this case.

However, I am involved in a project where two micros are cheaper than one. Due to the large pin count of the single micro, there are lots of unnecessary resources/costs to be removed by two smaller micros. It will be a 15% to 20% cost reduction.

PWM channels.

blue.

Every other programmable core on the PCB is a headache for the development, manufacturing and support. There will be additional programming operations. There will be inevitable version conflicts. There will be a lot of overhead on defining and maintaining the communication protocol between the cores.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

....

ware PWM channels.

rives blue.

s,

scope,

.......

PIC

work

he PICs?

That's true. But the cost saving can justify the extra step.

As part of the manufacturing process, a programmer will be loaded into micro A. Micro A will program micro B. The application will then be reloaded on micro A and retest the whole board. Micro A is USB capable. The whole process can be run in a shell script. No point and click. No operator interventions.

On a sunny day (Thu, 10 Jun 2010 00:29:54 +1000) it happened Grant wrote in :

ftp://panteltje.com/pub/multi_processor_PIC_LED_color_controller_hardware_img_2002.jpg

channels.

blue.

True, but it runs 64 MHz clock, I think I selected the biggest divider :-) (Not sure, actually).

You need a bit of a stack space for that. In this case I need 3 hardware PWM generators. The Microchip site lists a few PICs that have 3, but those are not DIL. I like the DIL packages, as it allows me to make proto types without having to make boards or have boards made. Easier to change things. And at less then 2 $ who cares 1 PIC for 5$, or 3 of 2 $, in small quantities. If somebody needs a million controllers then I will look again :-)

The idea of assigning processors to different tasks, as processors are so cheap, makes a lot of sense to me. In our nervous system many things are autonomous too, think reflexes. I use a very simple system, the master sends serial data on the TX output, all the slaves listen on that wire, direct connection. Commands have the form of GnnnLF for nnn is 0-255 to set green, RnnnLF to set red.

You can at least address 26 x 2 (upper and lower case) controllers that way. Software is largely the same too, just change a few characters.

On a cloudy day (Wed, 09 Jun 2010 16:20:10 GMT) it happened a complete idiot cried:

What a lot of bull excrement. You keep repeating that mantra over and over again, probably because you once terribly failed using even ONE PIC.

On a sunny day (Wed, 9 Jun 2010 10:06:10 -0700 (PDT)) it happened linnix wrote in :

SYNTAX ERROR

Exactly, and availability, I have many of these PICs, why order a rare beast with an unpleasant package all the way from the US if I can grab these from my drawer, and use my existing source files, and programmer soft.

The 'clever' way to do this would be a small FPGA, as it can do the ethernet RX part, and as many PWM outputs as you like. But I would have to have a board made, so this is many times cheaper. In large quantities the FPGA *might* be cheaper. I can test that on a spartan 2 here, but now I have a nice box and it is all working NOW.

On a sunny day (Wed, 09 Jun 2010 12:30:46 -0500) it happened Vladimir Vassilevsky wrote in :

Well, I have more then 1000 soft version out in the public domain ONLY. I think I have a good system, never a problem.

Strange I never noticed that :-)

You are a bit weak on networking right?

On a sunny day (Wed, 9 Jun 2010 10:38:35 -0700 (PDT)) it happened linnix wrote in :

Exactly, all scripts in Linux, and my own programm soft and hardware too. Takes a few *seconds* to make a change.

ftp://panteltje.com/pub/multi_processor_PIC_LED_color_controller_hardware_img_2002.jpg

Not necessarily. If, for instance, I need a PIC micro with two UARTS I have to make a choice. Either using a big, expensive one with two UARTS or using a PIC with one UART program a second in software or use a second PIC for only the UART. Skills are not the only limits. Time and money also are.

petrus bitbyter

That only works for very high volume products. And how about field updates?

ard=3D

ard=3D

t d=3D

PIC=3D

ler=3D

the=3D

to=3D

wo =3D

he =3D

in t=3D

s.

lots

We can send out a 512M flash drive with everything on it. To be more specific, Micro A is Atmega32u2 and Micro B is LPC1111. The AVR will program the ARM using SDW (Serial Debug Wire). Actually, the AVR can just toggle the ARM I/Os using SDW without programming it, but the application codes would be more complicated (including all SDW codes).

So far, I have GCC 4.3 working. Namely, 16K AVR (At90usb162) and Cortex-M0 assembler.

With GCC 4.5, both should be supported fully.

I will post the compilers later.

ftp://panteltje.com/pub/multi_processor_PIC_LED_color_controller_hardware_img_2002.jpg

channels.

blue.

make boards or have boards made.

cheap, makes a lot of sense to me.

I've just started using PICs, programmed enough (RTC, HD44780 LCD module controller, multitasking timebase) to know they're okay for what I want. I return to microcontrollers for first time since '93 when PICs were becoming popular but I was using 'HC05 series controllers (C8, J2, K1). So I've seen the RISC and can get the assembler to put multi-module code where I expect it now.

Yet to do user input, I'm more interested in standalone operation than serial interface, so not done rs232 or inter-chip comms yet.

So many things I'd like to try :) Even bought a 192x128 LCD graphics display to try driving one day -- the sort without a char gen, so I'd have to work in a char pattern memory for text on that too. Done that back in '80s with little 8085 box, in assembler.

Grant.

On a sunny day (Thu, 10 Jun 2010 07:39:58 +1000) it happened Grant wrote in :

There are a few PIC project on my site:

I could not write the soft without the serial interface. It is the first thing I always get working, plus some routines to print 8 bits, 16 bits and sometimes 32 bits numbers as ASCII to the RS232. So I can debug my programs, see what is happening. Also I always add test commands, for example 'b' to print a buffer, things like that.

When starting a new project that basic code is cut and paste, including the chip initialisation. Speeds up thing a thousand times. The scope_pic project has my own character generator in it:

Well, the mplab IDE for chips with builtin ICE support id really easy, windoze only, but I run both 'doze and Linux here so that's not an issue.

Oh, sure, BTDT way back -- but this time around I start from scratch.

Wrote my own LCD module driver as most software I saw out there was crap, copies of some old application note. Also found that Microchip appnote software is not solid code either, useful in parts as a guide, but not directly usable :(

that.

chip initialisation.

Yes, I've got my basic chip startup done, but since I run interrupt based timing the IDE craps out once I get my 'OS' going -- same thing happened with stuff I worked on couple decades back. ICE was only good for taking activity traces to work out what happened -- no point single stepping.

Instead, one does a breakpoint stop in top level code and examines memory.

Or, run a debug terminal, like what you're doing. I haven't made one yet.

I'd like to find my old code, port some of it -- backup of floppies buried on a CD somewhere, I hope...

Grant.

ftp://panteltje.com/pub/multi_processor_PIC_LED_color_controller_hardware_img_2002.jpg

channels.

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

ftp://panteltje.com/pub/multi_processor_PIC_LED_color_controller_hardware_img_2002.jpg

channels.

blue.

Use the Ethernet port for your interprocessor communications. Using its transformer coupling, all the real work is done.

I/O is the problem.

ftp://panteltje.com/pub/multi_processor_PIC_LED_color_controller_hardware_img_2002.jpg

channels.

blue.

Well, unless you need to guarantee tight timing, in which case the real work may be just beginning.

Best regards, Spehro Pefhany