Hi again...

I've done a few additional work on the 16F1xxx.

In this case it is a simple demo-app to drive a
64x8 LED matrix display (the one that is built from
8x8 LED matrises and usualy shows "rolling text" in
a shop window or similar.

I have a 384 byte buffer allocated in linear memory
(3 display lengths and red/green bits, 64x3x2=3D384).

The first 128 positions in the buffer are then used
for the actual display. The display is dynamic and has
to be multiplexed continues. One new row of 128 bits
will be written each 1 ms.

To get rolling text this 384 byte buffer has to be "shifted"
2 positions regulary. I now have that code ready, and it
shifts all 384 bytes two positions (since there are two
bits per dot) in 126 us on a 16F1938 @ 32MHz INTOSC).
That is OK and well within the multiplex timer of 1 ms.

I made a quick check using a 16F88x and it would take
something like 440 us (@ 20 MHz) if I'm right.

Now, a 17F88x can't have a continues buffer of that
size anyway... :-) But the rellative performane would be
similar for doing the same operation on a smaller buffer.

Jan-Erik.


The actual code as it looks right now is :

---------------------------------------------------------
; Rotate 384 byte buffer 2 steps to the left.

; Load FSR0 with start adress of buffer.
     movlw   high    out_buff
     movwf   fsr0h
     movlw   low     out_buff
     movwf   fsr0l

; Number of loops.
; 5 bytes are moved each loop, 76x5 =3D 380.
; 2 bytes are saved for later restore =3D 382.
; 2 bytes are moved before of the loop =3D 384.

     movlw   d'76'
     movwf   loop_cnt

; Save the first two positions for later restore ("rotated").
     moviw   [fsr0]      ; First pos...
     movwf   roll_tmp1
     moviw   1[fsr0]     ; Second pos...
     movwf   roll_tmp2

; Move two positions before the loop to get an "even" loop.
     moviw   2[fsr0]     ; Move FSR0+2 =3D> W
     movwi   fsr0++      ; Move W =3D> FSR0 and incr FSR0
     moviw   2[fsr0]
     movwi   fsr0++

; Now loop through the rest of the buffer.
; Move 5 bytes each time to save on looping logic.

roll_loop
     moviw   2[fsr0]
     movwi   fsr0++
     moviw   2[fsr0]
     movwi   fsr0++
     moviw   2[fsr0]
     movwi   fsr0++
     moviw   2[fsr0]
     movwi   fsr0++
     moviw   2[fsr0]
     movwi   fsr0++
     decfsz  loop_cnt, f     ; All of buffer?
     goto    roll_loop       ; No, continue.

     movf    roll_tmp1, w    ; Restore the two saved bytes
     movwi   [fsr0]          ; At the end of buffer, the
     movf    roll_tmp2, w    ; "rotate" part of it...
     movwi   1[fsr0]

; 384 byte buffer shifted 2 pos to the left!
---------------------------------------------------------


It is also easy to initialize the RAM buffer from data from
flash at startup. Two positions are copied each loop to keep
the loop counter within 8 bits.

---------------------------------------------------------
; Copy buffer data from flash to GPR.
; Load FSR0 with adress of GPR buffer

     movlw   high    out_buff
     movwf   fsr0h
     movlw   low     out_buff
     movwf   fsr0l

; Load FSR1 with adress of flash data
; txt_tab1 points to a number of "dt" statements
; defining 384 bytes (as RETLW instructions, but
; MOVIW only reads the low 8 bits anyway...).

     movlw   high    txt_tab1
     movwf   fsr1h
     movlw   low     txt_tab1
     movwf   fsr1l

; Number of loops, 192x2 =3D 384.
     movlw   d'192'
     movwf   loop_cnt

copy_buff_loop
     moviw   indf1++
     nop                 ; Reading from flash takes one extra cyc.
     movwi   indf0++
     moviw   indf1++
     nop
     movwi   indf0++

     decfsz  loop_cnt
     goto    copy_buff_loop

; Ready!

---------------------------------------------------------

Note that the processor automaticly switches between flash
and GPR depending on the adress on FSR0/FSR1 (bit 15).

---------------------------------------------------------


Jan-Erik Soderholm wrote 2012-07-25 16:38:
> A few additional notes... :-)
>
> Byron Jeff wrote 2012-07-25 13:19:
>> I have definitely learned something today.
>>
>> Question: is the SHADOW important...
>
> I noticed that the "shadow" param in the LKR files is
> *not* documented (yet ?) in the usual documentation
> "ASSEMBLER/LINKER/LIBRARIAN USER=92S GUIDE" (33014K.PDF).
>
>> below because of the mapping between the
>> linear memory and the gprs? How is it different than having a single
>> extra linear line with a start of 0x2000 and end of 0x23EF?
>
> I guess that it is the "shadow" parameter in the LKR that enables
> MPASM/MPLINK to "know" that these two memory areas are the same.
>
> Jan-Erik.
>
--=20
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.