Using an Assmbly Routine in PBP

[alanmcf]

Hi Darrel--

Right on about the channel, it should say 6. Otherwise, I don't think it's a hardware issue, i.e. resonator vs. crystal... I've been using PBP code (follows) to capture a single channel or two and it works great, but I'd like to get the whole 512 channels, hence trying to adapt AN1075. I think its getting lost somewhere... could this have something to do with BANK0, BANK1, etc?

This is the PBP routine that I have been using to read 2-3 channels at a time; on this same hardware platform it works great...

 '====================================================
' DMX Subroutines
'====================================================    

readdmx:
        counter = 1
       	PIE1 = 0				' Mask the interrupt
        pulsin target, 0, counter
        idleflag = 0
        DMX_OK = 1
        if counter = 0 then
            idleflag = 1                        'either no DMX or break timed out
            DMX_OK = 0                          'set DMX as not present
            goto noshow_exit
        endif
        
        if counter < 35 then readDMX            'active pulse too short, keep looking
                              'otherwise its valid DMX & time to read the start code
        dummy = rcreg
        dummy = rcreg 'do this twice to clear out ang garbage in the USART
        spbrg = 0
        txsta.2 = 0 'brgh = 0
        txsta.4 = 0
        rcsta.7 = 1 'turn on the USART
        rcsta.6 = 0 'setting 8 bit receive mode, no parity, etc.
        rcsta.4 = 0
        rcsta.4 = 1 'toggle the rcsta.4 bit to make-ready
        
        while rcif = 0 : wend   'hover until start code is received
        
        startcode = rcreg 'read the startcode somewhere, tho most likely we'll never look at it

        if dmx_channel = 1 then  'if DMX address is 1, do this special case
            dummy = rcreg
            goto exit_readDMX
        endif        
        
        'else, do this code for DMX addresses 2-512:        
        count0 = 0       
        While count0 < (dmx_channel-1) 'set up loop to count up to just 1 shy of target address
            while rcif = 0 : wend   'wait for a byte
            dummy = rcreg
            count0 = count0 + 1           
        WEND        
    exit_readDMX:   
        DMX_data = rcreg         'put the DMX byte into a variable and exit
    noshow_exit:
        rcsta.7 = 0              'turn off the USART
        if intensity > 0 then
            PIE1 = 1                        'restore interrupt
        else
            PIE1 = 0                        'if the intensity is >0, let the elapsed timer run
        endif
    return

[Darrel Taylor]

... could this have something to do with BANK0, BANK1, etc?

On an 18F, banking problems don't show up till you have more than ~200 bytes worth of variables.... You have 3. Not including the array, which is handled nicely by the FSR0 indirect.

One thing your PBP version has, that the ASM doesn't, is clearing an OERR condition (CREN toggle).

OERR locks up the USART until cleared, and many bytes could be received before the program looks for data. So it's probably overflowed before it gets to the ASM routine.
<br>

[leisryan]

On an 18F, banking problems don't show up till you have more than ~200 bytes worth of variables.... You have 3. Not including the array, which is handled nicely by the FSR0 indirect.

One thing your PBP version has, that the ASM doesn't, is clearing an OERR condition (CREN toggle).

OERR locks up the USART until cleared, and many bytes could be received before the program looks for data. So it's probably overflowed before it gets to the ASM routine.
<br>

Sir Darrel;
I'd like to ask which would you most prefer and or convenient with PIC18F data ram addressing "Access Ram" or "Indirect Addressing"

[Darrel Taylor]

I'd like to ask which would you most prefer and or convenient with PIC18F data ram addressing "Access Ram" or "Indirect Addressing"

They're really two completely different things.
But if I had to choose one, I'd say "Indirect Addressing".

Access Ram is more for optimizing the code, reducing the size by letting you do things with less bank switching. It doesn't really give any additional functionality.

But "Indirect Addressing" let's you use the entire RAM space like it's a big array, which adds just a TON of functionality. Strings, packets, buffers, software stacks, etc. etc.
<br>

[leisryan]

They're really two completely different things.
But if I had to choose one, I'd say "Indirect Addressing".

Access Ram is more for optimizing the code, reducing the size by letting you do things with less bank switching. It doesn't really give any additional functionality.

But "Indirect Addressing" let's you use the entire RAM space like it's a big array, which adds just a TON of functionality. Strings, packets, buffers, software stacks, etc. etc.
<br>

Wow!!! I really appreciate it really enlightening!!! Is bank switching still occurs in "Indirect Addressing" Un-noticeably though?

[Darrel Taylor]

> Is bank switching still occurs in "Indirect Addressing" Un-noticeably though?

Well, YES and NO.

But, if I had to choose one ...
I'd say NO.

On 18F's, the FSRx registers are 12-bits wide.
Which means it can address any location from 0 to 4095 ($000 to $FFF).
It can access memory locations in ANY BANK without having to change the current bank (BSR). It's just a single address.

The beauty of this, is that no matter what bank your program is currently using, you can read/write from any other bank without switching the banks back and forth. Which may be where your original question was aimed, because Indirect addressing can be a good tool for optimization, much like the Access RAM.