# PIC basic to Oshonsoft conversion

Status
Not open for further replies.

#### camerart

##### Active Member
Hi,

I'm trying to convert a piece of code written in PIC Basic to Oshonsoft basic, below:
I get most of it, apart from 'ABS' and e,g, the decimal point in 'Distance.15' and the numbers 13 and 15.
Any help appreciated.

Camerart.

Position VAR WORD
Target VAR WORD
Distance VAR WORD

Position = 1234

Main:
HSEROUT[13, "You're at position: ", DEC Position, 13]
HSEROUT["Enter new target: ",13]
HSERIN[DEC Target]

' Actual calculation starts here.
' When done the variable Distance contains the
' number of "ticks" to target in two's complement format.
Distance = Target - Position

IF Distance.15 = 0 THEN ' Distance is positive
If Distance > 1790 THEN
Distance = Distance - 3580
Endif
ENDIF

IF Distance.15 = 1 THEN ' Distance is negative
IF ABS Distance > 1790 THEN
Distance = Distance + 3580
ENDIF
ENDIF
' End of calculation, result now in Distance.

Done:
IF Distance.15 = 1 THEN ' Distance is negative
HSEROUT["CCW "]
ELSE
HSEROUT["CW "]
ENDIF

HSEROUT[DEC ABS Distance, " ticks.", 13]

Position = Target

Goto Main

#### ericgibbs

##### Well-Known Member
hi C,
Distance.15, distance is a WORD variable,
ie: 16 Bits, so Distance.15 means the 15th Bit of that Word.[ the MSBit]
The Bits are 'weighted' 15, 14, thru 1, 0

13 is the Decimal code for Carriage return
E

BTW. Oshonsoft uses the same method,, the Compiler should recognise the statement

#### camerart

##### Active Member
hi C,
Distance.15, distance is a WORD variable,
ie: 16 Bits, so Distance.15 means the 15th Bit of that Word.[ the MSBit]
The Bits are 'weighted' 15, 14, thru 1, 0

13 is the Decimal code for Carriage return
E

BTW. Oshonsoft uses the same method,, the Compiler should recognise the statement
Hi Eric,
I had to use distance as word as the variable, then distance.15 compiled in the program.

Do you know what the Oshonsoft version of ABS is?

Thanks, C.

#### ericgibbs

##### Well-Known Member
Do you know what the Oshonsoft version of ABS is?
hi C.
ABS means the Absolute value of value/number, the Sign is assumed as a positive value.
If Distance.15 = 1 then distance is a negative value
There is no Oshonsoft equivalent.

IF Distance.15 = 1 THEN ' Distance is negative
flag=1
'you could try, as I am not sure what the limits of the distance value
Distance.15=0
distance =65535-distance
IF Distance > 1790 THEN
Distance = Distance + 3580
ENDIF
ENDIF

Done:
IF flag= 1 THEN ' Distance is negative
HSEROUT["CCW "]
ELSE
HSEROUT["CW "]
ENDIF

#### camerart

##### Active Member
hi C.

[ABS
means the Absolute value of value/number, the Sign is assumed as a positive value.]

Hi Eric,
Am I correct that the sign above does not mean sign as used in angles?

Can you try this in your SIM please?, as I'm not sure quite what to expect.

C.

#### Attachments

• 1.8 KB Views: 146
Last edited:

#### camerart

##### Active Member
hi C.

[ABS
means the Absolute value of value/number, the Sign is assumed as a positive value.].
Hi Eric, [I'm not sure if the above post made any sense, so here it is again corrected.]
Am I correct that the sign above does not mean sign as used in angles?

Can you try the code in post# 5, in your SIM please?, as I'm not sure quite what to expect.

EDIT: I got mixed up between sign and sine I get it now.
C

#### jjw

##### Member
You can calculate ABS of distance ( word variable ) in Oshonsoft.

If distance.15 = 1 then
abs= 65535-distance+1
Else abs=distance
Endif

#### ericgibbs

##### Well-Known Member
hi C,
Whats the PIC type and xtal?

#### ericgibbs

##### Well-Known Member
hi,
Look at this, remember the Hserin is a ASCII string, so you must convert to a number.

In the SIM use the ? as a serial string input terminator, for a PIC change the "?" to Lf.

You could change the program section that says neg/pos and use Post#7 option if you wish.

E

#### Attachments

• 1.6 KB Views: 145
• 17 KB Views: 142

#### camerart

##### Active Member
Ok, thanks Eric. C.

#### jjw

##### Member
hi C.
ABS means the Absolute value of value/number, the Sign is assumed as a positive value.
If Distance.15 = 1 then distance is a negative value
There is no Oshonsoft equivalent.

IF Distance.15 = 1 THEN ' Distance is negative
flag=1
'you could try, as I am not sure what the limits of the distance value
Distance.15=0
distance =65535-distance
IF Distance > 1790 THEN
Distance = Distance + 3580
ENDIF
ENDIF

Done:
IF flag= 1 THEN ' Distance is negative
HSEROUT["CCW "]
ELSE
HSEROUT["CW "]
ENDIF
I think this is not right:
...........

Distance.15=0
distance =65535-distance

...........

For example distance -1 as unsigned word is 65535.
Distance.15=0 -> distance = 32767
65535 - distance= 32768, but it should be 1

#### ericgibbs

##### Well-Known Member
'you could try, as I am not sure what the limits of the distance value
hi jj,
I did say that I was not sure if 'camerart' is using signed or unsigned values.
Oshonsoft does not support signed WORD values.
I assumed that the '16 bit counter' POSCNT, in the 18F2431 PIC would roll down thru .... 1,0,65535, 65534.....
It is possible to preload the CAP2CNT registers with 3599 [359.9 deg] decimal., as was done in the earlier programs I posted, which all work on my hardware.

Perhaps the OP will clarify that point.

E

#### camerart

##### Active Member
hi jj,
I did say that I was not sure if 'camerart' is using signed or unsigned values.
Oshonsoft does not support signed WORD values.
I assumed that the '16 bit counter' POSCNT, in the 18F2431 PIC would roll down thru .... 1,0,65535, 65534.....
It is possible to preload the CAP2CNT registers with 3599 [359.9 deg] decimal., as was done in the earlier programs I posted, which all work on my hardware.

Perhaps the OP will clarify that point.

E
Hi Eric,

Just to clarify! IMPORTANT!! What was:
CAP3BUFL = 0x0f 'MAXCNT, preload with 3599 degrees [actual 359deg][Should read 359.9deg]
CAP3BUFH = 0x0e 'MAXCNT, preload with ???? degrees [actual ???deg]

Is now:
CAP3BUFL = 0x0f 'MAXCNT, preload with 3581 degrees [360deg - 0.995Deg]
CAP3BUFH = 0x0e 'MAXCNT, preload with ???? degrees [actual ???deg]

Due to the recently found error of the 100:1 gearbox being actually 99.5:1. Therefore 3582 steps/rev of the output shaft.

I'm not familar with signed and unsigned values, but if this means that there are negatives, then no I don't use signed values. I hope this is correct!

I was interested in the code in post #1, with the 'Distance.15' variable, as I've not come across this before, especially if it gives better code than before. Also if it allows me to add a DEADBAND succesfully.

C.

Last edited:

#### ericgibbs

##### Well-Known Member
hi C,
The programs we have exchanged do not use SIGNED values, as Oshon does not support them.
You can use If WORD.n = ... Then , to check any bit in a Word for being High  or Low .
or you can SET a Bit High or Low by using WORD.n = 1 or 0

For example,
if the present Head Azimuth is say, 010 degrees and you want to move the Head to 350 degrees, the program determines that the Head must rotate Anticlockwise for the shortest travel.
Also if the present Azimuth is 350 degrees and 010 degrees is required, the program drives the the Head Clockwise. ie: the shortest travel.

As we are working in 360 degrees of Head rotation, the requirement was to determine the shortest angular movement to get the Head from its present Azimuth to the required new Azimuth, the programs we have do just that.

I understand that you are using 3581 as an Index point, because of the mechanical error.

Testing 'distance.15' in the program will not make any difference to the Dead band angle detection, its just another way of doing what we have already done. E

#### camerart

##### Active Member
hi C,
The programs we have exchanged do not use SIGNED values, as Oshon does not support them.
I'll try to remember!

[QUOTE="You can use If WORD.n = ... Then , to check any bit in a Word for being High  or Low .
or you can SET a Bit High or Low by using WORD.n = 1 or 0[/QUOTE]
That's really interesting!

[QUOTE="For example,
if the present Head Azimuth is say, 010 degrees and you want to move the Head to 350 degrees, the program determines that the Head must rotate Anticlockwise for the shortest travel.
Also if the present Azimuth is 350 degrees and 010 degrees is required, the program drives the the Head Clockwise. ie: the shortest travel.[/QUOTE] As we are working in 360 degrees of Head rotation, the requirement was to determine the shortest angular movement to get the Head from its present Azimuth to the required new Azimuth, the programs we have do just that.[/QUOTE]
OK, back to the drawing board.

[QUOTE="I understand that you are using 3581 as an Index point, because of the mechanical error.[/QUOTE]
Tick.

[QUOTE="Testing 'distance.15' in the program will not make any difference to the Dead band angle detection, its just another way of doing what we have already done. E[/QUOTE]

What a shame, it looked so magical Ok, that's the end of this thread, for me. Back to the Tracker thread!

Thanks a lot C.

#### camerart

##### Active Member
Duplicated and removed. C.

Status
Not open for further replies. 