Continue to Site

# ASM - Enhanced 16F and long calls - how?

#### Nigel Goodwin

##### Super Moderator
There's callw where you preload w with the destination, but again, the 16FXXX to 16F1XXX migration document is not that clear on how far it can actually jump.

As I read it, it supposedly can jump across pages, but as my program is currently only 1200 words, paging is not an issue other than the DW read which is at the very end of the second page and I know that is working ok when run on it's own.
Your table exceeds 256 bytes, from what I remember it causes chaos if tables cross 256 byte boundaries. I do seem to recall though that you could create much larger tables, that can cross boundaries?.

In fact, having looked it up, my Tutorial 13.3 uses large (16 bit) tables which can exceed boundaries with no issues.

#### Pommie

##### Well-Known Member
Your table exceeds 256 bytes, from what I remember it causes chaos if tables cross 256 byte boundaries. I do seem to recall though that you could create much larger tables, that can cross boundaries?.
The table is a 768 word table (at the end of memory) accessed using flash read. So no paging problems.

Mike.

#### Nigel Goodwin

##### Super Moderator
The table is a 768 word table (at the end of memory) accessed using flash read. So no paging problems.

Mike.
Ah - I only looked at the table, not at how it was accessed

#### Mike - K8LH

##### Well-Known Member
Terry, a quick look shows plenty of opportunities for optimizations (see example below) but I haven't stumbled upon any problems so far. I will keep looking, Sir.

Cheerful regards, Mike, K8LH

Code:
;~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
;   set step size LEDs       (step_size = 0..2 inclusive)         ~
;~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

step_led_alt
movlw   1<<RB4          ; '00010000' (10-Hz LED)              |
btfsc   step_size,0     ; step = 1? no, skip, else            |
movlw   1<<RB5          ; '00100000' (1-kHz LED)              |
btfsc   step_size,1     ; step = 2? no, skip, else            |
movlw   1<<RB6          ; '01000000' (10-kHz LED)             |
banksel LATB            ; bank 02                             |02
xorwf   LATB,W          ;                                     |02
andlw   b'01110000'     ; change RB6..RB4 bits only           |02
xorwf   LATB,F          ; update RB6..RB4 bits only           |02
movlb   0               ; bank 00                             |00
return                  ;                                     |00

Last edited:

#### augustinetez

##### Active Member
Hi Mike.

Thanks. There's plenty more places things could be trimmed up, but time just seems to get away from me these days

#### Pommie

##### Well-Known Member
I really don't like those ORGs that are in the code. Adding a little code near the beginning will cause a crash. Is this what you were experiencing?

Mike.

#### upand_at_them

##### Active Member
I now remember running into this problem before. You need 'lcall' or 'lgoto' for crossing page boundaries.

#### augustinetez

##### Active Member
No, I shifted the blocks of code to the org's after I had finished dropping code in there.

Thats' when it cleared at least one problem - I'm quite aware of not adding anything else in code wise before those org's.

I'm looking to see if I can re-organise where parts of the code are to see if that helps.

upand_at_them - I still think the problem is occurring in page 0 without jumping to another page, one of the jumps is 510 locations, hence my comment above re reorganising it. I know that a jump that size shouldn't be a problem, but there's a bell ringing (well tinkling) in the back of the head about something like this I had ages ago - can't quite tease out what it was.

#### Pommie

##### Well-Known Member
Relative jumps (branches) can only go +-128 but goto (and call) can go to anywhere in a 2k page. I'm also pretty sure that the assembler would throw an error if a branch was out of range. I'm at a loss to suggest what else it might be.

Mike.

#### augustinetez

##### Active Member
Thanks Mike.

I'll see what the reorganising shows up, if anything.

I did change the goto's for the enhanced version BRA which is supposed to have better range, but that didn't seem to make any difference.

Maybe Mike K8LH will see something.

#### augustinetez

##### Active Member
Well, I did some maneuvering of code - Put the Calibrate routine at the end and shifted a couple of small file swapping routines up before Start.

That put the bulk of file processing eg multiplication, sending to the DDS chip etc, in to the 0x100 to 0x200 block (and yes I removed the ORG statements)

Result - did sweet FA - still the same problem.

Next up I will move all the RIT stuff in Page 1 in to Page 0 and see what happens - reason being everything works fine until the RIT code is enabled.

#### augustinetez

##### Active Member
And to update the last bit, all code is now in Page 0, the lookup table is still in program space at the very end of memory - and no change - problem not resolved.

So it looks like I have something screwy in the RIT code somewhere and to narrow that down, it would seem to be when a negative offset** of the RIT value comes in to play.

**In code, all RIT values are a positive number, all that identifies if the offset should be added or subtracted from the base frequency is whether bit 0 of the 'dir' register is set or not.

#### Pommie

##### Well-Known Member
Terry,

I may have found your problem. After tracing your code in the simulator, fstep_2 & 3 have the value from the previous time through. Clearing them as below seems to fix it.
Code:
getValue
;first do ADC-center value to discover direction
bsf    dir,0        ; set direction, 1 = up
movlw    high(center)
subwf    NumH,f
movlw    low(center)
subwf    NumL,f
btfss    STATUS,C
decf    NumH,f
btfss    NumH,7        ; is it negative
BRA    notNeg
;need to negate acc
bcf    dir,0        ; set direction, 1 = up
movlw    0xff
xorwf    NumL,f
xorwf    NumH,f
incf    NumL,f
btfsc    STATUS,Z
incf    NumH,f
notNeg
; have now got a valid lookup value
BANKSEL    EEADRL        ; Select Bank for EEPROM registers
movfw    NumL        ;
movfw    NumH
bcf    EECON1,CFGS    ; Do not select Configuration Space
bsf    EECON1,EEPGD    ; Select Program Memory
NOP            ; required 2 x NOPs
NOP
; EEDAT will now contain 0 - 2500
; and direction bit will be set
movf    EEDATH,w
movlb    0
movwf    fstep_1        ; for DDS frequency change
BANKSEL    EEDATL
movf    EEDATL,w
movlb    0
movwf    fstep_0        ; for DDS frequency change
clrf    fstep_3        ;********added
See last two lines.

Mike.

#### augustinetez

##### Active Member
OK, I'm on the workbench at the moment so I'll give that a go.

#### augustinetez

##### Active Member
Thankyou, thankyou, thankyou - that was it.

Now to see if it works when I run the whole thing - but first I'm going to take a breather and have a cuppa.

#### Pommie

##### Well-Known Member
As a little excersize, I converted the first part of your code to C. Namely the equates and the EEPROM defaults.
This is the result,

I'd like, with your permision, to convert a little more to C out of curiosity.

Mike.

#### Nigel Goodwin

##### Super Moderator
As a little excersize, I converted the first part of your code to C. Namely the equates and the EEPROM defaults.
This is the result,
View attachment 137199

I'd like, with your permision, to convert a little more to C out of curiosity.

Mike.
If you want to play with one of the DDS chips (or modules) then it's easier to start from the Arduino library - which is what I did. Mind, you I've just been looking for the code, and can't seem to find it?.

#### augustinetez

##### Active Member
I'd like, with your permision, to convert a little more to C out of curiosity.
Go for it Mike.

Be interesting to see how that turns out.

Replies
0
Views
2K
Replies
5
Views
655
Replies
4
Views
786
Replies
6
Views
1K
Replies
42
Views
11K