Uart to servo controller

Go To Last Post
126 posts / 0 new

Pages

Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hi everyone i was wondering if i could have a few *'s (pointers) hehe. i have a servo controller that requires me to sent strings to it via TTL communication. Dean helped me put this first bit of code together but i cant figure out if this is TTL or not.. it sends the string to Br@ys terminal fine.

The controller had a db9 adapter that can connect to the pc so u can control it from there. it works from there but i think the pc sends 10v and my mega32 sends 5v ...can anyone think why this wouldnt work... u may need more info i dont know...

ne way heres the code.

// HEXAPOD 3DOF ALLOY VERSION 1.0
// USART initialization: 9600,8N1 @ 8MHz 
#include  
#include  

void USART_TxString(const char *strptr);
void USART_TxChar(const char sendbyte);

int main (void) 
{ 
	DDRC = 0x00;
	UCSRA = 0x00; 
	UCSRB = 0x18; 
	UCSRC = 0x86; 
	UBRRH = 0x00; 
	UBRRL = 0x33; 

	USART_TxString("#0 P1792 \r\n");
}

void USART_TxString(const char *strptr)
{
    while (*strptr != 0x00)
      USART_TxChar(*(strptr++));
}


void USART_TxChar(const char sendbyte)
{
    while (!(UCSRA & (1 << UDRE)));
    UDR = sendbyte;
}

p.s the controller is the ssc-32 from lynx motion if anyone has used it . here is a link to the manual if this helps
http://www.lynxmotion.com/images/data/ssc-32v2.pdf

Thanks heaps guys

:arrow: Dan :!:

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

TTL is transistor-transistor logic, it's the physical interface not the communication protocol they're not really related.. The TTL pins are for micro controller interfacing. The receive pin can be hooked directly to an Input pin. The transmit pin may require a current limiting resistor (5k sounds good) unless one is bulit into the board.

-Curiosity may have killed the cat
-But that's why they have nine lives

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

yeah there is one built into the board... well that clears that up. thanks for your reply Sceadwian

:arrow: Dan :!:

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

danrulz01 wrote:
hi everyone i was wondering if i could have a few *'s (pointers) hehe. i have a servo controller that requires me to sent strings to it via TTL communication. Dean helped me put this first bit of code together but i cant figure out if this is TTL or not.. it sends the string to Br@ys terminal fine.

The controller had a db9 adapter that can connect to the pc so u can control it from there. it works from there but i think the pc sends 10v and my mega32 sends 5v ...can anyone think why this wouldnt work... u may need more info i dont know...

ne way heres the code.

// HEXAPOD 3DOF ALLOY VERSION 1.0
// USART initialization: 9600,8N1 @ 8MHz 
#include  
#include  

void USART_TxString(const char *strptr);
void USART_TxChar(const char sendbyte);

int main (void) 
{ 
	DDRC = 0x00;
	UCSRA = 0x00; 
	UCSRB = 0x18; 
	UCSRC = 0x86; 
	UBRRH = 0x00; 
	UBRRL = 0x33; 

	USART_TxString("#0 P1792 \r\n");
}

void USART_TxString(const char *strptr)
{
    while (*strptr != 0x00)
      USART_TxChar(*(strptr++));
}


void USART_TxChar(const char sendbyte)
{
    while (!(UCSRA & (1 << UDRE)));
    UDR = sendbyte;
}

p.s the controller is the ssc-32 from lynx motion if anyone has used it . here is a link to the manual if this helps
http://www.lynxmotion.com/images/data/ssc-32v2.pdf

Thanks heaps guys

:arrow: Dan :!:

I have two SSC-32 boards. One is on the LynxMotion 6 DOF robot arm. The other is one that I was just playing around with.

I have not written any code to drive the SSC-32 with an AVR yet but, I have issued commands using HyperTerminal. It worked very well. I was communicating at 115.2K BAUD, though.

I might suggest that you do use HyperTerminal as a prooving ground that you are communicating with the SSC-32 and use that platform to become familiar with the SSC-32 commands, as well.

The SSC-32 commands are pretty straight forward yet, pretty flexible.

I know this isn't much. I hope it helps.

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi carl.. mine is actually using the lynx 6 arm also... its great. i have sent commands to the terminal from my avr and it shows exactly what the Pc says to the controller. strings are the same... how ever when i plug it in it does nothing but blink the led at me. any ideas

could be a connection error but then again its acknowledging my command by blinking... but i guess it would blink at junk data too.

:arrow: Dan :!:

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm not really sure but:

void USART_TxString(const char *strptr) 
{ 
    while (*strptr != 0x00) 
      USART_TxChar(*(strptr++)); 
} 

doesn't look quite right.

I would be thinking that you are moving to the next pointer address and not the data within the pointer, itself.

And why would the function parameters be declared as constantants when they are variable?

How about something like:

void USART_TxString(char *strptr) 
{ 
    char n = 0;
    while (strptr[n] != 0x00) 
      USART_TxChar(strptr[n++]); 
}

void USART_TxChar(char sendbyte) 
{ 
    while (!(UCSRA & (1 << UDRE))); 
    UDR = sendbyte; 
} 

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

Last Edited: Fri. Jun 23, 2006 - 04:34 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

thanks for that Carl as for the bottom parts of the code in not sure.. ill have to work on that.

:arrow: Dan :!:

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

microcarl wrote:
I'm not really sure but:

void USART_TxString(const char *strptr)
{
    while (*strptr != 0x00)
      USART_TxChar(*(strptr++));
} 

doesn't look quite right.

I would be thinking that you are moving to the next pointer address and not the data within the pointer, itself.

And why would the function parameters be declared as constantants when they are variable?

How about something like:

void USART_TxString(char *strptr)
{
    char n = 0;
    while (strptr[n] != 0x00)
      USART_TxChar(strptr[n++]);
}

void USART_TxChar(char sendbyte)
{
    while (!(UCSRA & (1 << UDRE)));
    UDR = sendbyte;
} 

You sure Carl? I wrote that, and Dan tells me it works fine. "strptr++" causes the pointer address to advance by one (pointing to the next character in the string) and the * outside dereferences the pointer to grab the character. It should work that the while argument keeps feeding USART_TxChar with the next byte in the string on the provisor that the next byte is NOT an end of string character 0x00.

EDIT: Your code is essentially identical to mine (using array format rather than raw pointer format) but yours preserves the base pointer address. I'm not sure if the compiler will see that preserving the address is unnecessary and optimize that out or not.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

Last Edited: Fri. Jun 23, 2006 - 06:05 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hmmmm they both out put the string i want to the terminal . but ill be dammed if i can get it to control a dam servo... im putting exactly the same string as what the lynx terminal inputs to the ssc-32 :?

:arrow: Dan :!:

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

abcminiuser wrote:
microcarl wrote:
I'm not really sure but:

void USART_TxString(const char *strptr)
{
    while (*strptr != 0x00)
      USART_TxChar(*(strptr++));
} 

doesn't look quite right.

I would be thinking that you are moving to the next pointer address and not the data within the pointer, itself.

And why would the function parameters be declared as constantants when they are variable?

How about something like:

void USART_TxString(char *strptr)
{
    char n = 0;
    while (strptr[n] != 0x00)
      USART_TxChar(strptr[n++]);
}

void USART_TxChar(char sendbyte)
{
    while (!(UCSRA & (1 << UDRE)));
    UDR = sendbyte;
} 

You sure Carl? I wrote that, and Dan tells me it works fine. "strptr++" causes the pointer address to advance by one (pointing to the next character in the string) and the * outside dereferences the pointer to grab the character. It should work that the while argument keeps feeding USART_TxChar with the next byte in the string on the provisor that the next byte is NOT an end of string character 0x00.

EDIT: Your code is essentially identical to mine (using array format rather than raw pointer format) but yours preserves the base pointer address. I'm not sure if the compiler will see that preserving the address is unnecessary and optimize that out or not.

- Dean :twisted:

Well Dean, it's late enough that I'm not really sure of anything, except that I'm tired.

I try to refrain from pointers as they tend to confuse me.

I do want to know why the function parameters were/are defined as constants, rather then variables.

But it's good to know that what I provided, at least got out to the SSC-32.

Tomorrow morning, if I have time before I go to work, I'll try to play with your code on my SSC-32 servo controller.

Nite, nite!

Oh! Dan, re-check my previous post as I made edits that you might not have noticed because you were entering another post while I was editing..

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The string sending routine used a const char simply because I was silly and didn't edit it when I just copied the SendChar header to save time. Whoops :oops:.

Both ways will work fine, so Dan should use - as all programmers should - the way which he is most comfortable with.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Awesome thanks heaps Carl. cant have enough help when ur starting out.. :lol: and thank u too dean 8) .

:arrow: Dan :!:

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Let us know when u give the program a go Carl, greatly appreciated.

:arrow: Dan :!:

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Whats a typical ascii string you are sending? does the lynx computer look for control chars like cr and lf? does it need delays between commands or semicolons or some detail thats easy to leave out by accident??

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Bob. it looks for a return character but no delays or anything in between that im aware of.

:arrow: Dan :!:

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dan,

The following is what i got working.

I using an STK500 fitted with an STK501, running a Mega64.

As you said that you had a flashing I/O LED on the SSC-32, I presume you are using a NULL MODEM cable, which is what I had to do.

I'm running at 7.3728MHz and 115.2K BAUD on USART1 at 0% COMM's error. Yours will just be USART as, you only have One COMM's Channel.

I am also using InageCraft ICCAVR v7.xx. I don't know how that applies to any changes you will have to make to get this to run with your compiler.

I am using the eight switches on the STK500 to increment the servo by some small angle with each progressive swtich bit weight. I also output the switch status to the STK500 LED's.

There are some changes as, I could not make your original code work so, I just decided to program the thing up the way I would normally do it. I hope you and Dean don't mind.

The code is following:

// HEXAPOD 3DOF ALLOY VERSION 1.0 
// USART initialization: 9600,8N1 @ 8MHz 
#include  
//#include  

// Crystal Frequency = 7.3728MHz

// Strings to output different servo angles to channel #0
char MOVE_CH_0_1[] = "#0P1000\r";
char MOVE_CH_0_2[] = "#0P1100\r";
char MOVE_CH_0_3[] = "#0P1200\r";
char MOVE_CH_0_4[] = "#0P1300\r";
char MOVE_CH_0_5[] = "#0P1400\r";
char MOVE_CH_0_6[] = "#0P1500\r";
char MOVE_CH_0_7[] = "#0P1600\r";
char MOVE_CH_0_8[] = "#0P1700\r";

char QUERY_CH_0[] = "Q\r";

void USART_TxString(char *); 
void USART_TxChar(char sendbyte); 

void main (void) 
{
   DDRA = 0x00;	 	   // Make PORTA inputs 
   DDRB = 0xFF;	 	   // Make PORTB outputs
   DDRC = 0x00;	 	   // Make PORTC inputs    
   UCSR1A = 0x00; 	   // U2X = 0 = Single speed, MPCM = Single Processor
   UCSR1B = 0x18; 	   // RXEN = Enable, TXEN = Enable
   UCSR1C = 0x06; 	   // No Parity Bit, 8 Data Bits, 1 Stop bit
   UBRR1H = 0x00; 	   // 7.3728MHz 
   UBRR1L = 0x03; 	   // 115.2K BAUD, 0% error

   while (1)
   {
   	PORTB = (PINA & 0x7F); // Get current switch status
      if((PINA & 0x7F) != 0x7F)
 	  {
	   	PORTB |= 0x80; // Turn off command status LED, PORTB bit 7

			if (~PINA == 0b00000001) 		   // Check Switch #0
			   USART_TxString(MOVE_CH_0_1);
			if (~PINA == 0b00000010)	   	   // Check Switch #1
			   USART_TxString(MOVE_CH_0_2);
			if (~PINA == 0b00000100)	   	   // Check Switch #2
			   USART_TxString(MOVE_CH_0_3);
			if (~PINA == 0b00001000)	   	   // Check Switch #3
			   USART_TxString(MOVE_CH_0_4);
			if (~PINA == 0b00010000)	   	   // Check Switch #4
			   USART_TxString(MOVE_CH_0_5);
			if (~PINA == 0b00100000)	   	   // Check Switch #5
			   USART_TxString(MOVE_CH_0_6);
			if (~PINA == 0b01000000)	   	   // Check Switch #6
			   USART_TxString(MOVE_CH_0_7);
	  }

		USART_TxString(QUERY_CH_0);	// Check for command complete
		if (UCSR1A & (1 << RXC1)) 
		   if (UDR1 == '.')
		   	  PORTB &= 0x7F;			// Set the status LED
   }
} 

void USART_TxString(char *strptr) 
{
  char n = 0; 
  while (strptr[n] != 0x00) 
  		USART_TxChar(strptr[n++]);
}

void USART_TxChar(char sendbyte) 
{ 
    while (!(UCSR1A & (1 << UDRE1))); 
    UDR1 = sendbyte; 
} 

Edit:

Added command status query.

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

Last Edited: Sat. Jun 24, 2006 - 05:30 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Don't forget that most TTL communication is positive for '1' and ground for '0'.

RS232 is inverted (as well as having different voltages). Negative for '1' and positive for '0'.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Good morning, I can't thank you enough Carl for sparing the time to help me out with this problem. i made some minor adjustments to the code you gave me to allow it to compile. i put my settings for uart setup (8mhz, 9600 baud etc.) it compiles fine however the output to the hyper terminal just constantly sends commands like this:
Q
Q
Q
Q
Q
Q
Q
Q
and so on.
i have gone through the code and cant really see why.
also carl how did u have the Tx connected to the SSC-32 (to see if its the same as i have got it)
heres the code i modified:

// HEXAPOD 3DOF ALLOY VERSION 1.0 
// USART initialization: 9600,8N1 @ 8MHz 
#include  
//#include  

// Crystal Frequency = 7.3728MHz 

// Strings to output different servo angles to channel #0 
char MOVE_CH_0_1[] = "#0P1000\r"; 
char MOVE_CH_0_2[] = "#0P1100\r"; 
char MOVE_CH_0_3[] = "#0P1200\r"; 
char MOVE_CH_0_4[] = "#0P1300\r"; 
char MOVE_CH_0_5[] = "#0P1400\r"; 
char MOVE_CH_0_6[] = "#0P1500\r"; 
char MOVE_CH_0_7[] = "#0P1600\r"; 
char MOVE_CH_0_8[] = "#0P1700\r"; 

char QUERY_CH_0[] = "Q\r"; 

void USART_TxString(char *); 
void USART_TxChar(char sendbyte); 

int main (void) 
{ 
DDRA = 0x00;          // Make PORTA inputs 
   DDRB = 0xFF;          // Make PORTB outputs 
   DDRC = 0x00; 
   UCSRA = 0x00; 
   UCSRB = 0x18; 
   UCSRC = 0x86; 
   UBRRH = 0x00; 
   UBRRL = 0x33; 

   while (1) 
   { 
          PORTB = (PINA & 0x7F); // Get current switch status 
          if((PINA & 0x7F) != 0x7F) 
          { 
              PORTB |= 0x80; // Turn off command status LED, PORTB bit 7 

           if (~PINA == 0b00000001)          // Check Switch #0 
                  USART_TxString(MOVE_CH_0_1); 
              if (~PINA == 0b00000010)            // Check Switch #1 
                  USART_TxString(MOVE_CH_0_2); 
           if (~PINA == 0b00000100)            // Check Switch #2 
                  USART_TxString(MOVE_CH_0_3); 
              if (~PINA == 0b00001000)            // Check Switch #3 
                  USART_TxString(MOVE_CH_0_4); 
              if (~PINA == 0b00010000)            // Check Switch #4 
                  USART_TxString(MOVE_CH_0_5); 
              if (~PINA == 0b00100000)            // Check Switch #5 
                  USART_TxString(MOVE_CH_0_6); 
              if (~PINA == 0b01000000)            // Check Switch #6 
                  USART_TxString(MOVE_CH_0_7); 
      } 

      USART_TxString(QUERY_CH_0);   // Check for command complete 
      if (UCSRA & (1 << RXC)) 
         if (UDR == 'a') 
              PORTB &= 0x7F;         // Set the status LED 
   } 
} 

void USART_TxString(char *strptr) 
{ 
  unsigned char n = 0; 
  while (strptr[n] != 0x00) 
        USART_TxChar(strptr[n++]); 
}
void USART_TxChar(char sendbyte) 
{ 
    while (!(UCSRA & (1 << UDRE))); 
    UDR = sendbyte; 
} 

it may be just silly mistake i made im not sure.
any way thanks (all help appreciated)

:arrow: Dan :!:

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I wrote:

Quote:
Don't forget that most TTL communication is positive for '1' and ground for '0'.

I should have looked at the schematic myself instead of believing what I read here. SSC-32 uses true RS232 levels from an ST202 (MAX202). The DB9 connector does NOT have TTL signals on it.

Sorry if I confused anyone.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

no worries.. i only just read ur post now.. must of missed it.
i didnt realize that :roll:

:arrow: Dan :!:

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dan,

It's sending 'Q' because, well, it's sending 'Q'.

Basically, I connected the STK500/STK501 directly to the SSC-32. I'm not using HyperTerminal to display anything. I have a servo connected to channel zero of the SSC-32 and when I press one of the switches on the STK500, the SSC-32 is told to move the servo connected to channel zero to a certian angle, based on the particular switch that is pushed.

After the SSC-32 is commanded, the STK500 sends the "Query" command, 'Q' and sets the MSB LED on PORTA, bit 7 on the STK500 to show that the command sent to the SSC-32 has completed.

The reason you are continuously receiving a 'Q' on HyperTerminal is because, the main loop continuously issues the "Query" command and checks the SSC-32 for a "Busy" status when sitting idle.

If you hook your development board directly to the SSC-32 controller and attach some "Low True", resistively pulled up, switches to PORTA, bits 0 through 6, the servo connected to channel 0 will move incrementally from one switch press to the other. PORTA, bit 7 is the SSC-32 "Busy" status. Logic zero is busy and, logic one is ready.

Edit:

Also note... If you are going to use the same cable that you used with HyperTerminal and your development board, you are going to need a NULL MODEM to connect your development board to the SSC-32.

If you are going to re-jumper and use TTL levels, the NULL MODEM won't be needed. But realize, that you will have to re-jumper your development board and the SSC-32 to use raw TTL level communications.

I have been playing with this all afternoon and it is actually pretty neat.

Between the microcontroller datasheet, the SSC-32 documentation and, the example program that I have provided you, you should have enough infomation to make some good progress with this project.

Let me know if you need anything else.

Good luck with your project.

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

oh sorry carl i dont know if i said that properly. when it constantly sends Q it does it with out me pressing anything... should that happen.
when plugged into the ssc32 the light just flickers rapidly. i have the stk500 with portA connected to the switches. maybe im misunderstanding what u are saying.

:arrow: Dan :!:

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sorry i read your edit as i was entering to post.

:arrow: Dan :!:

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Oh i see it sends Q constantly to the controller until u press an input. well thats what i thought. but when i press any of the inputs no string is sent to move servo :? its probably just something im doing or because i changed the code.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

PORTB connects to the LED's. PORTA connects to the switches.

And, yes, 'Q' is continuously sent to the SSC-32 to check it's status - meaning, you don't have to do anything to cause this action. If the SSC-32 status comes back 'a', PORTB bit 7 (LED 7) is set. If the status comes back anything else, PORTB bit 7 (LED 7) is cleared.

The I/O indicator LED on the SSC-32 will be on continuously as the STK500 is constantly asking the SSC-32 for the current status.

If all is connected correctly, the STK500 LED's 0 through 7 shouls only come on when SW 0 through 7 are pressed.

If all of the STK500 LED's are flickering without you pusing a switch, you need to check your wiring.

Also, if your power supply is being shaired by both the STK500 and the SSC-32 and you have a servo connected, be sure you have enough current sourcing ability to supply the entire system. If you don't have a big enough power source, you'll get lots of strange effects.

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK sweet ive managed to get it to send the strings now.. but still no movement of servo on the ssc-32 board.. mine is wired just like you say. i also have powered the ssc-32 on its own seperate form the stk supply.
i now know its recieving the command so it should move the servo. im getting more and more confused by this now :oops:

:arrow: Dan :!:

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, John...

When I was working on your program I noticed that your BAUD rate was wrong. And, make sure that you are using a crystal on the STK500 that will provide a BAUD RATE of something less then 1% error. That is why I used a 7.3728MHz crystal on the STK500 - it provides a theoretical error of 0%. Also, you had the PARITY set. It should be set to NONE. There will be no movement if the BAUD RATE, PARITY and STOP bits are not correct.

With the exception of switch 7 and LED 7,when you press a switch, does the respective LED light up? You should get the respective LED turning on when switch 0 through switch 7 are pressed.

If so, the program is working and your problem is more then likely a baud rate issue.

Also, when you press switch 0 through switch 7, LED 7 should go off and come back on shortly after you release the switch. Is that happening. If LED 7 is not coming on, you are not communicating with the SSC-32 properly as, the status won't be showing that the SSC-32 is ready.

And, is the I/O LED on the SSC-32 continuously on? If not, you're not communicating with the SSC-32.

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ohhhhhhh thats probably why. i was using internal 8mhz. ill fire it up with an xtal and fix the baud rate issues. yeah it does light the leds up... program is fine. thank you so much... ill keep u posted

:arrow: Dan :!:

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dan,

I put an 8.000MHz crystal in my STK500 and the SSC-32 will not work. At 115.2K BAUD an 8.000MHz crystal introduces an 8.5% error in the BAUD RATE.

Are you still running at 9600 BAUD? An external 8.000MHz crystal on the STK500 at 9600 BAUD is an error of only 0.2%

But, if you are using the internal oscilator, it would be anyone's guess as to what the percent of BAUD RATE error would be.

But I would still like to know specifically what you are seeing...

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

Last Edited: Sat. Jun 24, 2006 - 01:12 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

well the led on the SSC-32 is almost constantly on (kinda flickers) when i press a switch.. PB7 led turns off and the led coorosponding to the switch i just pressed turns on. that seems right dosent it... but im a little out of the know when it comes to changing my code to use external xtal and baudrate settings. have a 16 mhz xtal. im gunna whip out the data book but if u have any pointers for my that would be sweet.

:arrow: Dan :!:

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

yes still at 9600- i have an 8 mhz xtal that i could try.. how do i make the stk500 use the xtal and not internal - is it setting the fuse such as
ext crystal/resonator High freq; start up time 16k CK+64ms and so forth.
sorry i keep posting the same time u do

:arrow: Dan :!:

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dan,

16.000MHz also represents a 0.2% BAUD RATE error.

Ok, in AVRStudio, go to the Fuses tab in the "Top Module." The second tab from the left.

Scroll all the way down to the very bottom and check the selection that says "Ext. Crystal/Resonator High Freq.; Start-up time: 16K CK + 64 ms; [CKSEL=1111 SUT=11]"

While you're here, you might as well set the BOD too. Check "Brown-out detection level at VDC=4.0 V" and "Brown-out detection enabled."

In the program, change UBRRH to 0x01. Change UBRRL to 0x03.

This will set your BAUD RATE to 9600 BAUD.

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, I thought you said you were going to use a 16.000MHz crystal.

For an 8.000MHz crystal, set the Tab stuff as said above but: in the program, change UBRRH to 0x05. Change UBRRL to 0x01.

At 8.000MHz it's still only a 0.2% BAUD RATE error.

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

Last Edited: Sat. Jun 24, 2006 - 02:02 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you have an STK500 manual you should be looking at that.

On the STK500 development board, put a jumper block on header XTAL1 and put a jumper block at header OSCSEL at pins 2 & 3.

That's how my STK500 is configured.

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

Last Edited: Sat. Jun 24, 2006 - 01:49 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dean.

By the way! I didn't mean to steal your thunder on this thread. It's just that this thread proded me into doing something that I have been wanting to do for a couple on months now.

So, if you're ok with me doing this and, Dan is ok with me learning about the internals of the SSC-32 while I'm helping him, I guess you can be working on your next great BUTTLoad project, Dan gets some help, and I get to do what I would have otherwise been just too lazy to put any time or effort into.

Thanks!

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi.
Sometimes a little reminder of basic electronics ie RS 232/TTl levels dos'nt hurt any of us "LEST WE FORGET"

all the best Lyn

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I absolutely have No probs with this at all carl im actually enjoying learning from someone so much more experienced than my self.

i dont know what i have done to the code but i sorta screwed it up so i have to start it again.. it wont send anythin at all now... but i set everything for the xtal and it communicates fine..
i think it will work though.

:arrow: Dan :!:

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

NEWS HEADLINE (" CARL IS BRILLIANT") it works WOOOOOHOO
Carl your the best . thanks SOOOO SOO much for your patience with a newb i really mean it

:arrow: Dan :!:

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

microcarl wrote:
Dean.

By the way! I didn't mean to steal your thunder on this thread. It's just that this thread proded me into doing something that I have been wanting to do for a couple on months now.

So, if you're ok with me doing this and, Dan is ok with me learning about the internals of the SSC-32 while I'm helping him, I guess you can be working on your next great BUTTLoad project, Dan gets some help, and I get to do what I would have otherwise been just too lazy to put any time or effort into.

Thanks!

Carl, I thought you'd know me well enough by now to realise that I wouldn't get offended! The aim here is to help, to teach and to get the darn thing working - not to stroke our own egos! You're right -- I have ButtLoad to do that with :). Speaking of which, I really need to get the last but solved in 1.4 so I can move on, the project's been killing me for months :S. On an unrelated note if you have any ideas for my next project my email/PM box is always open, because I'm drawing a blank.....

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dan,

Great! I'm glad you got your SSC-32 working...

By the way... I'm not briliant and neither is the majority of the individuals on this forum.

The key is small steps, learning as you go. In addition to that, learning how to use the tools at your disposal, such as the datasheets for the components that you are using. And finally, the most important factor, by far, is persistance - not giving up when you are streached beyond your comfort zone.

If anyone here really is brilliant, its because they exibit these traits.

So take byte-sized steps, apply what you learn with real hardware, don't be afraid to streach beyond your comfort zone, and BE PERSISTANT!

That's what brilliance really is!

Dean, Lee, Smileymicros, Jesper, Johan, Svofski and, many others are much more brilliant then I.

I'm glad I could help.

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

your too modest carl... you are right though. but im kinda glad ive had this problem because i have learned so much. i must note though i havent got it fully working it only moves the servos sometimes and sometimes it randomly moves it may be baud rate. also i am indeed using 16mhz. im going to try and figure it out in the data book...

:arrow: Dan :!:

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dan,
Old geezer advice: Keep a logbook of project progress and ideas! Things fade with age and lifes other distractions.

Carl summed up the spirit of this forum pretty well. Everyone can contribute.
We all develop our specialist domain knowledge. I am continually amazed by both the breadth of knowledge lurking amongst the members here, and their joy in distributing it so freely.

Makes you smile!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

yeah your absolutely right. thanks for your advice. i will make notes of all of this useful information. :lol:

:arrow: Dan :!:

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hello Carl. you will be happy to know i have been using the data book and was looking up the uart regs. but when i came accross the baud regs. u said that

UBRRH = 0x05; 
UBRRL = 0x01; //At 8mhz for 9600 baud

i dont see how that equals 9600 baud :? i may be incorrect but i dont know.

:arrow: Dan :!:

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

danrulz01 wrote:
hello Carl. you will be happy to know i have been using the data book and was looking up the uart regs. but when i came accross the baud regs. u said that

UBRRH = 0x05; 
UBRRL = 0x01; //At 8mhz for 9600 baud

i dont see how that equals 9600 baud :? i may be incorrect but i dont know.

:arrow: Dan :!:

Yeah, It made sense then but, it sure doesn't now. Deffenitely a brain fart! I'm supprised some of the GURU's didn't pick up on it. It just goes to show that you should always have your own fingers doing the walking through the datasheet.

It should be

UBRRH = 0x00
UBRRL = 0x51

By the way, this could be written as:

UBRR = 0x0051

, as well.

Sorry, I worked on this thing all day. I don't know what I was thinking. I guess I just spaced out.

But even after working on this thing all day, I guess you can see how bugs can creap into a project.

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

oh yeah they are easy to get in your code.

thanks again Carl much appreciated!

:arrow: Dan :!:

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just to let you know Dan, I'm still working on this thing. I've gone from working pretty decent to, total non-functionality. But it's all fixable.

Basically, I'm just figuring out how to effectively use the commands and their responses. I have no concrete plans for any project. Maybe I'll just come up with a general library, or something, for the thing.

By the way, change the 'a' to '.'. Another case of mind blur, not to metion the literal vision blur.

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

thats aweosme carl... i am still trying to get mine to work perfectly... i am using it for the lynxmotion 6 arm on the 4wd1 rover... but i hope to use it with the alloy hexapod in the near future... im also planning on utilizing an eeprom to store different strings for different movement paterns. dont u think that controller was great value.

:arrow: Dan :!:

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

im also still curious... should it still send "junk data" in the br@y's terminal? it does weird things when plugged into the servo controller.. it only moves sometimes.. is that what yours does? could it be because of the 0.2% error?

cheers

:arrow: Dan :!:

Last Edited: Sun. Jun 25, 2006 - 12:06 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dan,

I don't use br@y's terminal, though, I've had reliable operation with HyperTerminal. Also, I've got the software that LynxMotion sells. they all proove to provide reliable communications with the SSC-32 and, the SSC-32 itself, seems to be rock solid. I wonder if you have the power wiring correct of if there might even be something wrong with your SSC-32., or the STK500.

As for the STK500, I've shown you the program that I'm using and, while not the most effecient, or even the best or optimum program for controlling the SSC-32, it is working quite reliably.

I only have one servo hooked to my SSC-32 during these experiments. I am assuming that you have 5 or 6 servos connected to the SSC-32. Are your power supplies able to supply enough current to the SSC-32 with all of the servos running? Are you using large enough wiring to the SSC-32. I know that when I run my robotic arm with all six servos, a fresh nine volt battery only lasts about 10 minutes and, the battery even gets warm while in use.

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

i am using only the one servo whilst in the testing process. what happens when i press buttons: servo sits for a while then moves, press a different button and servo may not move (or twitches) dont press anything and servo might move randomly by its self. im really leaning toward the idea that its how my uart is set up corectly (i could be wrong)... also how is yours wired to recieve the transmission (which pins wire to what)

:arrow: Dan :!:

Last Edited: Sun. Jun 25, 2006 - 12:21 PM

Pages