使用哪种PIC

如果你不喜欢银行（页面切换），你需要去16比特，最小的一个是PIC24F（或者PIC24FV，如果你需要5V）。



      以下为原文

    If you don't like banks (page switching) you need to move to 16-bit PICs, the smallest ones are PIC24F (or PIC24FV if you need 5V).

你看了微芯片部分选择器了吗？如果你喜欢，请关注PIC18S。或者PIC24



      以下为原文

    Did you look at the microchip part selector?
Focus on pic18s if you like them.
Or a pic24

它看起来像PIC16F15325和15345将做你想要的。8K字程序在一个银行中闪存，224字节存储区域Flash（它可以像EEPROM一样使用）和1024字节的数据SRAM。然而，SRAM有8个银行，而BANG0有96字节的通用RAM。http://www. Mouer-.com /DS/.. 8 /4000 1865 B-1082596PDF.这里还有其他的TSSOP-14包：http://www. Mouel.com／SEM……8ik？P= 1Z0YRIFZ1Z0Z7PTIF，你使用C，你不必担心银行交换。PIC18不需要银行交换，但没有在所需的TSSOP-14包。



      以下为原文

    It looks like the PIC16F15325 and 15345 will do what you want. 8k words program flash in one bank, 224 bytes storage area flash (which can be used like EEPROM), and 1024 bytes of data SRAM. However, the SRAM has 8 banks, and BANK0 has 96 bytes of general purpose RAM.
 
http://www.mouser.com/ds/..8/40001865B-1082596.pdf
 
Here are others with the TSSOP-14 package:
 
http://www.mouser.com/Sem...85ik?P=1z0yrifZ1z0z7pt
 
If you use C, you don't need to worry about bank switching.
 
The PIC18 doesn't need bank switching, but none are in the required TSSOP-14 package.

因为16F PICS使用GOTO中的11位即时地址和调用指令（2K范围），所以我相信您仍然必须进行寻呼（使用PACESEL或设置PCLAT的3到6位）来访问2K范围以外的区域。这些图片确实具有数据存取的线性内存寻址能力，但是我相信程序访问仍然是分页的（如果你使用C编译器，那就不是问题）。对于pCalth-BIT。



      以下为原文

   
Because the 16F pics use an 11 bit immediate address in the GOTO and CALL instructions (2K range) I believe you must still do paging (using pagesel or setting bits 3 to 6 of the PCLATH) to access outside the 2K range. These pics do have linear memory addressing capability for data access however I believe program access is still paged (not an issue if using the c compiler as you say).
 
EDIT: corrected banked to paged - FLASH is paged, RAM is banked. And for PCLATH bits.

16F1704／1705与所有芯片兼容，因为PPS外围引脚选择，仅没有EEPROM。



      以下为原文

    16F1704 / 1705 is compatible with all chips because of the PPS peripheral pin select, only no EEPROM.

各位，请使用正确的术语：页面是程序闪存，银行是数据RAM内存。：）



      以下为原文

    Guys, please use the correct terminology:  page is for program flash memory and bank is for data RAM memory. :)
 

因为16F PICS使用GOTO中的11位即时地址和调用指令（2K范围），所以我相信您仍然必须进行寻呼（使用PACESEL或设置PCLAST的位3和4）来访问2K范围以外的区域。这些图片确实有线性内存寻址能力用于数据访问，但是我相信程序访问仍然是存储的（如果你使用C编译器，那不是问题）。正如杰克所说，16F中的页面是2K范围。对于16F153X5设备，四位PCLAST & lt；6:3 & gt；选择GOTO页面并调用指令。



      以下为原文

   
Because the 16F pics use an 11 bit immediate address in the GOTO and CALL instructions (2K range) I believe you must still do paging (using pagesel or setting bits 3&4 of the PCLATH) to access outside the 2K range. These pics do have linear memory addressing capability for data access however I believe program access is still banked (not an issue if using the c compiler as you say).

As Jack said, a page in 16F is 2K range. For the 16F153x5 devicves, four bits PCLATH<6:3> select the page for GOTO and CALL instructions.

这意味着SPIC16不会给你3.5K没有页面。如果这很重要，你需要去PIC24。在PIC16中，数据可以线性地处理，但SFRs仍然需要银行业务。如果你不喜欢银行业，PIC24就是方法。



      以下为原文

   


This means PIC16 won't get you 3.5k without pages. If that's important, you need to go to PIC24.
 
Same with banking. In PIC16, the data can be addressed linearly, but SFRs still require banking. If you don't like banking, PIC24 is the way.

如果你写在C，然后去一个24F，因为自由编译器比18F自由编译器好得多。



      以下为原文

    If you write in C then go for a 24F because the free compiler is much better than the 18F free compiler.
 

使用需要程序代码分页的PIC并不难做到。在“C”中，编译器为你做所有的，但最深奥的情况，在汇编程序中，你可以从简单地总是指定页面开始（用Page SelpSedoDO指令），你就可以了，如果需要的话，以后再清理它。这是一个一贯风格的问题。



      以下为原文

    Using a pic that requires paging of the program code is really not that difficult to do. In "c" the compiler does it for you in all but the most esoteric situations and in assembly you can start out by simply always specifying the page (with pagesel psuedo instructions) and you will be OK, clean it up later if you need to. It is more a matter of consistent style then anything else.

如果他们关心Paging，我假设他们使用ASM。如果你使用C并且关心Paging，那么你做的事情非常错误。



      以下为原文

    If they are concerned about Paging, I ASSUME they are using ASM.
If you are using C and are concerned about Paging, then you are doing something very wrong.

我误解了PIC16F18325和PIC16F15325。他们在Goto指令中有一个11位的地址，所以它可以访问2K的程序内存而不需要分页。使我困惑的是程序存储器组织描述，它显示了连续的块到0x1FFF，而PIC16F83显示了两个0－0x07FF和0x0800到0x0FFF的页面，PIC16F87显示了四页：



      以下为原文

    I was mistaken about the PIC16F18325 and PIC16F15325. They do have an 11 bit address in the GOTO instruction so it can access 2k of program memory without paging. What confused me was the program memory organization description which showed a continuous block up to 0x1FFF whereas the PIC16F883 shows two pages of 0-0x07FF and 0x0800 to 0x0FFF, and PIC16F887 shows four pages:
 

是的，在“更新”的数据表中，他们似乎更喜欢没有明确页面的图片，但是所有16F部分都使用闪存的页面，这是指令集的限制（如果PIC有2K或更少的ROM，那么只有0页，所以它变得不重要）。



      以下为原文

    Yea, in "newer" data sheets they seem to prefer the picture without the explicit pages shown however ALL 16F parts use pages for FLASH memory, it is a limitation of the instruction set (if the pic has 2K or less ROM then there is only page 0 so it becomes unimportant).

此外，新的PIC16F1*具有“胸罩”指令，可以跨越页面边界并使编程变得更容易，因此页面不像旧图片那么苛刻，因此它们之间的分隔符可以被擦除：



      以下为原文

    Also, newer PIC16F1* have "bra" instruction which can cross page boundaries and makes programming much easier. Thus pages are not as harsh as in older PICs, so separators between them may be erased :)
 

为什么？一旦你知道它是如何运作的，那么它就不难了。当然，搬到C可以减轻你所有的负担，而且真的值得考虑。



      以下为原文

   
Why?
Once you get your head around how it works, then it's not hard at all.
Of course, moving to C relieves you of all the burden, and really is worth considering.
 
 

因为我不是在C中写的，而是实际上在没有图书馆的情况下编写ASM机器代码，我可以在一个页面上安装这个程序。所以16F68和16F15325都可以正常工作。谢谢大家的回复。阅读别人所说的话是非常有帮助的。



      以下为原文

    Since i am not writing in "C" but actually writing asm machine code without the libraries i can fit this program on less than one page. So either 16f688 or 16f15325 will work just fine. Thank you all for the responses. It helps immensely to read what others have said.
 

在第一篇文章中，你说你需要一个以上的页面，这就是为什么你问的处理器不需要页面切换的原因。16F15325会更好，因为它可以在一个指令中进行银行交换，所以你的代码会自动变小。它给你LATX寄存器，所以RE。AD修改写问题是一件过去的事情，它为您提供了简单的方法来直接从闪存读取查找表，简化了代码。它为您的中断自动化上下文保存和恢复，使其更小、更简单和更快。



      以下为原文

   
In the first post you said you did require more than one page, which is why you were asking about processors that didn't require page switching.
 

The 16f15325 will be better, because:

• it can do bank switching in one instruction, so your code automatically gets smaller.
  
• it gives you LATx registers, so read-modify-write problems are a thing of the past,
  
• it gives you simple ways to read lookup tables directly from FLASH memory, simplifying your code.
  
• it automates context save and restore for your interrupts, making them smaller, simpler and faster.
  

 
 

是的，先生。首先，使用16F87和876，它们需要进行页面切换。然后改变到18F2680，它增加了可用大小的X8，不需要页面切换。但是当我需要一个更小的（物理上）大小的照片时，我再次看了16F家庭，因为家庭似乎是一个较小尺寸的14/20针图片。因此，我回到页面切换问题。然后我做的是把程序内容减少到一个更小、更简单的内容。我仍然关心页面切换问题，因为如果我不能把它全部放在一页纸上，我又遇到麻烦了，但我想我可能能做到。同时，我正在处理一个DFU不工作的问题，现在已经解决了。我也从XP改为Windows 10（作为解决DFU问题的一部分）。因此，从我写这个查询到现在，我已经改写了程序的一部分，删除了我必须使它适合在一页上的部分。我希望。在我的问题上，我并不是故意欺骗别人的。这个表格是针对有图片问题的人，所以我来这里寻求帮助，因为我认为这是它的目的。我根本没有正式的编程训练，发现ASM机器代码的写作对我来说是不自然的。（就像我的母语，英语）。但是，当我和那些经过适当训练的程序员交谈时，他们理所当然地（如一般知识），对编写这些程序的团和格式来说，是非常混乱的。这个关于PICS和程序分页的问题就是一个很好的例子。提到“C”中的编程是（对我来说，我根本不知道“C”）就像是在解释另一种语言中的任何事物的操作，并期望这些知识的接收者能够理解正在传递的东西。这是不可能的，但已经说过，我也发现每个人谁添加一些东西的查询，几乎，无意中，提供了更多的知识，我可以添加到我已经准备好知道。我写的这个项目和程序还没有完成，但我可以看到我的头在隧道尽头有一盏灯。Windows 10处于工作状态，C++VR2008，2010, 2011, 2014都在，所以现在DFU工作。我有一个PIC我可以使用它将适合大小14/20针MAX的想法，我希望保持我的PRG足够小，以避免分页问题，因此我的查询。那些在C编程的人不会处理这些问题，因为你只是“包含”库A，B，或/和X，而且都被处理了。但这需要空间和了解语言。我认识一个大学的人（1973岁），他现在在一家跨国公司工作，他精通C语言、Pascal、FORTRAN等。我可以并且在这个人周围运行圈子，因为我没有这种训练，因此，不要用同样的方式思考。对不起，小姐领你去了。我希望这能让你更清楚。



      以下为原文

    Yes sir i did. At first, using the 16f877 and 876 they needed to be page switched. Then changing to the 18f2680, it increased the available size by X8 and required no page switching. But when i had a need for a much smaller (physically) sized pic I was again looking at the 16f family as it seemed that family was the one which has the smaller sized 14/20 pin pics. so i am back to the page switching issue. What i did then was to reduce the program content to a much smaller, bare bones content. I am still concerned about the page switching issue since, if i can not fit it all on one page i am in trouble again, but i think i may be able to do it.
  At the same time i am/was dealing with a DFU not working issue which now has been cleared up. I have also changed to windows 10 from XP (as part of solving the DFU issue).
  So from when i wrote this query till now i have rewritten parts of the program and deleted parts of what i had to make it fit on one page. I hope.
  I didn't mean to seem deceptive in my question. This form is for people having problems with issues about pics so i come here to get help as i thought that is what it is for. I have no formal training in programing at all, and find writing in asm machine code is quit natural for me. (like my native language, English). But when i talk to programmers who have had proper training they take for granted (as general knowledge) so much of the regiment and format of building the written programs that it is very confusing. This question about pics and program paging is a perfect example of this. The mentioning of programing in "C" is (for me as i don't know "C" at all,) is like explaining the operation of anything in another language and expecting the receiver of such knowledge to understand fluently what is being passed on. Which is impossible  But having said that i also find each person who adds something to the query, has, almost inadvertently, supplied a little bit more knowledge i can add to what i all ready know. The project and the program i am writing is still in flux as it is not finished but i can see in my head a light at the end of the tunnel. Windows 10 is in and working, C++ ver2008, 2010, 2011, 2014 are all in, so now the DFU works. I have an idea of which pic i can use that will fit in size 14/20 pin max, and i hope to keep my prg small enough to avoid the paging issue hence my query. Those of you who do program in "C" do not deal with these issues as you just "include" library a,b, or/and x, and it is all handled. But this takes room and knowing the language. I have known a university person (since 1973) who now works for a multi national co. and who is fluent in "C", Pascal, Fortran, and many more. I can and have run circles around this person as i do not have this training and as such, do not think in the same way. Sorry for miss leading you.
  I hope this makes it clearer for you.

读完所有的回复后，又出现了一个令人困惑的问题。使用GOTO，呼叫，和胸罩。我知道GOTO是一种直接寻址方法。如果GOTO将转到另一页，则在执行GOTO指令之前必须切换页位。调用指令用于跳转到子例程，如果目的地在另一页上，则与GOTO指令具有相同的要求。然而，文胸指令仅适用于2K的地址，那么如果它们具有相同的有限范围，为什么会使用BRA而不是呼叫呢？它已被写入“胸罩”消除了页面切换和边界指定的需要。好的，如果胸罩在一页的末尾被使用，但是当程序被写入时，如何将它合并，并且在尺寸上扩大，因为不可能知道指令将跳转到什么地方，直到程序完成。我已经读过，并已经解释了我的不同，然后，当我问我刚才在这张纸条上所问的问题时，我所面对的是好的，我不能从专家那里确定。在我切换到18F2680之前，建议使用胸罩。于是我用胸罩换了电话。发生了2件事。1 -在使用和工作的地方没有差异。和2个地方的呼叫需要在调用指令之前切换页位它仍然不工作。所以所有的解释都无济于事，当我问为什么，从微芯片技术支持，我没有明确的答案为什么。然而，我确实建议切换到18F2680，它确实结束了这个问题，但没有回答问题或解决页面切换的问题。水还是泥泞的，但我仍然喜欢游泳。



      以下为原文

    Having read over all the responses again, another confusing issue arises. The use of goto, call, and bra. I learned goto was a direct addressing method. If the goto was going to another page, the page bits would have to be switched before the goto instruction is executed. The call instruction is used for jumping to sub-routines with the same requirements as goto instruction if the destination is on another page. The bra instruction however is only good for 2K of address so why would one use bra instead of call if they have the same limited range? It has been written "bra " eliminates the need for page switching and boundary designations. Good if bra is used towards the end of one page, but how does one incorporate this when the program is being written and is expanding in size as it is impossible to know where the instruction is going to be jumping to until the program is completed? I have read and have had explained to me the difference, then, when i ask what i just have asked in this note i am faced with um errrr well I'm not sure from the experts.
  Back before i switched to the 18f2680 the use of bra was suggested. So i replaced call with bra. 2 things happened. 1- no difference was made in the places where call was used and worked. and 2- In places where call needed the page bits switched prior to the call instruction it still did not work. So all the explanations did not help, and, when I asked why, from microchip tech support, i got no clear answer as to why. I did however get the suggestion to switch to the 18f2680 which did end the problem but did not answer the question or solve the problem of page switching. The water remains muddy but i still enjoy a swim.