> >[1] A reasonable-sized area which is common to all memory banks. > >[2] Seperate bank-select bits for direct and indirect access. > >Maybe I'm being too negative since I haven't even seen the parts yet, but > >bank switching with such huge blocks is really a pain and I think there's > >no good reason for it. IMHO, Microchip should have placed the banked-vs- > >unbanked boundary at $80; having the page chunks be 128 bytes would be no > >less convenient than having them be 224 bytes as they are now, but then > >the common area would be large enough to keep most programs' scalar > >variables. > > I think it may be more convenient to have bigger pages, as it is > done now. If your program needs more than one page of RAM you can divide > it so as to keep the code of different pages connected as scarcely as > possible. Smaller pages would mean more divisions and more bank > switching. I understand you're saying that the pages are too big to even > think of this, but on the other hand I guess about 100 bytes may not be > enough, and if your using this chip instead of a cheaper one you > might have lots of code. My point is that I don't find bank-switching that > problematic and I'd consider the trade-offs. But I agree with you on the > separate bank bits, I wonder if there's a reason (maybe at the > circuit-level) for not doing it that way. While there are certainly exceptions to any rule, most programs that need a lot of RAM need it for arrays or other such constructs. Given that any array access has some associated setup work anyhow, having to deal with array banks isn't a big deal. For simple variables, however, it's nice to simply *ignore* bank-switching and related concepts. If 96 bytes' worth of registers are non-banked, then the vast majority of applications--even those which use up hundreds of bytes worth of arrays--will be able to handle all their non-array needs without bank-switching. Further, even for programs that do need large arrays [bigger than 128 bytes] the overhead of selecting the appropriate 128-byte page is really not severe. In fact, with arrays that span pages it's probably easier to deal with 128-byte pages (power of two) than 224-byte pages (not a power of two). For example, suppose ArrayH:ArrayL is a two-byte pointer to a logical address within banked memory. Then to access the value at ArrayH:ArrayL: [16Cxx'ish code] rlf ArrayL,w rlf ArrayH,w movwf Bank movfp ArrayL,FSR0 bsf FSR0,7 ... now accesses to FSR will go to the proper spot. Note that ArrayH:ArrayL can point anywhere in banked memory, and that the pair may be operated upon as a 16-bit pointer into contiguous memory space. To increment the pointer in FSR, use infsnz FSR0 incf Bank bsf FSR0,7 While I suppose that there may be some cases where an array is between 128 and 224 bytes in size where the larger pages would be helpful, I don't think I personally have encountered such situations but I know I've encountered the reverse. > > MICROCHIP, ARE YOU LISTENING!!? > > ``The salient features of Extended Indirect Mode are: > > 1. Full upward compatibility with existing PIC17C4X binary code. > > 2. Single-cycle access to contiguous linearly-addressable RAM via > > indirect addressing. > > 3. Single-cycle any-bank-to-any-bank RAM copy (MOV INDR0,INDR1). > > 4. A bank-selectable 224-byte RAM context (1Ch through FFh in any bank).'' > > But the implementation of this seems (to me, just an observer) far from > trivial at the circuit-level. You would need a new bus for the FSRs' > higher bits, the FSRs would need added circuitry apart from doubling their > size, and you would have to add a new MUX before the register address > latch. I agree that a "nice" implementation (like a BANKFSR register) would probably have added a little silicon; IMHO the benefits from being able to truly bank the IND's would probably be worth it. Certainly, though, while we can debate about the exact best size for the banked/unbanked split I hope you will agree with me that there oughta be more than SIX unbanked registers? > If I was microchip I think I'd rather use my resources to do diverse > faster and cheaper micros with more memory and peripherals, instead of > doing all this work just to save some programmers' work and perhaps make a > certain kind of code run a little faster. After all, isn't that the way > they're products are positioned? The simplicity of the scheme (from a > hardware point of view) might be one of various things that allow the high > speed and low price we expect from a PIC. Your point is certainly important. There's a diference, I think, between design decisions which trade complexity for programming convenience, and those which improve programmer convenience without much cost whatsoever. I think placing the bank split in a better place would have fallen in the latter category. My choice of 128 was intended both as a compromise between large bank/small blank options, and also one which would allow reasonably convenient accessing across pages. > > If you want to do any kind of > > inter-bank processing, with some data in RAM bank 0 and some in RAM bank > > 1, guess how many bytes of program variables you can have for your > > sophisticated algorithm? JUST SIX BYTES (less the one to save BSR, less > > any other interrupt saves, etc.). > > I don't use 17CXX yet but I'm sure you can use banked registers too! Can't > you do something like: > > MOVPF BSR,unbanked > MOVLB ISRbank > .... use all the registers you need > MOVLB anotherBank or MOVPF W,BSR > .... access another bank > MOVLB ISRbank > .... go on, close a loop, etc ? Certainly this is possible, which is why I said the 17Cxx give five general-purpose unbanked registers (you have to give up one to hold the BSR before you can put something useful into it). On the other hand, this is of course spending two cycles per interrupt which would in many applications not have to be spent if the unbanked region were larger. Personally, I rather liked the 16CXX memory map (with seperate IRP and RP0/RP1 bits) as well as the reasonably decent bank-shared region on the 16C924 [16 bytes]. It's too bad Microchip couldn't have kept these advantages on the 17Cxx.