Is This A Poor Example Of PIC to PIC Communication?

Discussion in 'Embedded Systems and Microcontrollers' started by ajm113, Sep 28, 2011.

  1. ajm113

    Thread Starter Member

    Feb 19, 2011
    176
    5
    Well I'm designing a hand held game using a PIC 16F, a 5,4 LED matrix, and I'm going to use a PIC 12F to be my audio device that would be controlling a buzzer. I wanted my little console to be able to support multitasking. Handling I/O and doing display all synchronized, just like how mulithreading works. Anyways I've concluded that I should use my little 12F for audio, so if I want to play music or play a sound effect, it wouldn't effect the performance of the game using the main CPU/PIC.

    I was thinking on having PORT 0 on the 12F, be the output for the piezoelectric buzzer, and store pre programmed music/effects in the 12F, so when lets say I want to play pling sound on start up, I could just do a digital to analog method and have 3 pins go through 3 resistors (each between ports), and have the output go to a compacitor 4.7uf. Then having the 12F's open pin connect between so I can read values.

    So when it reads value 24 then it plays a pling script.


    What I want to know is: Is this a poor way of PIC programming for communication and usage? Should I maybe use another method that's more professional, so it makes my system a little more complex, but flexible? So if there is a problem with the sound device I can tell the main CPU that?

    Is putting scripts on a PIC to play 8bit like small music, is a poor way of managing memory?

    Thanks, Andrew.
     
    Last edited: Sep 28, 2011
  2. ErnieM

    AAC Fanatic!

    Apr 24, 2011
    7,394
    1,606
    Well, there is nothing magic about "multi threading," it's just a fancy word or abstraction for splitting up time so you spend a portion on each task, thus from an outside world sense it appears as everything is happening at once.

    There was one application I did way back where I needed to acquire a signal and process the results at the same time. The task needed to count pulses during a certain time window and output the results at the end of that window, leaving zero time to process it. What I actually did was to acquire the signal into a counter during one window (a timer getting the clock from a pin), and process it in the next window. I kept my window rate the same and the 1 window delay in the output was quite tolerable in that application.

    While it complicates the code, I don't see any reason offhand why a single PIC can't process human interactions (button presses?) (a fairly slow event rate anyway), update the display (even if it is multiplexed) and make some beeps too according to some "script." Overall it would be an interrupt driven state machine.

    Your way would work too, but I would pretty much always go to a bigger/faster/better PIC before I added a second one. One thing and code base is always simpler to debug then two things.
     
  3. ajm113

    Thread Starter Member

    Feb 19, 2011
    176
    5
    Hey thank you! I seem to have figured how to do this then.

    Sorry for taking to long to reply, but I've seemed to finished my little project now! I didn't add a separate microcontroller for the sound, but instead just added the buzzer with the first one and set a pin as a sound device and just added simple little games like a number guesting game and a Simon game. I thought when I get the point when I buy a LCD display and I get more parts is when I develope a sound device for the second version. ;)

    Anyways, thank you for your help!
     
  4. ErnieM

    AAC Fanatic!

    Apr 24, 2011
    7,394
    1,606
    Good work!

    "Simon" sounds like a cool thing to build. Way back in the day there was a game (I forget the name) that had two 7 segment displays in the center surrounded by 4 buttons. The single chip inside was a micro controller made by General Instruments. I knew someone who worked there who gave me one of their chips. As it was PROM memory there was no way to reprogram it, but for years I had a breadboard version that played the game.

    My friend told me the entire program memory was 512 words (probably bytes) total the the programmer used each and every location to fit the game in. I bet it was all hand coded assembly too.
     
  5. ajm113

    Thread Starter Member

    Feb 19, 2011
    176
    5
    Wow, thats pretty impressive! :) I'll have to do some Google searching on that chip and see if it's somewhere in the market. I kinda wanted a really old microcontroller and maybe play with it and see if I can get it to do something neat, but I'm guesting the programmers out there for it are worth a lot of money too since they are discontinued. Ether way it would be a very nice collectible. ;)
     
Loading...