Does SoundPal work with other microcontrollers like a PIC????

Shannon · 2008-11-03 01:37

I'm doing a project with a PIC18F4620 microcontroller. I bought the SoundPal to try to use with this controller, but I didn't do enough research before hand. Now I am finding that it may not work with my controller. The PIC uses at least two output pins to communicate with serial devices. I'm assuming that the SoundPal is a serial device since it used the SER commands in the BASIC programs to communicate with it.

Does anyone know how I can use the SoundPal with a PIC controller?

Thanks for the help ahead of time.

SRLM · 2008-11-03 01:46

This is the key quote from the documentation:

"...commands at any baud rate between 9600 and 19200, positive logic, 8-bit, no-parity."

If you uC can do this, it should work.

T&E Engineer · 2008-11-03 01:50

I don't know PICs that well but the SoundPal should work with
most any micro-controller.

Are the 2 pins on the PIC for send and receive? You just need to be able to send a string at a baud rate. Provide more info on the PIC.

Shannon · 2008-11-03 02:39

What I am seeing in the PIC18F4620 datasheet are three pins for serial communications: data out, data in and a clock. I thought I could just use the data out as well. But, I guess I'm confused about the clock pin. I only have experience using the I2C serial communication functionality, it does not require the clock pin. But, I am wondering if the SPI serial communication requires the clock pin.

Do you think I can get away without using the clock output pin?

Bob Lawrence (VE1RLL) · 2008-11-03 03:08

Shannon said...
What I am seeing in the PIC18F4620 datasheet are three pins for serial communications: data out, data in and a clock.

Seems loke you are looking at the SPI Mode. If the SoundPal has SPI then that's fine.

It's more likely that you should try:

"The Enhanced Universal Synchronous Asynchronous
Receiver Transmitter (EUSART) module is one of the
two serial I/O modules. (Generically, the USART is also
known as a Serial Communications Interface or SCI.)
The EUSART can be configured as a full-duplex
asynchronous system that can communicate with
peripheral devices, such as CRT terminals and
personal computers. It can also be configured as a halfduplex
synchronous system that can communicate
with peripheral devices, such as A/D or D/A integrated
circuits, serial EEPROMs, etc."

==========================================
The pins of the Enhanced USART are multiplexed
with PORTC. In order to configure RC6/TX/CK and
RC7/RX/DT as a USART:
=====================================

Good luck.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Aka: CosmicBob

Shannon · 2008-11-03 03:49

Thanks for the suggestion!!!

I read the bits in the datasheet about the USART/EUSART. So, should I connect the SoundPal to the TX pin, as it is for transmission? The TX pin is for transmission, so I assume that would work.

Phil Pilgrim (PhiPi) · 2008-11-03 04:15

Yes, the SoundPAL expects asynchronous serial data (i.e. 1 start bit, 8 databits, 1 or 2 stop bits), so the UART mode of your PIC should work fine when properly configured.

-Phil

Shannon · 2008-11-03 04:34

Thanks very much for your help! I will work on this tomorrow and come back if I have any trouble.

Shannon · 2008-11-04 01:02

So, I've written code that utilizes the TX output pin on my PIC's USART functionality. I am sending individual characters that represent the notes for the SoundPal, I assume. In the SEROUT examples in the SoundPal documentation, however, only the "=" and "!" are represented as character strings. But, I am not familiar with the way the BASIC controller code works.

I am basically sending these strings out through the TX pin: "=", "C_1", "B_1", "A_1", "D_1", "G_1", "F_1", "E_1", "C_1", "A_1", "B_1", "0", "!"

However, nothing is happening when I do this. I am seeing that my registers are being set, etc, in debug mode, but the SoundPal is not making any noise.

So, are there delimiter characters I should use in between each note string?

Is there anything else I may be doing incorrectly?

Also, something else that may be affecting the SoundPal: I accidentally connected my whole circuit, which is on a breadboard separate from my main circuit, to my 9V supply. I forgot that I needed a transformer to lower the voltage and forgot my supply was 9V. However, my controller is still working. Is it possible I killed the SoundPal???

Thanks for the help.

Mike Green · 2008-11-04 02:18

The strings that you've shown won't work. If you look at the sample program, you'll see a lot of declarations like "C_1 CON $81" or some such. These are constant definitions. The label "C_1" is defined as the constant value $81 (in hexadecimal). That's what should be sent to the SoundPAL. Make your own list of what single byte values do what.

It's quite possible that you damaged the SoundPAL with the 9V supply voltage. Anything above 7V can certainly destroy low voltage devices like the SoundPAL.

The SoundPAL uses the data line for bidirectional signalling. Make sure that your PIC leaves that line floating when it's not actually sending data. There is a pullup on that line internal to the SoundPAL. Read the SoundPAL documentation for details.

Shannon · 2008-11-04 04:05

Okay, thanks for the help. I have put in the constants and am now sending the correct values. However, it is still not working, so I think I did burn out the SoundPal. I will order another one tomorrow, since they are not that expensive. If I can't get the new one to work, I will ask for further help.

Thanks very much for your help.

Shannon · 2008-11-09 04:47

Still not working.

I just got my new SoundPal in and have tested my code. It's still not working. I'm using the USART on the TX output pin. So, if anyone can help me figure this out, here is my code in C:
// Main routine executes first
void main ( void )
{
// Set up and configure the oscillator
setup_stuff();

// Set baud rate registers, should be about 9600
SPBRGH = 0x00;
SPBRG = 0xF0; //0x19;

// Set bits to 0 for 8-bit and asynchronous transmission
TXSTAbits.BRGH = 0;
BAUDCONbits.BRG16 = 0;

// Set sync bit to 0 for 8-bit and asynchronous transmission
TXSTAbits.SYNC = 0;

// Enable the port
RCSTAbits.SPEN = 1;

// Enable transmit interrupt bit
PIE1bits.TXIE = 1;

// Enable transmission
TXSTAbits.TXEN = 1;

// Send the load bit
b[noparse][[/noparse] 0 ] = '=';
write_data( b );

// Loop through the notes array
for( i = 0; i < 11; i ++ )
{
// Set the transmission register
TXREG = notes[noparse][[/noparse] i ];

// Wait for the TXIF bit to go to one
while( !PIR1bits.TXIF );

// Reset the bit to zero
PIR1bits.TXIF = 0;
}

// Send the load bit
b[noparse][[/noparse] 0 ] = '!';
write_data( b );

while( 1 );
}

void write_data( char *b )
{
while( *b )
{
// Set the transmission register
TXREG = *b ++;

// Wait for the TXIF bit to go to one
while( !PIR1bits.TXIF );
PIR1bits.TXIF = 0;
}
}

I put in the constants for the notes and I send the first and last bits (= and !) as characters, since they do not appear to be constants in the SoundPal documentation. Yet the SoundPal still does nothing.

Can anyone please help me figure out what's wrong?

Thanks for the help.

Franklin · 2008-11-09 16:39

Shannon, since you have found that the sound pal is not easy to connect to your pic why not find something that is rather than buying another sound pal? Also, try running the output of your pic into a terminal program and make sure what you are sending is what you want.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- Stephen

Phil Pilgrim (PhiPi) · 2008-11-09 18:29

Shannon,

It looks like you need to pay more attention to the SoundPAL's initialization and protocol. Here's what to do:

····1. On powerup wait at least 10ms before interacting with the SoundPAL. This will allow it time to come out of its own power-on reset.
····2. Wait for the I/O pin to go high. This signals that the SoundPAL is ready.
····3. (Optional) Pull the I/O pin low for at least 2ms, then tri-state it. This sends a soft reset to the SoundPAL.
····4. When sending data, be sure to use open-drain serial I/O. You should never drive the SoundPAL's I/O pin high!
····5. After sending a sequence to play, perform the handshaking sequence outlined in the SoundPAL's manual. This will tell you when the SoundPAL is finished playing and can accept another command.

If you observe these simple rules, there's no reason the SoundPAL should not work with your PIC. It's not a difficult protocol.

-Phil

Shannon · 2008-11-09 22:01

Thanks for the help with the initialization and protocol.

However, I am checking the TX pin now to see if it becomes high. This is the pin that the I/O pin of the SoundPal is connected to. But, the problem is this pin never becomes high. It stays low forever. I have let the code run for a couple minutes at the longest and it still remains low.

What else could be the problem here?

Thanks for your help.

Phil Pilgrim (PhiPi) · 2008-11-10 03:58

What happens if you leave the SoundPAL's I/O pin unconnected? My bet is that it will go high on its owm. If so, there's a problem with your PIC program that's keeping the pin low.

-Phil

Shannon · 2008-11-10 05:00

I set the pin that the SoundPal is connected to as an input pin. Therefore, if the SoundPal goes high on its own, the pin will go high. The PIC should not be keeping the pin pulled low. I use the same setup for my motion sensor, which outputs high when motion is sensed.

I will try turning on the SoundPal on it's own and see what happens to the I/O output.

Thanks for your help.

Shannon · 2008-11-10 07:29

I got my program to see the SoundPal's high bit. I was confusing my input and output setting and had the port set to output instead of input. Now it recognizes the high pin and then sends the data.

However, it is still not making any noise. I cannot poll it either because the TX bit for the USART on a PIC is only for output communication. I can receive byte data back in from the SoundPal. If the pin went high again I would be able to see that, but I cannot receive data back.

I have tried a few different techniques of sending the data, but none are working. Here is the code that I am trying to use the most:
#include <stdio.h>
#include <p18f4620.h>
#include <stdlib.h>
#include <usart.h>

// Constants
#define A_SIZE 16
#define ZZZ 0x80
#define C_0 0x81
#define Cs0 0x82
#define Df0 0x82
#define D_0 0x83
#define Ds0 0x84
#define Ef0 0x84
#define E_0 0x85
#define F_0 0x86
#define Fs0 0x87
#define Gf0 0x87
#define G_0 0x88
#define Gs0 0x89
#define Af0 0x89
#define A_0 0x8A
#define As0 0x8B
#define Bf0 0x8B
#define B_0 0x8C
#define C_1 0x8D
#define Cs1 0x8E
#define Df1 0x8E
#define D_1 0x8F
#define Ds1 0x90
#define Ef1 0x90
#define E_1 0x91
#define F_1 0x92
#define Fs1 0x93
#define Gf1 0x93
#define G_1 0x94
#define Gs1 0x95
#define Af1 0x95
#define A_1 0x96
#define As1 0x97
#define Bf1 0x97
#define B_1 0x98
#define C_2 0x99
#define Cs2 0x9A
#define Df2 0x9A
#define D_2 0x9B
#define Ds2 0x9C
#define Ef2 0x9C
#define E_2 0x9D
#define F_2 0x9E
#define Fs2 0x9F
#define Gf2 0x9F

#pragma code

// Prototypes
void setup_stuff( void );
void wait( void );
void write_data( char *b );

// Control loop variables
int i;
int j;

int notes[noparse]/noparse = { C_1, B_1, A_1, D_1, G_1, F_1, E_1, C_1, A_1, B_1, 0x00 };
char b[noparse]/noparse = { '=', '!' };

// Main routine executes first
void main ( void )
{
// Set up and configure the oscillator
setup_stuff();

// Wait for RC6 to go high
while( !PORTCbits.RC6 );

// Turn on indication LED
PORTD = 0xFF;

// Set PORTC to output when RC6 is high
TRISC = 0x00;

// Other code I have tried using the prototypes in the usart.h file
// OpenUSART( USART_TX_INT_OFF & USART_RX_INT_OFF & USART_ASYNCH_MODE & USART_EIGHT_BIT & USART_CONT_RX & USART_BRGH_LOW, 0x0C );
// WriteUSART( '=' );
//
// for( i = 0; i < 11; i ++ )
// {
// WriteUSART( notes[noparse][[/noparse] i ] );
// }
//
// WriteUSART( '!' );
//
// CloseUSART();
//
// PORTD = 0x00;
//
// while( 1 );

// Set baud rate registers, should be about 9600
SPBRGH = 0x80;
SPBRG = 0x0C;

// Set bits to 0 for 8-bit and asynchronous transmission
TXSTAbits.BRGH = 0;
BAUDCONbits.BRG16 = 0;

// Set sync bit to 0 for 8-bit and asynchronous transmission
TXSTAbits.SYNC = 0;

// Enable the port
RCSTAbits.SPEN = 1;

// Enable transmit interrupt bit
PIE1bits.TXIE = 1;

// Enable transmission
TXSTAbits.TXEN = 1;

// Send the load bit
// Set the transmission register
TXREG = b[noparse][[/noparse] 0 ];

// Wait for the TXIF bit to go to one
while( !PIR1bits.TXIF );

// Loop through the notes array
for( i = 0; i < 11; i ++ )
{
// Set the transmission register
TXREG = notes[noparse][[/noparse] i ];

// Wait for the TXIF bit to go to one
while( !PIR1bits.TXIF );

// Reset the bit to zero
PIR1bits.TXIF = 0;
}

// Send the load bit
// Set the transmission register
TXREG = b[noparse][[/noparse] 1 ];

// Wait for the TXIF bit to go to one
while( !PIR1bits.TXIF );

// Turn off indication LED when transmission completes
PORTD = 0x00;

while( 1 );
}

void setup_stuff( void )
{
// Set clock frequency to 8MHz
OSCTUNE = 0x80;
OSCCON = 0xFF;

// Setup Ports

// Set Port C as input
TRISC = 0xFF;

// Set Port c pins to zero
//PORTC = 0x01;

// Set Port D as outputs
TRISD = 0x00;

// Set Port D pins to zero
PORTD = 0x00;

// Initialize loop control variables
i = 0;
j = 0;

// Need to wait a few seconds or so for the SoundPal to come up
wait();
}

void wait(void)
{
// Loop for a long time
for( i = 0; i <= 1000; i ++ )
for( j = 0; j <= 1000; j ++ );
}

I have verified at PIC forums that I am transmitting the data correctly. What else could be causing failure with the SoundPal???

Thanks for your help.

Phil Pilgrim (PhiPi) · 2008-11-10 08:37

At the risk of repeating myself, if your USART device (or routine) is driving the I/O pin both high and low, the SoundPAL may fail to function properly. The correct way to drive the pin is to set the output register LOW, and the direction register to INPUT. When the USART is transmitting, it needs to toggle the direction register, not the output register: a zero bit will set the direction register to output; a one bit to input. If you are using a hardware USART that is incapable of this behavior, you will need to use a software (bit-banging) serial output routine instead.

As an alternative, you can employ a diode (e.g. 1N4148) to emulate open-drain behavior with a totem-pole output and split the SoundPAL's single I/O line into separate input and output lines, viz:

attachment.php?attachmentid=56693

With this circuit, the output can drive both high and low. The diode protects the SoundPAL against bus conflicts. The input pin will echo everything sent to the SoundPAL, as well as any responses sent by the SoundPAL. The output pin must be marking (high) to receive data back from the SoundPAL.

I don't do C and am especially not familiar with its implemetation on the PIC, so I can't be of much help with your program. But I know the SoundPAL can be made to work in your system. Don't give up!

-Phil

Chris Savage · 2008-11-10 15:34

I wonder...since you did have the pin driven as an output, perhaps you have damaged your SoundPAL?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Engineering

Shannon · 2008-11-10 16:19

Phil,

Thanks for your help, again. I am not sure if the USART is driving the pin high. Doesn't serial communication drive pins high and low to send the bits? I think the best implementation for my application is using the circuit you gave with a directional diode between the TX and RX (transmit and receive) pins of my chip. I didn't even think of this implementation, thank you very much!

Chris,

I have to set the TX (transmit) pin of my chip to output, or it won't work to transmit data. I have already purchased two SoundPals and if it cannot handle being attached to an output pin, then it's design is flawed and I will not buy another one. I will try Phil's suggestion and hope it works.

Thanks for both of your help.

Phil Pilgrim (PhiPi) · 2008-11-10 17:14

Shannon,

For the record, what you describe as a "design flaw" is a well-established method for effecting bidirectional communication on a single, logic-level pin. This kind of open-drain data transfer is also used by I2C and One-Wire protocols, to name just a couple more. The BASIC Stamp is capable of open-drain serial I/O natively. Some hardware UARTs/USARTs may support it; others may not. But at least there's a simple work-around that should get you off and running, assuming the PIC USART does not.

-Phil

Shannon · 2008-11-10 18:20

I have connected the diode up, according to the previous circuit diagram, only I reversed the direction of the diode so that data could flow from the output to the SoundPal. But, I am still getting nothing and I am not receiving the data I output on the input pin. I don't know what's wrong. However, I am getting frustrated with this SoundPal and am almost to the point of throwing it out of my design completely.

Does anyone have any other suggestions of how I can connect this to a PIC chip? It seems to me that the USART method is not working and I do not know how any other method can work as other serial methods with this chip require a clock output to a serial device.

Thanks for your help.

RobotWorkshop · 2008-11-10 18:33

I know it may be frustrating when things aren't going right but if you stick with this and see it through you will be much farther ahead. The next time will be a piece of cake.

One thing to keep in mind is that at the heart of several of the BASIC Stamp modules is a PIC processor. So there is definitely hope to make it work with a regular PIC chip by itself.

Why did you reverse the diode in the schematic Phil presented? Have you tried wiring it up exactly as shown?

Robert

Phil Pilgrim (PhiPi) · 2008-11-10 18:40

Shannon,

Let me describe the diode's function in more detail. It's there to block the transmit pin from forcing the SoundPAL's I/O pin high, but to allow it to pull the I/O pin low. In cases where the SoundPAL is pulling its pin low, while the transmit pin is high, the diode will be reverse-biased and will not conduct, thus preventing a bus conflict. The way I drew it is correct. If you reversed the diode, there's no wonder that it did not work.

Please bear in mind that none of this is magic. If something does not work as expected, there will be a logical reason for it and a way to fix it. And that's what we're here for.

-Phil

Post Edited (Phil Pilgrim (PhiPi)) : 11/10/2008 6:47:27 PM GMT

Shannon · 2008-11-10 19:43

Phil,

I connected the circuit as you illustrated it. Now I can see that the receive pin of the USART is getting the data I send out. However, the SoundPal is still not making any noise.

This is the data I am sending out (constants have been assigned):
"=", C_1, B_1, A_1, D_1, G_1, F_1, E_1, C_1, A_1, B_1, 0x00, "!"

Is this data correct to make the SoundPal make noise? Is there a simple way to test if the SoundPal is working? Could not having the diode in the circuit really damage the SoundPal, as a previous poster described? If it has been damaged, I am not going to buy another one.

Thanks for your help.

Phil Pilgrim (PhiPi) · 2008-11-10 20:14

Shannon,

The best way to check whether your SoundPAL was damaged is to test it on a known good system, i.e. a BASIC Stamp running one of the demo programs. My gut feeling is that your SoundPAL is okay, but that there's still an issue with your PIC program. Do you have access to a scope to verify that the data is being sent with the correct number of bits at the right baudrate? If you have access to an RS232 converter (e.g. MAX232 chip), you could also monitor the pin with your PC to see if it's sending the data you think it is. Even if you managed to damage one of your SoundPAL's I/O pins, you can still swap it with the ground connection to use the alternate pin. (See the SoundPAL's schematic, if you don't understand what I mean by this.)

-Phil

RobotWorkshop · 2008-11-10 20:19

What are you using as a clock source for the PIC processor? Are you using a crystal or resonator?

As a test I would follow Phil 's suggestion of you have a MAX232 and connect it to a PC serial port. At that point send the codes for some readable ASCII text and see if you get what you think on the PC. You might be surprised at what you see.

Do you have any other logic level serial devices that you can try with the PIC processor?

Robert

Shannon · 2008-11-10 20:33

No, I don't have a MAX232 chip to connect to my computer. However, the receiver pin of the USART is receiving the proper data. Is that sufficient?

I also do not have another serial device to try. Also, I am using the internal clock on my PIC. In the past I have been able to run I2C devices with this chip. I do not know why it is so difficult with the SoundPal.

Also, I flipped the SoundPal over to change the ground pins and it makes no difference. What else can I try? I'm convinced that the data is being sent properly since the chip is also receiving it now. So, what else could be the problem?

I may be able to borrow a MAX232 on an older circuit I have from a class I took, if you all think it is absolutely necessary. Let me know.

Thanks for all your help.

RobotWorkshop · 2008-11-10 20:40

Ahh! Internal clocks and serial communications usually often = unreliable serial communications. It would receive at the same clock speed that it is sending so that doesn't help determine if it is a timing issue since the receiving clock would be off as much as the transmitter. We need to see if you can properly send serial data to something else. My gut feeling is that may not be the case.

If you switch to a crystal or resonator then your problems may all be resolved.

Robert

Phil Pilgrim (PhiPi) · 2008-11-10 20:55

Shannon,

I agree with Robert. The fact that your PIC is receiving the same data it's sending gives you no clue that the baudrate is within range of the SoundPAL. However, the SoundPAL is very forgiving of baudrates and will work with any data rate between 9600 and 19200 baud. So I wouldn't necessarily worry about using a crystal. Just make sure to program a baudrate halfway between 9600 and 19200 to maximize your margin of error.

-Phil

Does SoundPal work with other microcontrollers like a PIC????

Comments