×
INTELLIGENT WORK FORUMS
FOR ENGINEERING PROFESSIONALS

Log In

Come Join Us!

Are you an
Engineering professional?
Join Eng-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!
  • Students Click Here

*Eng-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here

Jobs

Sharing Memory Between Processors?
2

Sharing Memory Between Processors?

Sharing Memory Between Processors?

(OP)
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

RE: Sharing Memory Between Processors?

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

RE: Sharing Memory Between Processors?

I would use a cheap PC compatible processor from
BAGOTRONIX or JKMICRO (add 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/>

RE: Sharing Memory Between Processors?

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.

RE: Sharing Memory Between Processors?

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

RE: Sharing Memory Between Processors?

(OP)
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

RE: Sharing Memory Between Processors?

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/>

RE: Sharing Memory Between Processors?

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

RE: Sharing Memory Between Processors?

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/>

RE: Sharing Memory Between Processors?

(OP)
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

RE: Sharing Memory Between Processors?

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/>

RE: Sharing Memory Between Processors?

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.

RE: Sharing Memory Between Processors?

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/>

RE: Sharing Memory Between Processors?

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

RE: Sharing Memory Between Processors?

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.

RE: Sharing Memory Between Processors?

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

RE: Sharing Memory Between Processors?

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

RE: Sharing Memory Between Processors?

(OP)
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/fullpage.html?res=9800E1D8133FF931A35752C0A9659C8B63&amp;n=Top%2fReference%2fTimes%20Topics%2fSubjects%2fP%2fPianos

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

http://www.google.com/patents?vid=USPAT6559369&amp;id=d7wMAAAAEBAJ&amp;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

RE: Sharing Memory Between Processors?

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.

RE: Sharing Memory Between Processors?

Ha clever indeed... Probably end up under the wheels of some pickup truck Don.. a piano tuners! autobugeyedcryHAHA.

Let me get this straight. You listen to each string and hence tune each string?

Is this done only during a "tuning time"?

Can you not use passive tuning and do it while it is being played or via someone running the keys once?  Seems it would get out a sizable bit of wiring(expense) for you, (excitation coils).

You've probably thought of it already but maybe you should provide methods - perhaps using a DSP to allow "coloring" of the tuning so that a musician can have the tuning shift for their needs, or the music's, or the "halls" as Appalling was saying.  That way the piano tuners could possibly embrace the system too.

230 channels yikes.  I'd still stick with the same plan. I'd run the excitation and the heat and even the audio frequency detection with each module you'd then have a module run the basic tuning per group.

This format makes for a tidy development(always important!)

1) Build a board to completely control 8 channels.
2) Get it to control perfectly 1 channel.
3) Modify the SW to run 8 channels.
4) Add a simple comm protocol.
5) Develop a master controller that is wireless capable.
6) Develop laptop SW to wirelessly connect with your piano so you can run any number of tuning tools to be developed.

I'm sure there are going to be aesthetics about this whole thing.  I can well imagine some players being fundamentally horrified about electrical switches knobs or dials on a Piano as I try to picture any location you might put them whereas, wireless kinda 'leaves the piano alone', even in the makers artisan's eyes.

Keith Cress
Flamin Systems, Inc.- http://www.flaminsystems.com

RE: Sharing Memory Between Processors?

You could do the PWM by reading a bank of ram using a free running counter on the address lines.  

[ I've done somthing similar, pwm-ing stepping motors using a 20kHz counter to run the low address lines and strobe  continuous reads from an eprom, with the actual (sorta micro) steps done by  manipulating the high address lines to select 'banks' of preprogrammed pwm patterns.  It produced 16 sorta- micro steps per full step, but I couldn't make the step angles perfectly equally spaced because of detent torque. ]

You could interpose writes between the read cycles, or double the ram, bank-swap it and write it twice to keep it up to date.

Mike Halloran
Pembroke Pines, FL, USA

RE: Sharing Memory Between Processors?

When the piano wires vibrate, they're suddenly moving quite quickly in air. The wires will instantly start to cool-off because of the 'breeze' caused by their oscillatory self-movement. This air-flow will remove the heat and tighten the wire.

In other words, there's going to be a rising pitch with each note. Even if the control loop is super fast, it would be a warble. If the control loop was mind-bendingly fast (many kilowatts of peak power), then it would still be a spread-spectrum note with a peculiar sound.

You could either coat the wires with some sort of newly-invented high-tech thermal insulation (an invention probably worth trillions of dollars by itself). Or perhaps apply a vacuum to the inside of the piano (but you'd have to keep the piano lid closed...).

Ignoring all the above negativity... winky smile

Is there some way of making the 256 channel count into a 16x16 matrix and thereby reducing the I/O count to 32?

Hmmm...

RE: Sharing Memory Between Processors?

(OP)
I'll have to repspectfully disagree with you since I've already built it and it works fine.  Apparently any effects the vibration has on heat transfer are negligible, since it generally behaves thermodynamically the same as if it were still.

I like your matrix idea.  I'll have to give it some more thought.  Too bad you can't connect directly to the bits inside a RAM.  Maybe some type of display driver??

Don
Kansas City

RE: Sharing Memory Between Processors?

16 high side outputs (drivers) and 16 low side sinks (think open collector 'outputs'). 256 strings connected at the intersections. Each string is individually addressable.

Do everything digitally (on/off) in the time domain. With this few signals, the processor should be able to buzz through them all pretty quickly.

If you need a speed boost, you can address multiple wires at once provided you choose the combinations carefully so that they don't get in each other's way. Probably need a preprogrammed table to do this efficiently.

PS: I'm glad that the basic idea does actually work.

RE: Sharing Memory Between Processors?

One problem with the matrix concept I described is that the duty cycle when power is applied to each string has to go down. You'll need lots more peak power, and a pretty high frequency to hide the low duty cycle. Probably need a radio transmitter license for the beast.

RE: Sharing Memory Between Processors?

Here's a though that you might jump on;

rather than heat the strings, anchor the stings to a carrier which would have a short heated section. The latency  of the anchor could be engineered to provide latencies that could be managed by PID loops.

RE: Sharing Memory Between Processors?

If you want to pursue the shared memory acces thing; In the past I've run DMA circuits on earlier 8 bit machines where the main CPU has bus access on phase 1 of the clock, whilst seconday CPUs shared phase 2 of the clock. Yet another method is to divide down a master and stretch one multlpe out. During this stretched clock interval, external devices can clock in for shared bus activities.

Yet another idea is rather than PWM, you can write out a byte into a resistor network which will give you stepped power command.

RE: Sharing Memory Between Processors?

The moving string has no problems with getting cooled because the sting is mostly radiantly heated.  Moving back and forth in the same radiant/convective field, like if you ran around under a heat lamp.

eromlignod; Do you have to heat each of the strings in a triplet?

Don; That Micrel part would work fine.

Check out this part too. It's an SPI digital bus part.
http://ww1.microchip.com/downloads/en/DeviceDoc/21952b.pdf

http://eu.st.com/stonline/products/literature/ds/5865.pdf

You might search out "executable high voltage shift register" in the hope that you could directly drive your heaters.

Keith Cress
Flamin Systems, Inc.- http://www.flaminsystems.com

RE: Sharing Memory Between Processors?

(OP)
Thanks for all the ideas.  This is such a friendly group.

Itsmoked:

I like the idea of the built-in power electronics, but I need a lot of current.  The average string has a resistance of about 0.5 ohms and takes about 2 or 3 watts to tune, so at just a few volts, the current gets pretty high.  Even if I found one, it would have to cost less than the other chip + the FET's.

Automatic2:

I like the idea of running the two processors on opposite clock phases.  I guess this would obviate the need for interrupts and busy signals?

Don
Kansas City

RE: Sharing Memory Between Processors?

(Another competing technology is piezo-driven actuators. Basically, a pair of crystals are used in I-Q mode to drive a mechanism one way or t'other depending on the phasing. Linked to a screw thread they can move things with very, very, very fine control. But Don's heating concept has no moving parts and should be much cheaper to implement. But something with a screw thread might remain in tune even with no power applied.)

I think it's pretty obvious that the 16x16 matrix concept would have tremendous cost advantages over the 256 parallel approach.

The question becomes: how many milliseconds will a string remain in tune after the power is cut before you need to revisit that string with another blast of power? And what resolution is required for the width of the power pulse so that the string remains in tune over the longer term?

Also, thinking a bit more about the peak power, the matrix shouldn't be much different than doing it in parallel. The applied voltage would be more like tens of volts instead of 3 volts, but that's not at all difficult. Considering the likely timing and power, all you'd need is a supercap to smooth of any remaining current pulses.

The strings will have to be electrically isolated at both ends. The far end of the strings will be connected in groups of 16 and those 16 return wires (not too bad a count) will run back to the driving circuit. The near ends will have to be arranged in counted-off groups 1-16 repeated, then those 16 high side wires will run back to the driving circuit.

The matrix leads to a lower pin count but would require a processor with higher performance to accurately calculate and count-off the required pulse widths. Fortunately that is exactly what most processors are these days. Trading off a higher clock speed for an 8:1 reduction in I/O pin count and high power drivers/sinks seems very attractive. uSecond resolution of the power pulse width should be easy these days.

Now, how to achieve a similar reduction on the other side of the circuit (256 excitation/sensing coils, etc.)? Another 16x16 matrix with the coils at the intersections?

Also, I'd be tempted to provide a closed loop so that the piano could stay in perfect tune during a performance. Just measure the frequencies (intelligently) from the sensing coils and update the table.

Give this thread a star for being the most interesting application of technology recently.

RE: Sharing Memory Between Processors?

(OP)
Thanks for the star.

Actually, I have the sensor end worked out.  I use an FPGA.  The sensors put out a 5V square wave at the frequency of the string vibration (I square them with LM339 comparators).  I just feed them into the inputs of the FPGA and have 256 independent 16-bit counters inside.  Basically I measure how many cylces of a 22 MHz clock happen during one cycle of the string (rising edge to rising edge) using the string signal as a gate for the counter.  Then I strobe this number into a 16-bit register and clear the counters before the next rising edge of the gate.  All the counters run continuously.  

I mux all the 16-bit vectors down to one bank of 16 ouput pins, using 8 input pins as the address.  So the main MCU puts out an 8-bit address indicating which string it wants to read and the period of the wave of that string appears on the 16 data pins from the FPGA.  I use this number for my PWM calculations.

I was actually pretty proud of myself for getting the FPGA (Xilinx Spartan-3) to work, since I'm just an ME.

I haven't picked out a main MCU yet, but I'm thinking about a Rabbit 3000.

...now I have to figure out my PID algorithms...ugh!

Don
Kansas City

RE: Sharing Memory Between Processors?

Certainly in this case, "... just an ME" does you a disservice.

That's a really neat hack.

Mike Halloran
Pembroke Pines, FL, USA

RE: Sharing Memory Between Processors?

This thread started with a question about shared memory.

As often the case, the real problem was something else, mostly I/O and speed. And, for that, there are many different solutions. The matrix approach reduces the I/O problem and the Propeller micro mentioned by IR in his 10 Mar 07 12:31 post definitely reduces the speed problem. See http://www.parallax.com/detail.asp?product_id=P8X32A-D40

I recommend everyone to have a look at this marvellous machine! It runs eight parallel 32-bit processors at up to 80 MHz/processor. The processors share a common RAM area and all processors have equal access to the 32 I/O:s that exist in the 40 pin package. You are probably not willing to believe that such a machine exists in such a small package and at such a low cost (less than 20 USD in single quantity) - but it does exist and it is being shipped.

It has a high-level language that is very clean and it has an assembler which also is clean and efficient. I have come to like it a lot and, I am really sorry to say this, I have left the ARM processors and the FORTH language for this new beauty.

And, yes, almost forgot to mention that each processor has two independent 32 bit counters with lots and lots of modes that makes the implemention of UARTS, D/A and A/D converters, SPI, I2C, CAN(?) controllers a snap. Mostly, there's code for it already in the application library.

I'm in love again...

Gunnar Englund
www.gke.org
--------------------------------------
100 % recycled posting: Electrons, ideas, finger-tips have been used over and over again...

RE: Sharing Memory Between Processors?

Yes! Two counters in each processor. That is sixteen 32 bit counters (I wouldn't call them counters - tools for building peripherals is more adequate) in each 40 pin package. And, on top of that, there's the system counter to synchronize the eight processors. You owe yourself to learn about it.

Checked pricing - it is 12.95 USD in singles and about 8 USD in 1k lots.

For those that have used Parallax before (I haven't) it must be the way to go when you need to increase capacity in one direction or more.

Gunnar Englund
www.gke.org
--------------------------------------
100 % recycled posting: Electrons, ideas, finger-tips have been used over and over again...

RE: Sharing Memory Between Processors?

With respect to the matrix, I'd said, "...you can address multiple wires at once provided you choose the combinations carefully so that they don't get in each other's way."

Obviously (in hindsight), you can address up to 16 strings at once in parallel (call them columns) by simply running through the rows. This allows the max duty-cycle to be roughly 1 over 16. So the applied voltage would have to be about 12 volts instead of about 3 volts (helpful squareroot in there). 12 volts is perfectly do-able. Total average power is unchanged.

All you have to do is achieve a sufficiently high revisit frequency so that the string maintains a constant note. That goes back to the question about milliseconds.

This type of 16x16 driver circuit would seem to be dirt cheap.

RE: Sharing Memory Between Processors?

It surely is a dual port device. But I do not think that it is a good solution if you are sticking to the Basic Stamp. The main reason is that you do not have the data and address busses brought out on the Stamp.

I think that you have to face it. Forget about the Basic Stamp. But stick with the Parallax and use my new love - the Propeller. It will do it all for you. It has lots of counters and shared memory built into it, too. Not that you are likely to need it, but it is there if you need it.

Also, the Propeller is a very economical device. Incredible power for that kind of money.

Gunnar Englund
www.gke.org
--------------------------------------
100 % recycled posting: Electrons, ideas, finger-tips have been used over and over again...

RE: Sharing Memory Between Processors?

(OP)
The Propeller looks interesting, but I guess I still don't understand how I can get 88 inputs and 256 outputs connected to it.

Don
Kansas City

RE: Sharing Memory Between Processors?

A lot easier than to a Basic Stamp. That's for sure.

I did not say that you can use it standalone. I am just pointing to a new device that has very few limitations and that answers your question about shared memory in a very powerful way.

There are many standard ways of expanding ports. A decoder and a handful of 8 bit latches, a shift register, specialized devices like the NS LED driver mentioned in an earlier post, multiplexers - just about any method you find suitable, economical or fun.

But do not get stuck with a terribly slow and primitive device like the Basic Stamp. No memory in the world, shared or not, will make that elephant fly.

Gunnar Englund
www.gke.org
--------------------------------------
100 % recycled posting: Electrons, ideas, finger-tips have been used over and over again...

RE: Sharing Memory Between Processors?

Wow.  I just had a thought experiment about what this piano might sound like as it "tunes up"... could you adjust the volume of the excitation, so that it starts soft then increases in volume, with all 88 keys going from out-of-tune to progressively in-tune...kinda like that Dolby sound that plays at the start of some movies...add some LED's that slowly increase in brightness...way cool.

Okay, back to engineering now.

RE: Sharing Memory Between Processors?

To tune you have to measure the frequency: until you hit a
key, you have no way to know it.

If one music piece doesn't use one particular key
it is not updated.

You would need a permanent memory ( e.g. flash) so the
tuning data is not lost on power-down. Ofg course, if the
temperature of the room changes, all bets are off.

I don't believe it is practical, economical, etc.
It certainly won't competye with the electronic piano.



----------------------------
Please read FAQ240-1032
My WEB: <http://geocities.com/nbucska/>

RE: Sharing Memory Between Processors?

nbucska,

If you read his patent, he is electronically exciting the strings prior to the piano being played.  Assuming the environment (temperature, RH, radiant sources (stage lights)) changes slowly enough, the piano will stay in tune throughout a performance, and can be re-tuned very quickly prior to the next day's concert.

RE: Sharing Memory Between Processors?

Hi eromlignod;

Since you seem hell bent on not distributing your solution and  you understand FPGAs, and have the tools to develop one, why are you not tailoring one to provide your output, obscene serial shifting and all??  You can even get all 256 outputs out of one part!

You really need to dump that stamp, and in my humble opinion, do this professionally or not at all.  Don't good pianos cost $30K?  I think you may risk your entire effort by fielding a flaky jury rigged solution if you're basing this whole thing on essentially a learning toy.  Do you realize there will be a lot of people watching this?  A truck load of them hate it. They want it to fail.  They will take any failure - especially - the roll out system and run with it!  They will damage your business permanently if they can.  Going out 1/2 cocked will hurt you badly.
Just an observation based on a long history, respectfully.

What voltage are you planing to run your heaters with?

Keith Cress
Flamin Systems, Inc.- http://www.flaminsystems.com

RE: Sharing Memory Between Processors?

BT:
I have the feeling, you would need to add  temperature
sensors, too.

Off course you have to tune it ine string at a time
to avoid coupling.

Well, it may be possible. Practical, competitive,
marketable ? I don't believe ...


----------------------------
Please read FAQ240-1032
My WEB: <http://geocities.com/nbucska/>

RE: Sharing Memory Between Processors?

Wealthy music lovers here in SoFla who like to leave the windows open, or entertain outdoors, or live on a yacht, would love it.

At any price, so long as it works.

Get it right, Don.

Mike Halloran
Pembroke Pines, FL, USA

RE: Sharing Memory Between Processors?

(OP)
I get this all the time: people telling me how impossible it is when it's already a working device (and has been for several years).

All the strings sustain as if a violin bow is being drawn across them.  I do this magnetically and tap the signal for evaluation.  I don't measure the temperature because I don't care what it is.  Only the pitch is used as feedback.  I can tune a single string in about 20 seconds using a crude proportional feedback loop.  Currently I have to individually poll the strings through one counter, which complicates and slows down the process.  I'm hoping the FPGA will eliminate this sluggishness.

I'm not necessarily sold on the Basic Stamp; it's just something I'm already familiar with and have lying around.  I don't need anything fancy if its sole lot in life is to generate a serial PWM loop.  It would be really simple to do with a 32 I/O Stamp because the PBASIC language allows you to refer to groups of I/O pins as if they were a single variable.  So I would have 10 address pins to the dual-port-RAM, 8 data pins from it, and one serial line, one clock line, and one strobe line to the shift register.  Simple, and I can do it in BASIC and don't have to buy a chip burner.  I considered using another FPGA on the output, but though the chip itself might have over 256 I/O pins, I never found one that would have that much I/O on a development board.  And I don't want to think about trying to use just the chip without a good way to connect it to a board, etc.

I don't intend on this setup to be the working production design.  I'm not qualified to even think about doing that correctly, and I don't have $50,000-$200,000 lying around to have experts like you guys do it for me.  What I want is something that can tune quickly and fits inside the piano...something that I can show to prospective manufacturers without any wires hanging out of it or a three-foot-long PLC.

Hopefully a slicker, faster prototype will attract a manufacturer who can fund a real production design.

Don
Kansas City

RE: Sharing Memory Between Processors?

Hiya-

If you run out of processor power with the stamp that you are using, there is an ARM based stamp that's about $25.00 that looks interesting to me.  I haven't researched it in any great detail, but shows promise.

I am not affiliated with the vendor.  The link is:

http://www.futurlec.com/ET-ARM_Stamp.shtml

Hope this helps.

  Cheers,

    Rich S.

RE: Sharing Memory Between Processors?

A good used concert grand goes for over $60k here in the Pacific NW.  A low-end baby grand goes for $30k and a quality upright is $10k or more.  The boys just got to play a true concert grand for their recital; and no, an electronic piano can't duplicate that sound, nor the nuances that a good pianist can generate with an "analog" machine, sorry.

Making the price of the system competitive?  Call a piano tuner, and ask him to drop by next week (or even next month) and tune your piano...and sit down first.  That's for the guy down the street.  The really good tuners, who work once or twice a week for the orchestras/concert halls live in much nicer houses than I do.  

Don's got the right approach I think, and you'll notice he didn't ask us how to market the device, just how to make it work a little better or smaller package than it currently does.

RE: Sharing Memory Between Processors?

"Making the price of the system competitive?"

The uP (which ever one is chosen) is probably cheap compared to the power circuits. I'm fairly certain that the 16x16 matrix can't be beat for price. The only remaining design challenges are in the software (fairly easy and lots of room to be clever).

===
1 : 10 : 100 : 1000 : 1,000,000
The relative value ratios of:
Idea, Patent, Prototype, Manufacturing and Marketing.
As they say on The Tube, "Mind the gap."
===

RE: Sharing Memory Between Processors?

Don,

Your invention reminds me of a local concert I took part in in the summer.  Small, and packed church hall with limited ventilation and no AirCon on the hottest evening of the summer.  Lots of people taking turns to do their party pieces.  Mine was unaccompanied, so it didn't really matter much (the heat that is - the lack of practice was another thing altogether), but the poor girl who'd brought her bassoon couldn't tune it down far enough to reach the piano (wind and strings going in opposite directions as they heat up).

A piano you could retune between items and adjust to suit the vagaries of the solo instrument could be an accompanist's dream.

Do you have scope to chase hot woodwind, or would that justneed to big an initial uptune for the health of the frame?

A.

RE: Sharing Memory Between Processors?

(OP)
Thanks for all the help (and encouragement) so far everyone.

As I'm contemplating what my next move is, I had an idea that I thought I'd run by you guys.

I'm already using an FPGA to multiplex and measure the incoming wave signals from the strings.  It still has a lot of I/O left and I'm wondering if there is anything else I can use it for in this application.  There's not enough left to drive the outputs, but I'm thinking that it might be possible to create the dual-port memory bank (RAM) with what's left over (8 data, 13 address).  I wish the FPGA could be my entire processor, but I don't think it's practical to do PID or serial communication with it...is it?

Don
Kansas City

RE: Sharing Memory Between Processors?

A critical factor is the thermal (pitch) time constant of the strings (in the worst case). Not the 1/e time constant, but within the required accuracy of the pitch (probably with a several:1 safety factor).

In other words, if the strings maintain their pitch for several seconds in the absense of power being applied, then the required speed of your entire end-to-end process drops down (probably use relay logic winky smile ). If the strings need to be constantly hit with heat every couple of  milliseconds, then you need a much faster scheme.

This factor has a huge effect because you can shift gears to a simpler architecture if the speed is low enough.

RE: Sharing Memory Between Processors?

(OP)
My current setup has a PWM cycle frequency of about 2 Hz, or two on/off cycles per second.  This appears to be fast enough to get a steady pitch.  

My accuracy needs to be at least +/- one "cent", which is logarithmically about 1/100th of a musical half-step (the pitch between a white key and the next black key).  This is the accuracy piano technicians are tested to when they receive their RPT certification.  In reality I should be able to get much better than this. I can measure the frequency (period) to tiny fractions of a cent and I plan to have 8 bits of PWM resolution (1 in 256).

Don
Kansas City

RE: Sharing Memory Between Processors?

VE1BLL brings up a good point, that you may be able to investigate with the rig you have now, i.e., how low can you go with the heating frequency?

There may be a limit other than the thermal time constant, too.  If the heating cycle happens to acoustically excite a string, and a good musician with young ears can hear it in a quiet room, that may become a problem.

Mike Halloran
Pembroke Pines, FL, USA

RE: Sharing Memory Between Processors?

Can you add a small thermal mass to the heaters that could allow a much  lower update rate?  Say 1 or 2 seconds or even longer?  Would seem (theoretically) that you could stretch it to minutes because the room ambient won't be able to affect wild rapid changes.  This could allow really slow processing.

If you have the grits you can do anything with an FPGA! You can get processor IPs and stick multiple ones in. You can run PCI (horrible complex logic engines), you can certainly use them for shallow DPM.  USARTS and other serial comm are often done in/with them.  NIOS is a 32 bit processor you can get from ALTERA that runs in their FPGAs.  You can get all sorts of 8051 cores, which are 8 bitters that can easily do your job.

What voltage are your heaters?(for the third time)

Now let me address your 'plan' as you are about to make a serious amateur's classic mistake.

Quote:

I don't intend on this setup to be the working production design.  I'm not qualified to even think about doing that correctly, and I don't have $50,000-$200,000 lying around to have experts like you guys do it for me.  What I want is something that can tune quickly and fits inside the piano...something that I can show to prospective manufacturers without any wires hanging out of it or a three-foot-long PLC.

Hopefully a slicker, faster prototype will attract a manufacturer who can fund a real production design.

Why are you not working on the production version? You've said the method works. You're scheme for show-and-be-funded is um.. less than optimal! Actually, in your case, it's down right bad!  You are going to put the buyer in the drivers seat, BIG TIME, using this plan.  Is this what you want?

  If they fund you for engineering to build the 'production unit' then they in-fact own  a serious part of your design - the heart of the realised hardware. The legal precedence is very clear on this.  When the Next Company comes along and wants your tuner there will be a big problem.  You will have legal difficulties in using any of the prior design on a competitor's piano.  You need to have a product that is done but only needs maybe some mechanical/aesthetic alterations to fit a particular company's piano.  In the industry this is commonly referred to as "tooling" or "customization".  This clearly defines what part of the work to be done just for that customer.  Again they own that but it's only for their piano, and you won't care, because only they need that specific tooling.  The Next Customer comes along and you charge them tooling also.  Tooling can be a line item on a quotation and doesn't mean,(and better NOT mean), "thrashing out the production design"!

  If the first company to fund you has one shred of business moxie it will be the last company you ever sell a tuner to. If you continue with this 'plan' you are going to be rather sorry in my opinion.

Keith Cress
Flamin Systems, Inc.- http://www.flaminsystems.com

RE: Sharing Memory Between Processors?

(OP)
The system cannot be practically implemented in a piano without warming the strings to tune them.  This is a claim (among many others) in my patent and any device used to warm a piano's strings for tuning must be licensed by me or it will infringe.  Anyone trying to claim rights to the technology because of the electronic design would be playing "dog in the manger".  Their electronics are useless without a device for them to control.

What most of the piano manufacturers that I have talked to want is an exclusive for a year or two, then sublicense the patent to all other piano companies.  The version leased to the other companies would be deliberately inferior (in speed and accuracy).  

I get the same royalties no matter who produces it.

Don
Kansas City

RE: Sharing Memory Between Processors?

(OP)
...Oh, and to answer your question...currently I use 5 volts to warm the strings from a 5V, 1500W power supply.  As I mentioned before, the string resistances are about a half an ohm.

The strings themselves literally *are* the heaters, and I can't add any mass to them without changing their timbre, so any increase in voltage would be accompanied by a corresponding increase in peak current and a decrease in duty cycle percent.

Don
Kansas City

RE: Sharing Memory Between Processors?

Does one exciter/pick-up coil cover all 2 or 3 strings in one set of strings (for one key)? You'd mentioned having only 88 coils but 256 heater circuits. Do you use FFT to ferret out each of the three strings at once? Or use the different frequecies to sort them out?

Two cycles per second for the heating control loop should be dead easy, even with the required very fine (1 or 10 uS ? *) resolution of the exact duty cycle. You should not run into any problems with lack of processing speed.

* Have you confirmed the exact resolution requirement for the duty cycle value? You need to confirm if 1/256 (or 1/1k or 1/1M) is fine enough control of the duty cycle. 1/256 seems a bit course. If you're a shade too high or low, then the string will slowly drift unless you close the loop (recommended).

With suitable SW, you could interpolate the duty cycle in between what the hardware is capable of (keeping in mind the thermal time constant). I'd just make it as fine as possible and close the loop.

I'd add a USB port too for uploading and downloading settings and saving personalized tuning scales.

With respect to Patents and IP, it seems to be not uncommon practice to have a flow of refinement patents going through the office (slowly) so that you effectively drag out your monopoly decade after decade after decade.

RE: Sharing Memory Between Processors?

...and the patent office has been getting wise to such schemes and is cracking down on it.  Judges are starting to toss cases and patents because the "refinements" were obviously meant to do exactly what you describe.

Dan - Owner
http://www.Hi-TecDesigns.com

RE: Sharing Memory Between Processors?

Don:
Do you update the tuning while the piano is being played,
too? What do you do about the coupling betveen the keys?

Knowing so much more, I would use a custom designed processor board with a 186 - the question is how to interface it to the sensor coils and the power switches.

The circuits are simple but to reduce the production cost
it may be worth to develop special custom IC-s.

Wouldn't be cheaper to use one tuning unit which would
slide across the strings, measure each in turn and
tune it mechanically ?


----------------------------
Please read FAQ240-1032
My WEB: <http://geocities.com/nbucska/>

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Eng-Tips Forums free from inappropriate posts.
The Eng-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Eng-Tips forums is a member-only feature.

Click Here to join Eng-Tips and talk with other members!


Resources