Servo motor does not work correct

[EarlyBird2]

Looking at the code "CASE "1" is saying CASE = "1" not CASE = 1 there is a big difference. "1" is a string with ASCII value of 49 and 1 is a value of 1.

CASE works with a value and not with strings but you can use the ASCII value.
So CASE "1" should be CASE 49
and CASE "A" should be CASE 65

for example.

[cesar35]

Looking at the code "CASE "1" is saying CASE = "1" not CASE = 1 there is a big difference. "1" is a string with ASCII value of 49 and 1 is a value of 1.

CASE works with a value and not with strings but you can use the ASCII value.
So CASE "1" should be CASE 49
and CASE "A" should be CASE 65

for example.

Hello
About your question
I modified the program to SELECT CASE.para get better to understand the program.

[cesar35]

Hello
Now already understand what you said.
on the servo seems to me that something is missing he is without direction
Here is the corrected code.
thank you

@ DEVICE PIC16F876A
@ DEVICE PIC16F876A,WDT_OFF
@ DEVICE PIC16F876A,PWRT_OFF
@ DEVICE PIC16F876A,PROTECT_OFF
@ DEVICE PIC16F876A,XT_OSC
define OCS 4
ADCON1 = 7
TRISC=%10000000:PORTC=%10000000
TRISA=%11111111:PORTA=%11111111
TRISB=%00000000:PORTB=%00000000

SYMBOL SERVO1=PORTB.0 'SERVO1
SYMBOL RX_INP=PORTC.7 'RF

RX VAR BYTE
POS VAR word
POS = 1500

PROG:
serin2 RX_inp,84,600,MODATA,[wait("PC"),RX,DEC POS]

SELECT CASE RX
CASE 65 'A
GOSUB FRE
CASE 66 'B
GOSUB TRA
CASE 67 'C
GOSUB DIR
CASE 68 'D
GOSUB ESQ
CASE 69 'E
HIGH PORTB.0
pauseus 1500 + pos
LOW PORTB.0
Pause 20
END SELECT
GOTO PROG

FRE:
PORTC.0 = 0
PORTC.1 = 1
PORTC.2 = 1
PORTC.3 = 0
RETURN
TRA:
PORTC.0 = 1
PORTC.1 = 0
PORTC.2 = 0
PORTC.3 = 1
RETURN
ESQ:
PORTC.0 = 1
PORTC.1 = 0
PORTC.2 = 1
PORTC.3 = 0
RETURN
DIR:
PORTC.0 = 0
PORTC.1 = 1
PORTC.2 = 0
PORTC.3 = 1
RETURN

MODATA:
PORTC.0 = 0
PORTC.1 = 0
PORTC.2 = 0
PORTC.3 = 0
GOTO PROG

[Demon]

If the PC is not sending A, B, C and D in the proper sequence, the motor will not turn, MODATA will hold the motor in place.

Robert

[HenrikOlsson]

Hi,

CASE works with a value and not with strings but you can use the ASCII value.
So CASE "1" should be CASE 49
and CASE "A" should be CASE 65

Both are equally fine.
CASE "A", CASE 65, CASE $41, CASE %01000001 all works and does the exact same thing.

/Henrik.

[EarlyBird2]

Hi,


Both are equally fine.
CASE "A", CASE 65, CASE $41, CASE %01000001 all works and does the exact same thing.

/Henrik.

That is useful information.
The mystery deepens then because the way CASE was written was not the problem. But CASE "A" did not work but CASE 65 does. Or does it? Is the question now. I need more feedback!

[HenrikOlsson]

Hi,

But CASE "A" did not work but CASE 65 does. Or does it?

I have no idea... All I can say is that CASE "A" works perfectly fine for me, I use it extensively in several applications, as an example, here's a snippet:

Select Case CmdBuffer[0]                     ' Decide what to do based on the first character in the buffer

CASE "A", "a"                                ' Set accleration feedforward
 GOSUB ReadCmdBuffer
 If ValueReceived then pid_Acc_kFF = RxValue
   MenuLine = 6
   PrintLine = 1

/Henrik.