怎么在可重定位代码中使用fsr对

不，我认为这不安全，所以最好是管理两个寄存器。对于RES，可能有一些“对齐”指令，但我从来没有使用过（因为类似的原因，我用闪存做了）。



      以下为原文

    No, in my opinion it's not safe so it would be better to manage both registers. There could be some "aligning" directive for RES but I never used it (I did that with Flash Memory though, for similar reasons)

谢谢，你使用一对“影子”寄存器，设置在循环开始之前达到你想要达到的值吗？对我来说，这似乎是最简单的方法，只是想知道专家们在做什么？欢呼杰夫



      以下为原文

    Thanks,
Do you use a pair of 'shadow' registers which are set before the start of the loop to the value you want to reach?
That would seem to be the easiest way to me, just wondered what the experts do?
Cheers Geoff

哦，对不起，你的意思是“找到街区的尽头”？我会用柜台…在循环中，您增加FSRL/H并递减计数器。除非你能指望一些特殊的定界符，比如说字符串或类似的零…



      以下为原文

    Oh sorry you mean for "finding the end of the block"?
I'd use a counter... inside the loop you increment FSRL/H and decrement the counter. Unless you can count on some special delimiter, say zero for strings or alike...

答案取决于哪一个PIC设备和变量保留在哪里。变量必须是连续的（在位置上不是必需的）——链接器保证了，也就是说，它必须能够在顺序地址中访问。



      以下为原文

   
The answer depends on which PIC device and where the variable is reserved. The variable must be contiguous (not necessary in location) -- the linker guarantees that; that is, it must be able to access in sequential addresses.
 

不知道你正在做什么家庭PIC是不可能给出一个好答案的。请提供你的照片的全名。



      以下为原文

    Impossible to give a good answer without knowing what family PIC you are working on.
Please provide the full name of your PIC.

由于至少有两个其他答复，答案取决于特定的PIC。如果您的PIC支持线性寻址，并有“ADFSR”指令，那么对于我的钱，你最好用线性地址加载FSR X，然后：你永远不必担心银行边界或CA。里斯。请注意，线性寻址不包括我使用的8位PICS中的公共存储器（PIC16LF1XXXX），其中公共存储器位于每个银行中的0x70-0x7F。侧注：我使用FSR 1保持软件堆栈，所以通常在栈上有计数器，而“DEFSZ”将由我的AL引用Idf1。IAS“Stuttos”。S/W堆栈有许多其他用途（参数到例程，其他的“本地”存储，…）。但是S/W堆栈与线性寻址和“ADFDSR”设计的使用正交。GelnPeDe: Grammar。



      以下为原文

   


As at least two other replies mentioned, the answer depends on the particular PIC.
 
If your PIC supports linear addressing and has the "addfsr" instruction, then for my money you are better off loading the FSR x with the Linear address and then:
LoopStart
    ...                 ; Your Work Here.
    addfsr  0, 1        ; Move to next byte.
    decfsz  counter, f  ; Loop Control.
    bra     LoopStart   ; Continue Loop.
Then you never have to worry about bank boundaries OR carries.  Note that linear addressing does NOT include the common memory in the 8-bit PICs I use (PIC16LF1xxxx) where common memory is located at 0x70 - 0x7F in each bank.
 
Side note: I keep a software stack using FSR 1, so I normally have the counter on the stack and the "decfsz" would refer to INDF1 by my alias "StackTOS".  The S/W stack has many other uses (parameters to routines, other "local" storage, ...).  But the S/W stack is orthogonal to the linear addressing and the use of "addfsr" design.
 
GlennP
 
Edit: Grammar.

是的，线性记忆是另一个选择，找到“块的结束”是一个独立的问题。



      以下为原文

    Yep, linear memory was another option
Still , finding "the end of the block" is a separate matter

我不会再重复我刚才说过的话。假设数组/缓冲区变量是在一个简单的UDATA段中保留的，链接器将把它全部分配到一个存储的内存中，因此不需要FSR的高字节来“查找块的结束”。数组的大小和数组的相对结束地址是已知的，所以任何方法都将被使用。工作。然后，它涉及到指令集与可用RAM的关系，代码大小与速度对个人偏好的关系，以及如何实现它。



      以下为原文

    I'm not going to repeat what @qhb and I have said earlier. Assuming the array/buffer variable is reserved in a simple UDATA section, the linker will allocate it all within one banked memory, so the high byte of FSR is not needed to "find the end of the block." The size of the array and the relative end address of the array are known, so either method will work. It then comes down to instruction set vs. available RAM vs. code size vs. speed vs. personal preference on how to implement it.

很高兴知道链接器会把所有的空间都放在同一个银行里，但是如果我误解了OP（也）问我的坏话，我在想一个“某物的结尾”的标记。



      以下为原文

    Good to know that linker will put all of that space in the same Bank, but I was thinking about a "end of something" marker
If I misunderstood what OP was (also) asking, my bad...

谢谢大家，我现在使用的是16F1779，它有线性访问。出于某种原因，计数器的想法回避了我，我用它来做其他的循环，为什么不使用FSR写呢？觉得现在有点傻了，但应该继续干下去！欢呼杰夫



      以下为原文

    Thanks everyone,
I'm using a 16f1779 at the moment which does have linear access.

For some reason the idea of a counter eluded me, I use them for other loops so why not a fsr write??

Feel a bit daft for asking now but shall get on with it!
Cheers Geoff

很高兴知道链接器会把一小块RAM放在一个银行里。再次感谢杰夫



      以下为原文

    PS.
Nice to know the linker will keep small blocks of ram in one bank.
Thanks again Geoff

计数器使用RAM的字节。当RAM不可用时，可以使用数组的结束地址（数组的最后一个元素的地址），就像在原始的POST中那样。



      以下为原文

   
Counter uses a byte of RAM. When RAM is not available, you can use the end address of the array (address of the last element of the array) like in your original post.
 

也就是说，用简单的UDATA指令分配变量。如果该块被分配到线性数据空间，则该块可以跨行。



      以下为原文

   
That is when the variable is allocated with a simple UDATA directive.  The block can span across banks if it's allocated to the linear data space.
 

谢谢，我在数据表中读了一些关于线性数据的信息，所以任何一个最多80字节的块都会保留在一个有UDATA的银行中（显然是在空间上），如果一个数据块通过银行，链接器会发出警告吗？我可以看到保存一些RAM的优点，如果我理解了它的安全性，假设我可以，在循环开始时设置FSRXH，并且知道FSRXL不会溢出，只要我使用少于80个字节，没有用大量块填充RAM并且不使用线性数据。我意识到，FSRXL的7位是银行选择位之一，其他都在FSRXH中，所以翻转将是一个问题：-欢呼杰夫



      以下为原文

    Thanks,
I had the read a bit about linear data in the data sheet, so any block up to 80 bytes will stay in one bank with udata (subject to space obviously), does the linker issue a warning if a block ends up crossing a bank?

I can see the advantages of saving some ram, if I've understood this right its safe to assume I can, set fsrxh at the start of the loop and know that fsrxl won't overflow as long as I'm using less than 80 bytes, haven't filled up the ram with massive blocks and aren't using linear data?

I realise that bit 7 of fsrxl is one of the bank select bits, the others being in fsrxh, so a roll over would be a problem :-)
Cheers Geoff

是的，每当我不需要挤到RAM的最后一个字节时，我就会使用计数器。



      以下为原文

    Yep,
I'd use a counter every time I don't have to squeeze up to the last byte of RAM

注意，如果使用线性数据，则有一个指令在一个指令中取出一个字节并对FSR对进行16位增量或递减。



      以下为原文

    Note, if you were using linear data, there are new instructions that in one instruction, fetch a byte and do a 16 bit increment or decrement on the FSR pair for you.
 

是的，但是那些MOFIW FSR0++也工作在“基本”的地址上，所以无论如何都值得在一个新的PIC16上使用（这将是下一个建议）。



      以下为原文

   


Well yes, but those
    moviw FSR0++                


also work at "basic" addresses - so worth using anyway on a "new" PIC16 (it would have been next suggestion

确实，并且可以是有用的，但是正如已经讨论过的，如果你坚持非线性内存块，那么高字节就永远不会改变。



      以下为原文

    Indeed, and can be useful, but as already discussed, the high byte will never change if you stick to blocks of non-linear memory.
 

真正地？我在想：“它只会出现在任何地方”，但它不会增加……让我重新检查一下文档，我只使用过一次，当移植一个旧的PIC16代码到一个新的（和小块内存无论如何）



      以下为原文

    Really? I was thinking "it would just address to nowhere" but NOT that it would not increment...
Let me recheck the docs I only used it once, when porting an old PIC16 code to a new one (and for small blocks of memory anyway)