Picaxe + AppInventor Orientation Sensor

JSDL

Senior Member
Hi all, I am trying to send some orientation sensor readings from a simple app created in AppInventor to a Picaxe 08M2 over an HC-06 BT->Serial module. The connection is made successfully, but I am not seeing the correct pitch/roll values.

Here is the BASIC code:
Code:
setfreq m32
symbol pitch=b0

main:

serin c.3,t19200_32, pitch
sertxd(#pitch,cr,lf)
goto main
I have attached an image of the data transfer part of the app. The values I am receiving hover around the 50 range and only change slightly with movement of the phone. I am not sure if the serin command simply cannot keep up with the data stream, or if there is another problem elsewhere. I even tried serin with a qualifier, but the same results. Also, how/can Picaxe deal with the negative integers returned in one direction of the pitch/roll? I am basically trying to mimic the project below with a Picaxe. Any assistance would be greatly appreciated.

orientation.jpg

http://www.instructables.com/id/3D-Printed-Maze-Controlled-by-Your-Android-Device/
 

hippy

Technical Support
Staff member
You probably need a # as in ...

serin c.3,t19200_32, #pitch

And the text you are sending will have to end with a non-ASCII character.

You might also have to make 'pitch' a word variable depending on what values it holds.
 

JSDL

Senior Member
ok, so after several hours spent on this (and lots of frustration),I've got some working code, sort of. Here it is:

Code:
setfreq m32
HSerSetup B115200_32, %010
init:

symbol orientation_RX=c.1
symbol roll_val=b0
symbol pitch_val=b2
symbol pitch_dir=b4
symbol roll_dir=b5
symbol servo_pitch_mapval=w4
symbol servo_roll_mapval=w5
symbol angleRoll=b10
symbol anglePitch=b11
symbol pitchHM=b12
symbol rollHM=b13
symbol servo_roll=c.4
symbol servo_pitch=c.2
pitchHM=150
rollHM=150

servo servo_roll,pitchHM
servo servo_pitch,rollHM

main:

Do 
b1 = 1
b3 = 1
	Do
		HserIn w0
		HserIn w1
	Loop Until b1 = 0
		

if pitch_val > 90 then
	pitch_val=255 - pitch_val
	'pitch_val=pitch_val XOR %11111111
	pitch_dir="N"
else
	pitch_dir="P"
end if

if roll_val > 90 then	
	roll_val=255-roll_val
	'roll_val=roll_val XOR %11111111
	roll_dir="N"
else
	roll_dir="P"
end if

if roll_dir="P" and pitch_dir="P" then
	
	servo_roll_mapval=roll_val * 25 / 90 + 150
	angleRoll=servo_roll_mapval - 150
	servo_pitch_mapval=pitch_val * 25 / 90 + 150
	anglePitch=servo_pitch_mapval - 150
	servo_pitch_mapval=pitchHM + anglePitch
	servo_roll_mapval=rollHM + angleRoll
		
elseif roll_dir="P" and pitch_dir="N" then
	
	servo_roll_mapval=roll_val * 25 / 90 + 150
	angleRoll=servo_roll_mapval - 150
	servo_pitch_mapval=pitch_val * 25 / 90 + 150
	anglePitch=servo_pitch_mapval - 150
	servo_pitch_mapval=pitchHM - anglePitch
	servo_roll_mapval=rollHM + angleRoll
	
		
elseif roll_dir="N" and pitch_dir="P" then
	
	servo_roll_mapval=roll_val * 25 / 90 + 150
	angleRoll=servo_roll_mapval - 150
	servo_pitch_mapval=pitch_val * 25 / 90 + 150
	anglePitch=servo_pitch_mapval - 150
	servo_pitch_mapval=pitchHM + anglePitch
	servo_roll_mapval=rollHM - angleRoll

	
elseif roll_dir="N" and pitch_dir="N" then
	
	servo_roll_mapval=roll_val * 25 / 90 + 150
	angleRoll=servo_roll_mapval - 150
	servo_pitch_mapval=pitch_val * 25 / 90 + 150
	anglePitch=servo_pitch_mapval - 150
	servo_pitch_mapval=pitchHM - anglePitch
	servo_roll_mapval=rollHM - angleRoll

end if

Hserout 0, ("PITCH: ",#servo_pitch_mapval, " ",pitch_dir," ", "ROLL: ",#servo_roll_mapval," ", roll_dir,cr,lf)

servopos servo_pitch, servo_pitch_mapval
pause 20
servopos servo_roll, servo_roll_mapval
pause 20

Loop
the values read in correctly via Hserin, and they get scaled properly between 125 and 175 for transfer to the SERVOPOS command (this is intentional for a maze game I am making, only want max 25 degrees of tilt), however the values are constantly switching between 150 and the correct translated value, causing the servos to jitter and not really move to the position value generated by the scaling math, as it does not have time to respond since it immediately goes back to 150. Any ideas on how to optimize this code, am I missing something obvious here, or is this just a limitation I am reaching with the microcontroller? Any help would be appreciated. Thanks in advance.
 

hippy

Technical Support
Staff member
Code:
	Do
		HserIn w0
		HserIn w1
	Loop Until b1 = 0
That won't work reliably. You need to check you have received each byte and it's not guaranteed you will be receiving the two bytes in the correct order.

For an HC-06 you will likely be receiving ASCII data not binary data, so it's not even clear what data you are receiving. It is somewhat surprising it appears to work because I am not sure what data is being sent or is being received.

Unless the data can be received with a SERIN I would have expected an X2 with background serial receive would have to be used.

Have you checked what data is being received from the HC-06 on a PC using a terminal emulator ? That would be my starting point.

Second step would be to have the PICAXE read the HC-06 data and simply display it, to ensure it matches what is being sent, before trying to use that data with actual servos.
 

JSDL

Senior Member
how can I ensure I am receiving the two bytes in the correct order using hserin? I quite reliably received the two bytes in the correct order using serin with a qualifier (verified using sertxd to a terminal), however, I realized this could not be used in conjunction with the servo commands in the same program as serin temporarily disables the timer for the servo. The app talking to the HC-06 is sending pitch and roll numeric values from the orientation sensor (rounded to the nearest integer). As mentioned with serin, I was able to receive them in the correct order and output them to the terminal. With hserin, they are being received sometimes in the incorrect order (as verified with an hserout command to a terminal), but I am not sure how to ensure correct order. Does the M2 series not support background receive up to 2 bytes?
 

PhilHornby

Senior Member
I can't spot what's going on with your hserin ... but I just noticed that your code contains 'setfreq M32'. However, the manual says "The servo command will function correctly at 4 or 16MHz (M2/X1 parts)."
 

hippy

Technical Support
Staff member
how can I ensure I am receiving the two bytes in the correct order using hserin?
Probably by sending a prefix byte before the two data bytes, ensuring that the timing is appropriate for a PICAXE to detect them reliably.

If you allow -127 to +127 as data ( $81 to $FF and $00 to $7F ) that allows $80 (128/-128) to be used as a unique prefix byte.

Alternatively. if relying upon a time gap between those two bytes to synchronise, you need to ensure you are in a gap, have received all previous bytes, before taking the two bytes in. Untested ...

Code:
; Wait for first ( or second ) byte
w1 = $100
Do
  HSerIn w1
Loop Until w1 < $100

; Ensure there are no more bytes
Do
  w1 = $100
  Pause 10 ; <-- May have to adjust this
  HSerIn w1
Loop Until w1 < $100

Do
  ; Read two consecutive bytes
  w1 = $100
  w2 = $100
  Do
    HSerIn w1
  Loop Until w1 < $100
  Do
    HSerIn w2
  Loop Until w2 < $100
  ; Report bytes
  SerTxd( "w1=", #w1, TAB, "w2=", #w2, CR, LF )
Loop
 

PhilHornby

Senior Member
The original Arduino code contains pitch = Serial.parseInt(); and roll = Serial.parseInt(); so there's more than two bytes arriving from the HC06 (as already discussed in Post #2).

I would think that either the Android app. needs amending to send more easily processed data (another learning curve, I know!) - or maybe add a 2nd 08M2 ... which does "Serin # etc" and then writes out two binary bytes for the main 08M2 to act upon. Or switch to a 20X2, (but the ASCII to binary conversion code would still need adding).
 

JSDL

Senior Member
just to make sure I understand the hserin buffer correctly for M2 parts, so the hserin command takes the first byte available in a 2 byte buffer then copies it to a variable, so for example:

Code:
hserin w0
would save a byte in the buffer to w0. However, if a second byte entered the buffer before hserin read the first byte, would the second byte overwrite the first byte, or would they both exist in the buffer until they were read by hserin? I am not really understanding the two byte buffer because I read another post that said if the first byte is not read quickly enough, it will get overwritten by the second byte, but I thought the buffer was 2 bytes wide?
 

hippy

Technical Support
Staff member
No bytes get overwritten AFAIR; any after the second will be lost.

You can set up a test program which sends one, two or more bytes out and back into the HSERIN pin, then read what you get back.

Something like this though you cannot use both HSEROUT and SERTXD on an 08M2 -

Code:
#Picaxe 18M2
#Terminal 4800
HSerSetup B4800_4, %000
Do
  HserOut 0, ("ABCD")
  Pause 1000
  Do 
    w0 = -1
    HSerIn w0
    If b1 = 0 Then
      SerTxd( b0, CR, LF )
    End If
 Loop Until b1 <> 0
 SerTxd( "<Empty>", CR, LF )
Loop
 

JSDL

Senior Member
Just out of curiosity, is the -1 just used as an invalid value, or is there significance to the negative value? Am I correct in thinking this has to do with 2's complement?
 

PhilHornby

Senior Member
Have you taken on-board, my point in Post #8 - that the data from the Android app., via the HC-06 is not two binary bytes - it's an ASCII string of characters?

Or am I wrong? (It's been known :D)
 

PieM

Senior Member
Have you taken on-board, my point in Post #8 - that the data from the Android app., via the HC-06 is not two binary bytes - it's an ASCII string of characters?

Or am I wrong? (It's been known :D)
I think so
For Picaxe (with serin), in AppInvent, I use:

Code:
call BluetoothClient1.[B]SendBytes[/B][INDENT]                      list           make a list           get xx
[/INDENT]
[INDENT]                                                           get yy
[/INDENT]
 

hippy

Technical Support
Staff member
Just out of curiosity, is the -1 just used as an invalid value, or is there significance to the negative value? Am I correct in thinking this has to do with 2's complement?
It's just a convenient trick for putting a non-zero value into the MSB of the variable HSERIN reads into. When a byte is read the MSB is zeroed, if not the MSB remains non-zero.
 

hippy

Technical Support
Staff member
Have you taken on-board, my point in Post #8 - that the data from the Android app., via the HC-06 is not two binary bytes - it's an ASCII string of characters?
That is my understanding too. It sends the data as one long text string. The original code uses something like -

Bluetooth1.Send.Text = Join( pitch + "," + roll + "<CR>" )

I would expect that to send out a single string as multiple ASCII characters, for example -

"-2518,7834<CR>"

In traditional Basic parlance, the number would be auto-converted to a string using STR$() rather than CHR$().

That's why the first step is to check what the HC-06 is actually outputting. Though similar could be achieved by sending via Bluettoth and putting that data in a label box in the AI2 app -

var = Join( pitch + "," + roll + "<CR>" )
Bluetooth1.Send.Text = var
Label1.Text = var

If it is sending a string of ASCII as above, that can be read with -

SERIN PIN, BAUD, #pitch, #roll

But as noted messes with SERVO because SERIN is blocking. The same cannot be read using two consecutive HSERIN.

There is also an issue that any minus signs would be ignored. The string would need to have a plus forced if non-negative, then read with -

SERIN PIN, BAUD, pitchSign, #pitch, rollSign, #roll

There may be a way to send two binary bytes using AI2 but we don't know what AI2 code is being used.

I like the suggestion earlier of using two PICAXE devices. The first using SERIN to read the Bluetooth data and sending two binary bytes to the second. The second using HSERIN to read those two bytes and controlling the servo. That would also allow a timed servo loop rather than SERVO/SERVOPOS which will remove any jitter there may be.
 

JSDL

Senior Member
problem solved, I ended up using a 28X2 with background receive and a qualifier. The data fell into the appropriate variables spot on consistently. I like the idea of the two chip setup and thought of that as well, but I wanted to exhaust every

possibility (which I think I did), to get it working with a single chip. Background receive on the X2 saved the day! All is working well now and the servo moves to the desired position accordingly. I simply could not get consistent results with

the M2 chips using Hserin. The data was received, but would get out of sync quite often due to timing issues, therefore messing up the servo movements. One more question, the servo moves are quite fast, is the only way to slow them down

to step to the servo position using a FOR...NEXT loop with a PAUSE in between, or is there a better way? The Arduino has a varspeedservo library with a slowmove procedure, but I think that's essentially what it is doing. Thanks for everyone's

help.
 

PhilHornby

Senior Member
problem solved, I ended up using a 28X2 with background receive and a qualifier. The data fell into the appropriate variables spot on consistently... Background receive on the X2 saved the day! All is working well now and the servo moves to the desired position accordingly.
If you have modified the Android App ('Imagineering_maze.apk'), then I could understand what you are saying...

However, in its current form, as downloaded from the 'instructable' web site, this just can't be right :confused:

I loaded the app. onto my Huawei P9 and paired the phone with a HC-05 in slave mode. The HC-05 was connected to a (fake) FTDI-232R and plugged into my Windows 10 PC. On the PC, I used Realterm to dump the data that the phone sends.

The app. sends ASCII data like this :-
Code:
10,0[COLOR=#222222][FONT=Verdana]<lf>
[/FONT][/COLOR]10,-1<lf>
10,-1[COLOR=#222222][FONT=Verdana]<lf>
[/FONT][/COLOR]10,-1[COLOR=#222222][FONT=Verdana]<lf>
[/FONT][/COLOR]12,-1[COLOR=#222222][FONT=Verdana]<lf>
[/FONT][/COLOR]14,0[COLOR=#222222][FONT=Verdana]<lf>
[/FONT][/COLOR]15,0[COLOR=#222222][FONT=Verdana]<lf>
[/FONT][/COLOR]15,0[COLOR=#222222][FONT=Verdana]<lf>
[/FONT][/COLOR]14,-1[COLOR=#222222][FONT=Verdana]<lf>
[/FONT][/COLOR]
At rest, on a flat surface, my phone sends the following ASCII string, repeatedly: "0,0<lf>", i.e. it is sending four binary bytes -> 30,2C,30,0A

Each parameter appears to have minimum value of -30 and a maximum value of +30, depending on the phone's orientation. (I don't know if this is Phone or Android Version specific - mine's V7.0).

There is no appropriate qualifier to wait for - only a terminator. Hserin does not perform ASCII to binary conversion, so whatever values you have received, they're misinterpreted chunks of ASCII data, not the actual values of the parameters being sent. (For starters, Picaxe Basic doesn't support signed numbers).

The Manual said:
Users familiar with the serin command will note the hserin command has a completely different format. This is because the hserin command supports much higher baud rates than serin, and so is unable to process received bytes &#8217;on the fly&#8217; (e.g. by changing ASCII into binary, as with the serin # prefix), as there is insufficient time for this processing to occur before the next hserin byte is received (at high baud rates). Therefore the raw data is simply saved in the memory and the user program must then process the raw data when all the bytes have been received.
One interesting issue I had, is that my HC-05 was only running at 9600baud. This introduced a 3 second lag every time I moved the phone, while it emptied its buffer.

UPDATED
Just to add - the 'instructable' implies that the values sent are the actual angles that the phone is being held at - and that they should be constrained to ±15 (by the receiver). On my phone, they don't correspond to the actual angle of the phone (unless the Android app. is also constraining them, but to ±30 instead)
 
Last edited:

PieM

Senior Member
At rest, on a flat surface, my phone sends the following ASCII string, repeatedly: "0,0<lf>", i.e. it is sending four binary bytes -> 30,2C,30,0A

Each parameter appears to have minimum value of -30 and a maximum value of +30, depending on the phone's orientation. (I don't know if this is Phone or Android Version specific - mine's V7.0).


UPDATED
Just to add - the 'instructable' implies that the values sent are the actual angles that the phone is being held at - and that they should be constrained to ±15 (by the receiver). On my phone, they don't correspond to the actual angle of the phone (unless the Android app. is also constraining them, but to ±30 instead)
Hi,
Phone orientation sensor is -90 , +90, but this Androïd appli give OrientationSensor1.Pitch /3 and OrientationSensor1.Roll /3
to avoid negative value, its better to add 100 and use call BluetoothClient1.SendByte list make a list get....
 

hippy

Technical Support
Staff member
the servo moves are quite fast, is the only way to slow them down to step to the servo position using a FOR...NEXT loop with a PAUSE in between, or is there a better way?
The better way is to keep track of where the servo is positioned then step it towards where it should be at a timed rate. Somthing like ...

Code:
Do
  Select Case positionRequired
    Case > positionNow
      positionNow = positionNow + ? Max 225
      ServoPos ?, positionNow
    Case < positionNow
      positionNow = positionNow - ? Min 175
      ServoPos ?, positionNow
  End Select
  Pause ?
Loop
 

JSDL

Senior Member
I changed the original AI2 code to look like this for the serial comms:
AI2 maze.jpg

For the math, the pitch/roll values from the phones orientation sensor generate a number from 90 <-> 0 <-> -90, however since Picaxe does not support negative numbers, whenever either pitch or roll fell less than 0 it would return the 2's complement of the #, for example, -1 would return 255, -2 -> 254, -3 -> 253 and so on. To convert this to a positive integer, I simply XOR'ed the byte with 1's and added 1, giving me the positive representation of the number.
Code:
if pitch_val > 90 then
	pitch_val=pitch_val XOR %11111111 + 1
	pitch_dir="N"
else
	pitch_dir="P"
end if

if roll_val > 90 then	
	roll_val=roll_val XOR %11111111 + 1
	roll_dir="N"
else
	roll_dir="P"
end if
Still, the Picaxe has no way of knowing if the # is + or - since they are both positive numbers now, so I added a FLAG whereby if the number was > 0 before complementing it (meaning in the negative direction), I would set a direction variable equal to "N", otherwise "P". Then using an IF statement checking the flag, I would do the appropriate math:

Code:
if roll_dir="P" and pitch_dir="P" then
	
	servo_roll_mapval=roll_val * 25 / 90 + 150
	angleRoll=servo_roll_mapval - 150
	servo_pitch_mapval=pitch_val * 25 / 90 + 150
	anglePitch=servo_pitch_mapval - 150
	servo_pitch_mapval=150 + anglePitch
	servo_roll_mapval=150 + angleRoll
		
elseif roll_dir="P" and pitch_dir="N" then
	
	servo_roll_mapval=roll_val * 25 / 90 + 150
	angleRoll=servo_roll_mapval - 150
	servo_pitch_mapval=pitch_val * 25 / 90 + 150
	anglePitch=servo_pitch_mapval - 150
	servo_pitch_mapval=150 - anglePitch
	servo_roll_mapval=150 + angleRoll
	
		
elseif roll_dir="N" and pitch_dir="P" then
	
	servo_roll_mapval=roll_val * 25 / 90 + 150
	angleRoll=servo_roll_mapval - 150
	servo_pitch_mapval=pitch_val * 25 / 90 + 150
	anglePitch=servo_pitch_mapval - 150
	servo_pitch_mapval=150 + anglePitch
	servo_roll_mapval=150 - angleRoll

	
elseif roll_dir="N" and pitch_dir="N" then
	
	servo_roll_mapval=roll_val * 25 / 90 + 150
	angleRoll=servo_roll_mapval - 150
	servo_pitch_mapval=pitch_val * 25 / 90 + 150
	anglePitch=servo_pitch_mapval - 150
	servo_pitch_mapval=150 - anglePitch
	servo_roll_mapval=150 - angleRoll

end if
I kept the angles between +/- 25 (125 to 175 for the servopos command).

Code:
servopos servo_pitch, servo_pitch_mapval
servopos servo_roll, servo_roll_mapval
 

hippy

Technical Support
Staff member
If the bytes being sent are -90 to +90 then the values received will be those in 8-bit two's complement. To convert the 'pitch' byte -90 to +90 into 125 to 175 ...

Code:
 If pitch >= $80 Then
   servoPitch = pitch ^ $FF + 1 Max 90 * 25 / 90 + 125
 Else
   servoPitch = pitch Max 90 * 25 / 90 + 150
 End If
No need for any flag bytes to show if they were negative or not.

Note that your "@" has decimal value 64, which could be valid data. Probably better to switch that to "a".
 

PieM

Senior Member
Code:
[COLOR=Blue]If [/COLOR][COLOR=Black]pitch [/COLOR][COLOR=DarkCyan]>= [/COLOR][COLOR=Navy]$80 [/COLOR][COLOR=Blue]Then[/COLOR]
[COLOR=Black]servoPitch [/COLOR][COLOR=DarkCyan]= [/COLOR][COLOR=Black]pitch [/COLOR][COLOR=DarkCyan]^ [/COLOR][COLOR=Navy]$FF [/COLOR][COLOR=DarkCyan]+ [/COLOR][COLOR=Navy]1 [/COLOR][COLOR=DarkCyan]Max [/COLOR][COLOR=Navy]90 [/COLOR][COLOR=DarkCyan]* [/COLOR][COLOR=Navy]25 [/COLOR][COLOR=DarkCyan]/ [/COLOR][COLOR=Navy]90[/COLOR]
[B][COLOR=#ff0000]servoPitch = 150-servoPitch[/COLOR][/B]
[COLOR=Blue]else[/COLOR]
[COLOR=Black]servoPitch [/COLOR][COLOR=DarkCyan]= [/COLOR][COLOR=Black]pitch [/COLOR][COLOR=DarkCyan]Max [/COLOR][COLOR=Navy]90 [/COLOR][COLOR=DarkCyan]* [/COLOR][COLOR=Navy]25 [/COLOR][COLOR=DarkCyan]/ [/COLOR][COLOR=Navy]90 [/COLOR][COLOR=DarkCyan]+ [/COLOR][COLOR=Navy]150[/COLOR]
[COLOR=Blue]endif[/COLOR]
or in AppInvent

Image 055.png
 

JSDL

Senior Member
If the bytes being sent are -90 to +90 then the values received will be those in 8-bit two's complement.
Thanks guys great info, just to clarify, the pitch/roll value received is stored as an unsigned binary number, hence why we are testing if the value is >= 128?

If that's the case how could we differentiate between, for example, b0=%10000001 as being equal to +129 or -127, or would we just have to know we are expecting a negative number?
 

hippy

Technical Support
Staff member
Two's complement byte values will be $00 to $7F for 0 to +127, $80 to $FF for -128 to -1.

It wouldn't be possible to distinguish +129 and -127.

That +129 isn't a valid value for a data byte known to hold a two's complement byte value so we would know it means -127.

To be able to distinguish +129 from -127 one would need to use 16-bit two's complement word values; $0000 to $7FFF for 0 to +32767, $8000 to $FFFF for -32768 to -1.
 

JSDL

Senior Member
Does that mean that a number is ONLY stored as a two's complement byte value when a negative sign is in front of the number being sent/stored?
 

hippy

Technical Support
Staff member
A byte is 8-bits. How any 8-bit value is interpreted is however you want to interpret it, which will probably be influenced how the generator of the value expects it to be interpreted.

8-bits are held and stored as 8-bit no matter how its value is interpreted.
 

JSDL

Senior Member
That +129 isn't a valid value for a data byte known to hold a two's complement byte value
I guess what I am asking is how is a byte "known" to hold a two's complement byte value (not how it is interpreted)? Would it be determined by the sender, e.g if an integer with a - sign indicating negative value was sent by the app (in this case for example -1 to -90), the byte would be stored by the Picaxe in two's complement form, otherwise not?
 
Last edited:

techElder

Well-known member
To further what Hippy said, it is much like a temperature reading. When someone tells you it is "32 degrees" outside, what is the first question?

Same with "coded" numbers. Both ends have to agree on what the 8-bit number represents.

There's no way to tell from the number itself ... its just 8-bits with no units.
 

hippy

Technical Support
Staff member
I guess what I am asking is how is a byte "known" to hold a two's complement byte value (not how it is interpreted)? Would it be determined by the sender
Effectively yes. The author of the sending program will be deciding what to send or that will be implied by what the sending code does or uses.

e.g if an integer with a - sign indicating negative value was sent by the app (in this case for example -1 to -90), the byte would be stored by the Picaxe in two's complement form, otherwise not?
The PICAXE simply stores the 8-bit value received. It doesn't care or know what the byte value is, it has no concept or understanding of sign bits.

There is no sign bit in an 8-bit value until the receiving program's author decides what is being held is a two's complement number. That decision should be decided based upon what the sender decided or there will be a mismatch in understanding and the receiving program will likely not behave as expected.

As you earlier asked; what is %10000001 ? To the PICAXE it is exactly that, %10000001, and that is what will be stored. Does it represent +129 or -127 or something else ? That's up to you to decide; the PICAXE does not know and there is no way for the PICAXE to know what you will be deciding. It just knows bits are set or not, not what they mean.

Added: One thing which may help is getting away from the view that %10000001 could represent 129 or -127. It could also represent 0.5 (ish) to 64.5 if the byte were a fixed decimal point value depending on where the point were intended, and quite a few other numbers if it represented a (not very useful) floating point value.

In all cases the same binary bit pattern would be stored by the PICAXE.
 
Last edited:
Top