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
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?
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?
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?
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?
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?
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?
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?
Dan - Owner

http://www.Hi-TecDesigns.com
RE: Sharing Memory Between Processors?
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?
Don
RE: Sharing Memory Between Processors?
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?
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?
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?
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?
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?
----------------------------
Please read FAQ240-1032
My WEB: <http://geocities.com/nbucska/>
RE: Sharing Memory Between Processors?
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?
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?
Here is some of the publicity:
http://www.newscientist.com/article.ns?id=dn3143
http
http://ww
http://
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?
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?
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?
[ 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?
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...
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?
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?
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?
http:/
TTFN
Eng-Tips Policies FAQ731-376
RE: Sharing Memory Between Processors?
RE: Sharing Memory Between Processors?
http://www.micrel.com/_PDF/mm5450.pdf
Don
Kansas City
RE: Sharing Memory Between Processors?
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?
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?
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://w
http://
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?
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?
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?
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?
That's a really neat hack.
Mike Halloran
Pembroke Pines, FL, USA
RE: Sharing Memory Between Processors?
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:/
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?
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?
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?
http://
Don
Kansas City
RE: Sharing Memory Between Processors?
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?
Don
Kansas City
RE: Sharing Memory Between Processors?
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?
Okay, back to engineering now.
RE: Sharing Memory Between Processors?
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?
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?
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?
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?
At any price, so long as it works.
Get it right, Don.
Mike Halloran
Pembroke Pines, FL, USA
RE: Sharing Memory Between Processors?
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?
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?
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?
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?
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?
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?
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
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?
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?
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?
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.
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?
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?
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?
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?
Dan - Owner

http://www.Hi-TecDesigns.com
RE: Sharing Memory Between Processors?
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/>