Serin again

marcos.placona

Senior Member
Hi, this is just a followup to my previous thread on serin.

I was indeed missing the N in front of the 2400 :p

I'm now stuck on something else, and was hoping someone here could be able to help.

I have this program that expects a number coming from the serial port. As far as I understood, I can send a number like 123 via serial, but it will be read in different bits i.e.

SerIn 1,N2400,("data"),b0,b1,b2

where b0 = 1, b1 = 2, b2 = 3. I was wondering if there's any way to get this number to be a whole number again once it's received by the picaxe.

I thought about something on the lines of

number = b0 * 100
number = number + b1 * 10
number = number + b2

Obviously this didn't work :D, but I reckon the logic is not too far away from right.

Also, I noticed that when I pass "data123" via terminal link and try to serout the variables like:

serout 0, N2400, (b0,b1,b2,CR,LF)

I get something like "'23" or "+23" almost as if it was replacing b0 with a funny character.

Trying using b3,b4,b5 brings up the same results, as it will always skip t least one variable.

Could anyone give me a light here?

Thanks in advance
 

gbrusseau

Senior Member
Math is carried out in sequence order so "number + b1 * 10" would take number, add b1 to it and then multiply that results by 10. Or logically NUMBER = (NUMBER+b1)*10.

Instead use: number = b1 * 10 + number

number = b0 * 100
number = b1 * 10 + number
number = b2 + number

Your explaination of passing "data123" via terminal link etc... is very confusing to me. Do you mean you are sending the data "123" from a terminal to the PICAXE input pin and back out the PICAXE to the terminal , where the terminal displays '23 or +23? If so, the terminal will see the number "1" as an ASCII code 1, which I think is SOH (start of headin), not the number 1
 
Last edited:

marcos.placona

Senior Member
Ok, I'll try explaining it better.

I'm trying to use the programming editor's terminal to send the following string:

data123

As data is my validator on the serin (SerIn 1,N2400,("data"),b0,b1,b2)

I would expect b0,b1,b2 to be 1,2,3 respectively.

While b1 and b2 are correct, b0 always comes back as a funny character. I think I'm doing something wrong here, but i can't figure out what it is.
 

Dippy

Moderator
If you are sending "data123" from Terminal then the "123" are separate ASCII chars.
So, b0 = "1" = 49
etc.

Also, think of the sequence in which PICAXE does its arithmetic.

Check this to see what I mean:

b0 = "1"
b1 = "2"
b2 = "3"

b0 = b0-48*100
b1 = b1-48*10
b2 = b2-48

b3 = b0+b1+b2

(B3 will equal 123)

Sadly, I don't understand the second part of your question :(
 

hippy

Ex-Staff (retired)
If the three numbers are ASCII characters, there's a post somewhere on the forum explaining how to do and why it works, but basically ...

Serin ... , b1, b2, b3
b0 = b1 * 10 + b2 * 10 + b3 - 5328

If they are actually byte values ...

Serin ... , b1, b2, b3
b0 = b1 * 10 + b2 * 10 + b3
 
Last edited:

marcos.placona

Senior Member
Thanks Dippy and Hippy, your examples made a lot of sense.

However, after doing:

b0 = b0-48*100
b1 = b1-48*10
b2 = b2-48

b3 = b0+b1+b2

I can see from the debug screen that b3 == 123, which is the desired number. If now I wanted to have this number printed in the terminal (that's the main purpose of it), I would need to turn it into ASCII again is that correct?

How could I do that?

Thanks a lot
 

MPep

Senior Member
Use SEROUT, from the manual:
Code:
The # symbol allows ASCII output. Therefore #b1, when b1 contains the data
126, will output the ASCII characters “1” ”2” ”6” rather than the raw data 126.
Hope his helps.

MPep.
 

marcos.placona

Senior Member
So if I understand it correctly, by using #b3 (as per my example above), I could use it to for example send data serially to an LCD?
 

hippy

Ex-Staff (retired)
Yes ...

b3 = 123
SerOut ... ( #b3 )

will send the characters "1", "2" then "3" to the LCD.
 

marcos.placona

Senior Member
Thanks very much for that Hippy, however I don't seem to be getting it quite right for some reason.

When running my code on the simulator, I get this:


As you can see, it's setting b3 to 123, which is fine. Now, if I wanted to use this value to for example move a servo, I'd be inclined to do something like:

servo servoPin, b3

As you mentioned earlier, to have it turned into a string, I'd need to use it like:

servo servoPin, #b3

Which should work till an extent, as when I try:

serout 0, N2400, (#b3,CR,LF), I get the value of 92.

This is the bit of code that is supposed to print #b3

Code:
moveServo:
	b0 = b0-48*100
	b1 = b1-48*10
	b2 = b2-48
	b3 = b0+b1+b2
	'servo servoPin, b3
	serout 0, N2400, (#b3,CR,LF)
	return
}
What am i missing here?

Thanks
 
Last edited:

hippy

Ex-Staff (retired)
What am i missing here?

Not sure, this works for me ...

#Picaxe 08M
b3 = 123
serout 0, N2400,(#b3, CR, LF)

How are you getting this "92" ? In the simulator, on a real chip ? How do you know it's "92" ?
 

marcos.placona

Senior Member
You're right... It would display 251 sometimes for some reason, but i think it's because I wasn't giving it enough time to clear out b3.

I've just added a b3 = 0 at the beginning of the sub, and it's sorted.

One thing I can't understand though, is how does one send the string to the servo command?

servo servoPin, #b3

Gives me a compiling error, and

servo servoPin, b3

Acts nonsense, as I reckon it's not really sending the integer to it (i.e 123)
 

MartinM57

Moderator
One thing I can't understand though, is how does one send the string to the servo command?

servo servoPin, #b3

Gives me a compiling error
That's because it is incorrect to send a string to the servo command - you send a variable (e.g. b3, which is holding a number) or a constant (e.g. 123). See the servo command in Manual 2

servo servoPin, b3

Acts nonsense, as I reckon it's not really sending the integer to it (i.e 123)
Try servo servoPin, 123 - that would definitely send 123 to the servo - what happens then? (and "acts nonsense" might make sense to you looking at your servo, but makes no sense at all to us - what is actually happening?)
 

marcos.placona

Senior Member
Right, so if 123 should work,

shouldn't this also work

Code:
SYMBOL servoPin = 2
SYMBOL servoStart = 70

init:{
	servo servoPin, servoStart
	b1 = servoStart
}

main:
	SerIn 1,N2400,("data"),b0,b1,b2
	gosub moveServo
		
	goto main

{

moveServo:{
	b3 = 0
	b0 = b0-48*100
	b1 = b1-48*10
	b2 = b2-48
	b3 = b0+b1+b2

	if b3 > 70 then
		servo servoPin, b3
	end if
	'serout 0, N2400, (b3,CR,LF)
	return
}
When from the terminal I send "data70"?

The way I'm saying it "acts all weird" is that when I send data070, sometimes it will go to the very start, and sometimes it will move to the middle, sometimes start again and etc. It doesn't seem to be holding the value, or for some reason it's messing up with the variables.

I would think that passing data120 would be consistent, and if the servo is already at this position, it wouldn't move, but it seems to move for some reason.

Thanks for the help guys, you're being great!
 

MartinM57

Moderator
Well I'm confused on a number of levels:
- the code looks OK in terms of manipulating the received ASCII data back to a number in b3
- but if you are sending "data070" then you're IF statement will never be true, so the second servo command will never be issued
- why are you sending an "out of range" value (needs to be between 75 and 225, so 70 is invalid)?
- why are you not doing what the manual says, and doing servopos commands after the initial servo command?

Have you gome back to basics and checked that everything works without the complexity of the serin?

Code:
#PICAXE 08M
SYMBOL servoPin = 2
SYMBOL servoStart = 75

init:
	servo servoPin, servoStart

main:
	for b3 = 75 to 225 step 5
		servopos servoPin, b3
		pause 100
	next
	for b3 = 225 to 75 step -5
		servopos servoPin, b3
		pause 100
	next

end
 
Last edited:

hippy

Ex-Staff (retired)
You're right... It would display 251 sometimes for some reason, but i think it's because I wasn't giving it enough time to clear out b3.

I've just added a b3 = 0 at the beginning of the sub, and it's sorted.
I don't understand that. b3 doesn't need to be cleared so I'm not sure how this fixes anything.

Is this in simulation or on a real chip ?
 

marcos.placona

Senior Member
- but if you are sending "data070" then you're IF statement will never be true, so the second servo command will never be issued
- why are you sending an "out of range" value (needs to be between 75 and 225, so 70 is invalid)?
- why are you not doing what the manual says, and doing servopos commands after the initial servo command?
This is correct, I was missing some things here, but fixed them thanks to your example. I wasn't using servopos because I thought servo would do the same (*lack of reading I admit :p*), but at least not I understand exactly what it does

I've made a few changes to my code, and not it looks like this:

Code:
SYMBOL servoPin = 2
SYMBOL servoStart = 75

init:{
	servo servoPin, servoStart
}

main:
	'Reset variables
	b0 = 0
	b1 = 0
	b2 = 0
	
	SerIn 1,N2400,("data"),b0,b1,b2
	gosub moveServo
		
	goto main

{

moveServo:{
	'Don't even calculate if b0, b1 or b2 = 48 (0), just set it as 0 and keep going
	if b0 = 48 then
		b0 = 0
	else
		b0 = b0-48*100
	end if
	
	if b1 = 48 then
		b1 = 0
	else
		b1 = b1-48*10
	end if
	
	if b2 = 48 then
		b2 = 0
	else
		b2 = b2-48
	end if
	
	'Add b0, b1, b2 which will make b3 a suitable value to set the servo position
	b3 = b0+b1+b2
	pause 100

	servopos servoPin, b3
	pause 100

	serout 0, N2400, (#b3,CR,LF)
	return
}
It's really a lot more stable, and works partially. Sometimes for some reason, when the servo is in position 200 for example, and I want it to go straight to position 75, it will only go half way (around position 150) and stop.

Other times, when I want to to go from 75 to 225, it will also only go half way.

Funnily, sometimes it just works.

I've kept the serout 0, N2400, (#b3,CR,LF) on my code, so I can see if b3 is getting the right values, and they are always spot on, but the servo seems not to be obeying the command all the time.

When I run the code proposed by MartinM57, everything works flawlessly, so that suggests my servo is in a good state.

@hippy I tried resetting the variables, just to make sure it wasn't doing anything wrong, and to answer your question, the results I'm getting are directly from the chip (Picaxe 0.8m 9.2)

Any more suggestions as per why my servo doesn't always work as it should?
 
Top