Sharing Memory Between Processors? 2

[eromlignod]

Hi guys:

I'm an ME and I have an application where I'd like to use two Basic Stamp microcontrollers working together. One is the main processor that runs the show and does calculations; the other is a dedicated slave that constantly distributes a series of 16-bit numbers to
various devices in a continuous, timed loop. The first processor calculates what these numbers are based on feedback sources.

The reason I use a dedicated second processor is that its stream of numbers can't be interrupted...it has to provide a continuous series of values on a clock. The problem is that I can't even interrupt it long enough to pass numbers to it from the other processor without messing up the sequence.

What I'd like to try (if possible) is to share the same memory between the two MCU's. So the first Basic Stamp is calculating values and storing them to memory and the second Basic Stamp is using them as if they were in its own memory bank simply by referring to a value by variable name (or address??...I don't know).

Is this possible and, if so, what would be a good way of going about it? I'm also open to alternate suggestions to solve the problem including using a different processor (I would like to avoid investing in another development kit or chip burner if possible though).

Thanks for any help you can provide.

Don

 

[MacGyverS2000]

If you don't have enough time to ship messages to the main processor, how do you expect to have time to write them to memory? UARTs are typically interrupt driven, so you drop a number into a register and let the hardware take care of sending the data out... takes all of a handful of cycles to implement.

You're looking for dual-port RAM, but I doubt you have the pins/timing necessary to implement such a beast with a Stamp. the cheap method is flags/tokens with standard memory, but you already said you don't have enough time to do any of that.


Dan - Owner

http://www.Hi-TecDesigns.com

 

[nbucska]

I would use a cheap PC compatible processor from
BAGOTRONIX or JKMICRO (add

http://www...com)

for about the same price but MUCH faster, magnitude of orders more memory etc. You can use any PC language: C,C++, ( GW- TURBO, POWER-,QUICK- etc ) BASIC, FORTRAN,Pascal, Assembly, etc.

What is the clock-rate you have to syncronize with?
What is the algorithm of the number generation ?









----------------------------
Please read FAQ240-1032
My WEB: <

http://geocities.com/nbucska/>

 

[richs]

Hiya-

Much as I hate to say it, the PIC microcontrollers are not
the best choice for a shared memory application. The series
that I am familiar with does not lend itself well to shared
memory (external) to itself. The PICs that I'm familiar
with usually require the setting of external address lines
seperately under software control which imparts quite a
bit of overhead (time) to the operation. I think an
examination of some of the ARM processors might be more
interesting towards a shared memory application.

If your application can pass single bytes of information
between the calculating processor and the sending processor,
then you don't have to worry about "atomic" functionality.
If you have to pass multibyte (or multiword data if the
external memory is as wide as the data unit) then you
have to worry about fully atomic functionality and this
is usually acomplished by semiphores in sofware (again,
high overhead). Consider the situation of a one
processor sending two bytes of information, and the values
of the two bytes increments from 0x00ff to 0x0100. If
the two processors are out of phase, the "receiving"
processor could read the high byte and see 0x01, and
the low byte as 0xff, yielding a reading of 0x01ff, not
the desired 0x0100. So, oftentimes, a software handshake
called a "semiphore" is included for this sort of
operation.

Another possiblity is to use a more primitive, or closer
to the machine language form of software development. As
I understand it, the Basic Stamps are an interpretive
processor. In other words, the software that you write is
converted (sometimes) into an intermediate language that
will take the processor of choice many instruction cycles
to decode this intermediate language, often times at
quite a performance degradation. This MIGHT allow both
processors (mainly the "receiving" processor) time enough
for it to do it's job.

Yet another alternative, is to use what is called a FIFO
memory (First In First Out). This type of memory typically
is used as a "data rubber band" to pass data between
two devices. The "calculating" processor passes the
"cooked" data to the fifo. The "receiving" device sees
that there is data in the fifo (usually a hardware pin),
and reads the data. Meanwhile (if the fifo does not
fill up completely), the calculating device can pass
data into the fifo completely independantly of the
receiving device. Again, assuming that the receiving
device is fast enough to keep up with the data.

Without knowing the design goals, one possible architecture
that I might humbly suggest is something like a pair
of PICs (choices might be the 16F877A, been around a long
time, or it's newer brother the 16F888). They both
have "slave data ports" on them. Data could be passed
from the "calculating" processorm, through it's slave
port, into a fifo, to the "receiving" processor which
sends out it's data.

The calculating processor I would suggest, as a real rough
estimate, might be easiest to implement with a "compiled"
basic to reduce software redesign. The "compiled" code
has the software broken down to a series of directly
executed "machine language" code. Most often, much faster
than the "interpreted" code mentioned above.

Many of us code jockies would pick a different language,
such as C, for this, but I think that basic *MIGHT* be
just fine.

For the receiving code, I personally would use machine
language (or it's mnemonic counterpart assembly) for
this as it provides the "fastest" code execution (most
of the time). But this can be quite a learning
exercise for the student.........

Finally, as to debugging. You might find it much faster
to invest in a PAIR of debuggers. PIC ICD2, are about
$150.00 each (there are some 3rd parties that are even
cheaper). If you go the PIC route, then a debugger on
each of the PICs will certianly allow much more
capability. Failing that a single debugger with debugging
process first concentrated on the "computing" processor
filling the fifo. After that gets working properly,
then start debugging the "receiving" side, emptying
the fifo and sending out the appropriate action.

There are many ways to solve the problem set that you have
described, and this is just one way that I would consider
solving the problem. I hope that this little explaination
helps in determining a solution that works for you.

Cheers,

Rich S.

 

[itsmoked]

Lots of good points made so far!

You should describe more of your project to us as then we could give you a much better crafted solution. You haven't said what method your "stream of data" is being sent in.. If it's being sent to various devices why are you not making the other processor 'just another device' and have it collect the data as it is put out by the first processor?

Other than that if you are truly having speed issues and are using a "Basic Stamp" the general answer would be, "well daH!" as they are really not meant for data crunching but for learning and toyish like uses.

If you switch to a "PIC Stamp" that allows C code and runs compiled code you could probably do the whole job with one device.

Using dual port memory is insanely costly and an option of last resort, beating back the wolves of time, type application. Last I looked just the devices were $50 in quantity as they are all fast parts with special features.

Anyhooo explain you app more and we can help more.

Keith Cress
Flamin Systems, Inc.-

http://www.flaminsystems.com

 

[eromlignod]

Well, you will all probably get a good laugh, but I'm trying to make a massive PWM generator. It's a one-up prototype project, so I'm not so much worried about cost as I am about time and learning curves that could add months. I've already got Basic Stamps lying all over the place.

What I need to do is control 256 heaters on independent PWM duty cycles that are adjusted according to temperature feedback. I realize that an FPGA might make more sense, but it's hard to find a development kit that has that much free I/O (most of them tie up a lot of the I/O with peripherals) and I don't have a lot of time to learn it from scratch.

My idea is to connect the FET's that fire the heaters to the outputs of a chain of serial-to-parallel synchronous shift registers (like a CD4094). So it's like one giant shift register with a 256-bit parallel output. I fill it up serially, then strobe the entire number to the output register over and over in a continuous loop. With the right series of numbers I can, in effect, turn each FET on and off as I wish. If I loop through 256 numbers I have a duty cycle resolution of 1 in 256.

If I want the PWM's to be accurate, I can't stop the loop to read thermocouples, calculate errors and adjustments, run the rest of the system, etc. or I might mess up the timing and cause a pause in the outputs.

What I was thinking about was storing the numbers in RAM so that the dedicated PWM engine can simply call them up at will. Another processor does the drudgery of measurements and calculations and writes new values over the data as needed.

It may not be the most efficient solution, but I might be able to get by with what I already have.

Don

 

[nbucska]

Heaters are slow - I would check if it would not be enough
to switch them on-off in increment of 60 Hz cycle
i.e. n on of m cycles. In this case you just need a SSR
-- and you need one anyway but you could save the rest
of the electronics.

I bet, one processor is enough...



----------------------------
Please read FAQ240-1032
My WEB: <

http://geocities.com/nbucska/>

 

[MacGyverS2000]

I would suggest increasing the duty cycle range to seconds rather than milliseconds since they're slow heaters... with proper testing, you should get plenty of resolution and control. Once that's done, you'll have plenty of spare cycles to transfer data back and forth. Sounds to me like this is one of those projects that would benefit from stepping back and looking at it from another viewpoint.


Dan - Owner

http://www.Hi-TecDesigns.com

 

[nbucska]

Sorry - one SSR per heater.

Interpretive BASIC is slow-- but any PC compatible
microcomputer can be programmed in many compiled
BASIC flavors. I often use TURBO-basic, which is
compatible to GWBASIC for simple tasks like this.





----------------------------
Please read FAQ240-1032
My WEB: <

http://geocities.com/nbucska/>

 

[eromlignod]

It would be great to get by with one processor, but where do I find one with at least 256 outputs and 256 inputs?

Don

 

[nbucska]

there is no such animal, i.e. you need 40 to 45 logic
IC-s for address decoding etc.

How big are the heaters, anyway ?


----------------------------
Please read FAQ240-1032
My WEB: <

http://geocities.com/nbucska/>

 

[richs]

Hiya-

O.K. now we have something to work with. As nbucska has mentioned, it might be possible to do it with one processor.

However, I might suggest an alternative to your shift register scheme, if you are building hardware for the FET and have to do a hardware layout anyway.

I would again suggest that a peek at a compiled basic.
Something like Great Cow Basic:

http://gcbasic.sourceforge.net/

I have no experience with this free open source compiler, but it certianly might do the job. You will need a programmer for the PIC, however, I have seen some that can be built on the web. Microchip sells their version of a programmer for under $50.00 that can both be a programmer and for some of the pics, a debugger as well. The IDE software is free.

The reason that I say this is that PICs themselves are MUCH cheaper than the STAMP products. A 28 pin device (for example the 16f686) can be had at Mouser electronics for under $5.00 each in singles quantities. I don't work for either Mouser nor Microchip, so there is no ax to grind.

The 16F686 has quite a bit of I/O available to it. With a tiny bit of thought, one can eliminate the shift register and do the PWM under software control. Alternatively, many of the PICs have a PWM controller built in. However, these are single channel. Smaller PICs (like my favorites the 16F648A and their older brothers, the 16F627(A), and 16F628(A)s are also suitable candidates.

These also have some EEPROM which can be used for configuration information (more on that later).

I would suggest partitioning the 256 heaters that you have to deal with into subsets. Each subset being controlled by a seperate PIC. I would suggest somewhere in the range of 8 to 16 along with the associated FETs to control the heaters. I would suggest that PWM control be done entirely under interrupt control using TIMER 1 for most of the work. I personally would use the serial usart for passing data from the "sending" controller to all of the "receiving" controllers. Data is passed in only one direction from the sender to the receiver. I2C or SDI initerfaces could also be used. The point is that one would want "multidrop" communications. The PIC serial interfaces have a nine bit mode that could be used to determine if the rest of the information is either an address or a value for the address. The "receiving" controllers, I would suggest, POLL their serial interfaces looking for a range of addresses that they would respond to. When the "calculating" controller detects a change in value is needed, then it would send out the new address followed with an 8 bit data value. For example the address could have the ninth bit set, the data have the ninth bit cleared.

Partitioning the hardware into logical "groups" has the added advantage of having spare hardware available. By controlling say 8 or so heaters/board one could have additional hardware built and ready to go if one of the FETs went bad. The board can be programmed for it's range of desired addresses (or one could use dip switches), and plugged in, replacing the defective components at ones leasure.

This, at least at first blush, is how I would attack the problem.

Hope this helps and let us know how the design progresses.

Cheers,

Rich S.

 

[nbucska]

I think we need more info before starting to design.
1.) What is the power of each heater? Volume of heated space and specific heat, if not air.
2.) Required accuracy
3.) Any temp. sensor selected ?
4.) Is this prototype for mass production? How many
needed now and later per year?
5.) Max. distance from controller to heater?
6.) Do you want/can wirewrap it? ( not necessary
a simple design like this doesn't need trial and error.)
7.) and a few more after these were answered....

------------------------------------------------
I know/have TURBO-, QUICK-, POWER- and GWBASIC, the first 3
compiled. All of them would be good enough.




----------------------------
Please read FAQ240-1032
My WEB: <

http://geocities.com/nbucska/>

 

[MikeHalloran]

Do you really need to gather 256 temperature inputs to a central store before deciding on 256 pwm outputs? I.e. is the output of any one channel dependent on inputs other than from the corresponding input channel?

OR, could you e.g. set up 64 Basic Stamps to run 4 channels each, autonomously?



Mike Halloran
Pembroke Pines, FL, USA

 

[VEBill]

Any system with 256 heaters (yikes!) should probably include quite a bit of consideration for failure modes, fail-safe, diagnostic modes, maintenance, etc.

In other words, a large and complicated solution might be much cheaper in the long run than a minimal, simple, elegant solution.

 

[nbucska]

VE1: A star for you...


----------------------------
Please read FAQ240-1032
My WEB: <

http://geocities.com/nbucska/>

 

[MikeHalloran]

There seems to be a general misconception here that a Basic STAMP is slow; it's not. The original version with the slow clock runs at ~2000 instructions/sec, and the instructions are fairly powerful. I think the PC-hosted program loader is actually a compiler, too.

Yeah, it's expensive relative to a bare PIC; not so much relative to a PIC with a development board and a power supply. It's cheaper than anything else if you already have it.








Mike Halloran
Pembroke Pines, FL, USA

 

[itsmoked]

Have you considered that 256 heaters and 256 senors is at least one thousand(1,000) wires?!!?!

This suggests, ney, demands a distributed system.

I agree with richs you should distribute this. I would suggest 8 to 16 channels per a small PIC. That's 8 or 16 analog analog INs and 8-16 digital OUTs. Pin wise and A/D wise 8 might be best for this reason and others,(as you will see).

Run a simple async comm protocol. Each board has it's own address and 8 channels to control. Each board implements its own closed loop controls. Each board will faithfully run its own heaters without intervention. The only stuff that the "control panel", (if you have one), needs, is the current temperatures of the various loops and to issue the setpoints. The master just gets updates when it asks, or adjusts setpoints, when needed by asking or telling a module. Stick everything on 485 duplex for pain-free serial programming. Each unit knows it's own address and ignores all other messages.

This allows you to leverage the PIC's outstanding I/O pin drive capabilities if needed, and really allows you to develop a small smart module and an associated master unit. The resulting full system then just requires turning a crank for the needed number of channels a system requires. This also allows you to physically distribute the control close to the heaters which allows for added system economies to be realized. One tiny example; you might be able to utilize off-the-shelf sensor leads if the controllers are locally mountable rather than needing custom leads or having to, (horror), extend a truck load of sensor leads.

Anyway it sounds like fun. Must be one of those cigarette puffing machines!! LOL

Keith Cress
Flamin Systems, Inc.-

http://www.flaminsystems.com

 

[eromlignod]

OK, I'll let the cat out of the bag. It's a self-tuning piano. I pass electrical current through each string to control its temperature and thermal expansion/contraction controls its pitch.

Here is some of the publicity:

http://www.newscientist.com/article.ns?id=dn3143

http://query.nytimes.com/gst/fullpa...=Top/Reference/Times Topics/Subjects/P/Pianos

http://www.npr.org/templates/story/story.php?storyId=878091

http://www.google.com/patents?vid=USPAT6559369&id=d7wMAAAAEBAJ&dq=gilmore+piano

The piano is purposely tuned too sharp and warming the strings flattens them to pitch. The average temperature is around 95 F and they run at about 3 Vdc.

For simplicity's sake I said the feedback was temperature. Really it's pitch. I sustain the strings magnetically (like an Ebow) and tap the signal to measure the pitches, then adjust the PWM to tune the string. When they are all in tune, I stop the sustain and just maintain the duty cycles until the system is switched off when the pianist is done playing. The next time it is switched on, it sustains and tunes again for that day's ambient conditions.

I have already run it with a monstrosity of wires using a PLC and now I'm trying to embed it into the piano. Thanks for the suggestions so far.

Don
Kansas City

 

[btrueblood]

Don, after reading a bit of the patent:

You are way to clever to be from this planet. That is a very cool application, or maybe the operative adjective is "hot"? Now, if the wife will let me tear into our upright at home...

Back to your problem:

So, (guesssing) the reason you want a single "master" controller is to avoid clock frequency errors between seperate controllers causing seperate banks of strings to be mistuned relative to each other?

Could you not use watch/clock crystals (with their very high accuracies) to provide reference clock rates for each controller and use the distributed schemes like itsmoked's? Alternatively, use one crystal and distribute it (but I think that's considered bad because you may overload the crystal with too much line? The real digital guys probably can enlighten us more on that). There may be a way, using a multiplexer (MUX switch), or 16, that you could distribute the clock signal to only one controller at a time. Lastly, I was thinking earlier that you could use multiplex switches to directly address the PWM controllers one-at-a-time from the master, rather than via a network.

After sitting here a minute. Why not use dc instead of pwm, and vary the voltage using some combination of amplifiers and digital potentiometers? You still need to address each pot, but once set you could forget it for awhile.