ftp://panteltje.com/pub/multi_processor_PIC_LED_color_controller_hardware_img_2002.jpg
PWM channels.
blue.
I thought we were just interfacing between multiple processors. ...and John doesn't like RTOSs, so...
ftp://panteltje.com/pub/multi_processor_PIC_LED_color_controller_hardware_img_2002.jpg
PWM channels.
blue.
I thought we were just interfacing between multiple processors. ...and John doesn't like RTOSs, so...
ftp://panteltje.com/pub/multi_processor_PIC_LED_color_controller_hardware_img_2002.jpg
PWM channels.
blue.
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
On a sunny day (Wed, 09 Jun 2010 18:28:43 -0700) it happened John Larkin wrote in :
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:
ftp://panteltje.com/pub/multi_processor_PIC_LED_color_controller_hardware_img_2002.jpg
PWM channels.
blue.
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.
it,
computing is
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
it,
computing is
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.
On a sunny day (Thu, 10 Jun 2010 08:12:20 -0700) it happened John Larkin wrote in :
I think there have been many attempts to make something like that. For me it is like this:
*If* I can formulate the problem correctly, then sort of split it into steps, leading to a solution, then what method is used to implement those steps is just like choosing a tool, a pic, a hammer, or a screwdriver.. For some a graphical way to 'assemble' the solution path would be easier then in a text form, but for some it wont. Maybe the desire in people exists to make it all super simple, like pressing a button (on a mouse), or asking verbally 'I want xyz'. When that was to really happen what would happen to humanity if a large EMP or solar flare came and all calculators and PCs stopped working, and nobody knew any basic math, or programming anymore, just totally lost everybody (no GPS) too.... OTOH remember doing a 'slide rule test' in my school days, no calculators... When calculators came people wondered if people would no longer be able to do real math themselves. So maybe it will all not be so bad. But I would not want he graphical system.. take for example the click bar in my browser, there are now so many 'fast access' bookmarks in it that all icons are so small and look the same, that it has become next to useless, and it would be much faster to just type the URL then hovering to mouse over all the menus or icons to see in the window what URL it refers too. Language, is a very powerful thing. Kiddy stuff like walking in the supermarket and pointing to the chocolate 'mommy I want this', well, is limited by its nature. It may lead to some top heavy stuff like MS windows. C, is a very powerful language. If you just look at any C function, passing values as arguments,my_idea(int my_input, int *the_output) { /* do something */
} is probably the simplest way to divide problem up in to steps to solve it. I often start wring code like this:
my_function(...inputs, ...outputs) { // do this // do that // do more }
and then fill in the steps More powerful even when you use pointers (to data).
C++, I do not understand that, I think the guy who invented it could not program, but anyways, C++ adds some abstraction to it, but makes that so complicated that I want to avoid it. Gave birth to that same MS crap...
In the end the language does not matter, as long as it can be extended, C can, you can ask for water in German, Dutch, English, Spanish, Chinese, French, whatever, same water, I can only say learn C, it will get you a long way. I looks like many new programming languages are born each year, I do not bother to learn those. I know C, and shell scripting on an Unix system I just about can hack that, combining applications with it is also very powerful. I did not believe that until somebody wrote dvdwizard in bash! That is a complete DVD authoring suite, automatic! Just a few lines combining all the existing tools. Do that in a GUI form? That would be very very difficult. Like I said, with thousands of different commands on a Linux system, and the trend is towards chips running Linux anyways, the menus would be horrible to traverse, and no place for all the icons representing those programs. Much easier to type what you want: 'mommy I want chocolate', can already be said *before* the supermarket is entered.
Do I make sense? I do to me, well that is a plus anyways. LOL
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.
"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.
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
ftp://panteltje.com/pub/multi_processor_PIC_LED_color_controller_hardware_img_2002.jpg
PWM channels.
blue.
Google for 'ethercat'
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?
ftp://panteltje.com/pub/multi_processor_PIC_LED_color_controller_hardware_img_2002.jpg
PWM channels.
blue.
scope,
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.
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/O still has to be managed.
How many I/O per channel?
ftp://panteltje.com/pub/multi_processor_PIC_LED_color_controller_hardware_img_2002.jpg
PWM channels.
blue.
scope,
Timestamp?
ftp://panteltje.com/pub/multi_processor_PIC_LED_color_controller_hardware_img_2002.jpg
PWM channels.
drives blue.
scope,
to......
Each channel has just two pins. Any channel can
source 0-24 mA or 0-20 volts, CV/CC
Regulate an external current loop, 0-32 mA
Measure an external current loop, 0-32 mA
Measure voltage (actually, it always measures current and voltage)
Be an open.
Be a short.
It's for testing big control systems, faking out a process, before the control system is connected to a lot of expensive machinery. The first app is a big gas turbine generator, where they want to prove out the control system while the machinery is being built.
John
ftp://panteltje.com/pub/multi_processor_PIC_LED_color_controller_hardware_img_2002.jpg
hardware PWM channels.
drives blue.
scope,
to......
Doesn't sound like a lot of data or computation. Wouldn't it have been simpler to isolate between the DAC and the CPU? That is, one processor?
Each little CPU has a multiplexed ADC and a DAC in it, and the SPI stuff, and a bunch of parallel ports. That's cheaper than putting a separate ADC and DAC and ports up there. The CPU part is essentially free. We use the individual, isolated CPUs to do the closed-loop control, measurement, protections, and SPI up/down. The local control loops will each run at 50 or 100K hits/second. If we did SPI up/down to a single CPU, it couldn't run that fast, and the SPI traffic would get huge if we tried.
It is a little weird to think of getting a 100 MHz, 32-bit ARM CPU, with RAM and flash, essentially for free when you buy the ADC and DAC.
John
44MHz, aren't they? Or have you found a new one?
We're using the 80-pin LPC1758 in the channels. I think it runs at 100 MHz max.
================
The LPC1758/56/57/54/52/51 operate at CPU frequencies of up to 100 MHz. The LPC1759 operates at CPU frequencies of up to 120 MHz. The ARM Cortex-M3 CPU incorporates a 3-stage pipeline and uses a Harvard architecture with separate local instruction and data buses as well as a third bus for peripherals. The ARM Cortex-M3 CPU also includes an internal prefetch unit that supports speculative branching. The peripheral complement of the LPC1759/58/56/54/52/51 includes up to
512 kB of flash memory, up to 64 kB of data memory, Ethernet MAC, USB Device/Host/OTG interface, 8-channel general purpose DMA controller, 4 UARTs, 2 CAN channels, 2 SSP controllers, 2 2 SPI interface, 2 IC-bus interfaces, 2-input plus 2-output I S-bus interface, 6 channel 12-bit ADC, 10-bit DAC, motor control PWM, Quadrature Encoder interface, 4 general purpose timers, 6-output general purpose PWM, ultra-low power Real-Time Clock (RTC) with separate battery supply, and up to 52 general purpose I/O pins.==============
That is truly insane for $6 or so. One of the NXP arms is under $1.
John
Oh yes, nice looking chip, will be using it myself soon.
Sorry, I thought you were using ADUC7000 series for some reason. They do match the description of a good ADC and DAC with a free ARM attached, although not such a good one.
[...]
Yes, I see your point. That is amazing.
Have something to add? Share your thoughts — no account required.
Ask the community — no account required