Shop OBEX P1 Docs P2 Docs Learn Events
Sound control — Parallax Forums

Sound control

Steve2381Steve2381 Posts: 94
edited 2006-12-22 15:45 in BASIC Stamp
Hello

I have a BS2p40 running·five Max7219's·+ their 8 digit displays on a fairly complex clock system

It quite annoying that I have the BS2p40, but can only really use the mainio side.
The·stamp is·communicating with the·led drivers·using the mainio side,·but as I use any of the auxio side connections as outputs, the clocks go screwy because the mainio·outputs are turned off.

I have overcome this by using another·max7219 led display driver driven from the mainio side, and using transistors, gained 64·switched outputs·available to me without killing the clocks.

My two questions are as follows:

1/· Can you report which state you are in - mainio or auxio?· I need to know which state I am in when an event occurs in my software.

2/· This is the·main problem.· I need to playback 35 recorded messages.· These vary in length from 2 seconds to 4 minutes.
If I·use pre-built sound recording boards, it will be cripplingly expensive and they don't usually hold more than 60 seconds of sound (I know a few are longer).
I have tried controlling a cheap MP3 player using switched outputs operating the track controls, but it is far too hit and miss.

Love to hear of any suggestions!

Thanks, Steve

Comments

  • Chris SavageChris Savage Parallax Engineering Posts: 14,406
    edited 2006-12-20 18:59
    Steve,
    ·
    ·· When you switch active banks the previous bank of I/O pins retain their states.· It sounds like you’re indicating they do not.· Is this what you think is happening?· I wanted to confirm.· Thanks.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Chris Savage
    Parallax Tech Support
  • Steve2381Steve2381 Posts: 94
    edited 2006-12-20 20:02
    Hi

    No - the mainio pins are sending data to the max7219's.... and this data is stopped when you switch across to the auxio side.
    I was hoping that I could briefly send a command to switch the state of the auxio pins without it stopping the clocks - but it does.
    Once the clock data is disrupted, the counters go all screwy and only a power reset can cure it.
    Shame - I have the entire auxio side that I don't appear to be able to use.
  • Chris SavageChris Savage Parallax Engineering Posts: 14,406
    edited 2006-12-20 20:04
    Steve,
    ·
    ·· There must be something else happening.· The BASIC Stamp is a single-tasking controller.· The MAINIO pins cannot continue to send data when you switch to the AUXIO bank.· The fact that you have switched banks indicates that the previous operations have completed.· Perhaps there is a problem with your code?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Chris Savage
    Parallax Tech Support
  • Bruce BatesBruce Bates Posts: 3,045
    edited 2006-12-20 20:16
    Steve2381-

    To look at this a different way, the pins will stop outputting data as soon as the SHIFTOUT has completed.

    On the other hand, if you're saying that the MAINIO pins NEVER RETURN to being active, then you have changed to AUXIO, and never changed BACK to MAINIO. You are in total control as to which pin ports are active at any given time.

    BTW - MAINIO and AUXIO have NOTHING to do with bank switching, in case that wasn't clear. You can use MAINIO and AUXIO without ever using any additional slots.

    Regards,

    Bruce Bates

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    <!--StartFragment -->
  • Chris SavageChris Savage Parallax Engineering Posts: 14,406
    edited 2006-12-20 20:42
    Steve,
    ·
    ·· I just realized I didn’t answer your other question about knowing which bank of I/O pins you are using.· First of all, you can switch between them by using the command IOTERM with a 0 or 1 for the MAIN or AUX banks, respectively.· You can use this command in place of both MAINIO and AUXIO.· As for reading which bank is active you can do a GET from location 134 of the SPRAM.· Bit 0 will be a 0 if the MAIN bank is active and a 1 if the AUX bank is active.· I hope this helps.· Take care.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Chris Savage
    Parallax Tech Support
  • Steve2381Steve2381 Posts: 94
    edited 2006-12-20 21:41
    I realise that after swapping to auxio to switch a pin high on the aux side, I then have to return to mainio immediatley to keep my clocks running.
    Any interruption in the data to the max7219's screws up the count, even after the shiftout statement. The trouble I am having is this 'quick' switchover to the aux side is long enough to cause the clocks to go haywire. I am not sure why this is. The clocks carry on counting, but don't show the correct digits - just garbage.
    The tip regarding the GET from 134 of the SPRAM is a great help - thanks. I realise that I should always know what state my stamp pins are in (main or aux), but its difficult to explain my reasons for this requirement.
    My knowledge of Stamp prgramming is limited in exactly how they work memory wise. So, just to check.....
    I have 'Write' statements with 10 values each written from 20 to 220 (eg. Write 220,1,2,3,4,5,6,7,8,9,0) and therefore filling all these locations.
    Are these the same addresses as the above 134 SPRAM? If so, then when I switch between aux and main, it is over writing my data.
    Does anything else use these locations?
    I have already fully used all the slots and run out of variable space anyway... the project has evolved to a point where a stamp can no longer really cope (variable wise)
    I am sure you have been asked a million times before, but can you increase variable space? (I have already 'tidied up' the program and gained as much as I can)

    - edit....·· Just to add, I have just read about adding an external EEPROM.· Can I use this to store my variables ?··
    Although I have to say, the stamp program listing here - http://geocities.com/SiliconValley/Orchard/6633/25LC640.txt·- leaves me goggle eyed. I have no idea how that works!

    Thanks guys

    Post Edited (Steve2381) : 12/20/2006 10:11:42 PM GMT
  • Chris SavageChris Savage Parallax Engineering Posts: 14,406
    edited 2006-12-20 22:22
    Steve,
    ·
    ·· I have used the MAX7219 in over 20 different applications and not once ever had trouble with what you describe.· At least 10 of these applications used the BS2p40.· Either there is a problem with your electrical connections or something in the code.· The MAX7219 does not require refreshing to keep the data on the display.· In code you can shift out 8 digits and never send anything again and that data will remain unchanged on the display until you send new data.· My guess is something else is happening that you’re overlooking.
    ·
    ·· As for the WRITE command, you want to use it sparingly.· If you’re doing this in a loop you will very quickly damage your EEPROM since this has a finite number of write cycles.· Instead you should be using the SPRAM for extra storage of variables.· On the BS2p24/40 that is one of the great things you gain.· This makes me wonder if in fact your EEPROM is already damaged and that is why your display is getting garbled?· Are you by any chance using multiple program slots?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Chris Savage
    Parallax Tech Support
  • Bruce BatesBruce Bates Posts: 3,045
    edited 2006-12-20 22:31
    Steve -

    I'm still not sure you're getting the whole point here, although some might feel it's nit-picking, it's important to understand how things "operate" on a Stamp or other microcontroller. You said:

    "I realise that after swapping to auxio to switch a pin high on the aux side, I then have to return to mainio immediatley to keep my clocks running."

    Your "clocks" ARE NOT RUNNING on the MAINIO pins, or any other pins for that matter, at any time SUBSEQUENT to the execution of the SHIFTOUT command to the MAX7219 which caused them to initially clock out data. The "clocks" WILL ONLY start again, once ANOTHER SHIFTOUT is issued. Any multiplexing is done WITHIN the MAX7219, and that's the beauty of its design. There IS clocking being done to the LED's, but that is external to your control, once you issue the directives or commands to the MAX7219. Is that more clear - I hope?

    If we had a copy of the program, we might be able to re-gain some variable space for you, but without it, it's just a guessing game. So too reducing the size of the program.

    Regards,

    Bruce Bates

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    <!--StartFragment -->
  • Steve2381Steve2381 Posts: 94
    edited 2006-12-20 22:31
    Yes - I realise that the stamp is not doing the multiplexing, but it is issuing·the digit to be displayed on the leds.
    If I don't update the Max7219 within a second of its last update, it visually misses a second on the count (yes - it displays seconds and needs to).

    The write commands have been issued once when I first ran the program and since then have been changed to comment lines.
    Therefore they have only ever been written once or twice.
    As for memory, this is where I get vague.... I assumed that EEPROM was a memory I can write to and it stays there - even after power loss.
    So I assume SPRAM is the memory that resets upon every power up.

    I am using all my program slots.... which I am guessing is bad!
    I have also answered my own question - in that my EEPROM write statements are not going to get overwritten.

    What is the problem with using all the program slots?

    As for the Max7219's, 2x of the displays run from the main side and 2x run from the aux side.
    This was due to basically lack of pins. The 2x main side Max's are running clocks that update constantly, but the 2x aux side Max's are the date and an alarm time which only update once a day.

    Post Edited (Steve2381) : 12/20/2006 10:54:00 PM GMT
  • Chris SavageChris Savage Parallax Engineering Posts: 14,406
    edited 2006-12-20 23:00
    Steve,
    ·
    ·· Some pointers when working with multiple MAX7219 chips...for starters you don’t need so many I/O pins.· You can connect multiple MAX7219 chips to the same clock and data lines.· Each chip should have its own latch pin.· This means having 4 MAX7219 chips should use no more than 6 I/O pins.· Now, in some cases the MAX7219 can be daisy chained and in this case you would only need 3 I/O pins.
    ·
    ·· You are correct in your assumption that EEPROM is non-volatile and SPRAM is volatile.· It really depends on how you’re using the memory as to which is better suited.· In trying to help you it would seem that without seeing the code and/or the schematic we’re really just shooting blind, but I do have to ask.· Do you have a 10K pull-down on pin 12 of the MAX7219?· When you switch slots are you by chance resetting the states of I/O pins in your initialization when you switch slots?· In fact, when you switch between MAIN and AUX are you switching program slots?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Chris Savage
    Parallax Tech Support
  • Steve2381Steve2381 Posts: 94
    edited 2006-12-20 23:13
    Chris - thanks for your time on this....

    I already have shared clock and data lines and individual latch pins as you point out.
    I also have the 10k pull down resistor on pin 12 of the Max.
    The other main I/O pins are used for the BS1302, the input from a matrix keypad and a couple of inputs that need constant monitoring.

    I am not resetting the I/O states when I change slots, I am basically running an initalisation in slot 0, and a main loop in slot 1.
    Then, I am using the other remaining slots to hold large sub-routines (setup menu routines etc). I am using PUT and GET statements to jump between slots and return to exactly where it left the routine in the main loop.

    Yes - I am basically using aux and main I/O in various slots. I didn't think that would be a problem, as long as I returned the MAIN/AUX status to the correct I/O pins before the next SHIFTOUT to the Max's.

    Cheers, Steve
  • Chris SavageChris Savage Parallax Engineering Posts: 14,406
    edited 2006-12-20 23:19
    Steve,
    ·
    ·· Your response lends credibility to my suggestion that quite possibly something is getting garbled in the data you’re actually sending to the MAX7219.· This should be easy to prove by writing a simple test program in a single slot which controls all the displays.· If when not switching program slots everything is fine, then most likely during the switch something is happening.
    ·
    ·· This can sometimes be hard to track down when you are moving variables in and out of the SPRAM between variables.· One thing in the wrong order could result in a corrupt value.· Which brings up another thing you may not have considered…DEBUG.· I would try sending to the DEBUG screen what you are sending to the MAX7219.· In fact, DEBUG that data immediately afterward and you will see if something is not what it should be at that point.· Take care.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Chris Savage
    Parallax Tech Support
  • Steve2381Steve2381 Posts: 94
    edited 2006-12-20 23:21
    Thanks for your assistance and time

    Steve
  • Chris SavageChris Savage Parallax Engineering Posts: 14,406
    edited 2006-12-20 23:22
    Steve,
    ·
    ·· No problem…I would like to see you get this thing working.· At the same time you have a very complex setup and I would like you to come away from this with a better understanding of how to break things down and troubleshoot issues in the future.· In this case we need to simplify the issue to understand where the problem is.· Take care.


    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Chris Savage
    Parallax Tech Support
  • Steve2381Steve2381 Posts: 94
    edited 2006-12-22 14:34
    Looks like the problem may be a variable getting re-written somewhere. Still looking for the error.
    However, when I turn the project on, I have been getting a problem with the second digital display (there are 4 display's run from 4 Max's).
    It doesn't display what it should and usually goes blank.
    I have checked the pcb several times and found no problem.
    It always seemed to be when you first booted the project after being away for a while.
    This morning I think I solved it - its the cold weather.
    As soon as I heated the pcb up slightly with a blow heater, the problem went away. The project is kept in my workshop where it does get cold.
    I is very odd that it only seems to affect the second digital display, and I know its not the max7219, as I swapped it for another and still had the problem on the second display only.
    This means it must be the stamp. Is this a problem with the stamp or does it just not like the cold?

    Thanks
    Steve
  • Chris SavageChris Savage Parallax Engineering Posts: 14,406
    edited 2006-12-22 15:30
    Steve,
    ·
    ·· It’s more than likely a connection somewhere getting cold.· Since it only seems to affect the one display try looking specifically at the wires for both power and data to that display/chip.· Both power and data should be suspects.· Is this circuitry soldered or breadboard?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Chris Savage
    Parallax Tech Support
  • Steve2381Steve2381 Posts: 94
    edited 2006-12-22 15:45
    Its a large soldered circuit board. I will run over with a soldering iron and check the solder joints.
    Thanks for the suggestion

    Steve
Sign In or Register to comment.