Searching \ for 'Wanted: PIC17Cxx with big (256, 512) FLAT RAM!' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'Wanted: PIC17Cxx with big (256, 512) FLAT RAM!'.

Truncated match.
PICList Thread
'Wanted: PIC17Cxx with big (256, 512) FLAT RAM!'
1997\05\02@203427 by .EDU>

flavicon
face
Dear Microchip and Dear 17C4X users!

some of our designs, for in-chip encryption and rapid data transfer, are
hampered by the RAM address mapping of the PIC17C4X architecture.  For
instance, it is not possible to use a 256-byte table without bank switching,
which bloats the code and penalizes interrupt performance.

Would you please consider the advantages of a design in which a clean, flat
256- or 512-byte RAM array lies ``under'' the special-function registers,
which would be accessible via the INDF0 and INDF1 indrect registers?

A data-transfer loop exploiting the auto-increment features of the FSRs
could really scream, if we wouldn't have to test every iteration, ``Oops,
have we wrapped around to non-RAM addresses now?''

I would suggest a ``mode'' bit, in the BSR, to select compatibility in cases
where anyone still wants INDF0/1 to walk through the SFRs.

I have a complete paper with more details on this idea, in case anyone cares
to look at it more closely.  Anyone who wants to see a PIC17CXX REALLY scream!

Peter F. Klammer, Racom Systems Inc.                   spam_OUTPKlammerTakeThisOuTspamACM.Org
6080 Greenwood Plaza Boulevard                            (303)773-7411
Englewood, CO  80111                                  FAX:(303)771-4708

1997\05\02@205511 by John Payson

flavicon
face
> Would you please consider the advantages of a design in which a clean, flat
> 256- or 512-byte RAM array lies ``under'' the special-function registers,
> which would be accessible via the INDF0 and INDF1 indrect registers?

Sounds something like the 8x51 memory mapping.  This approach is nice
for just about anything EXCEPT a "PIC-Basic" style application, which
would require a jump-table to handle loads/stores of arbitrary
function registers.  This limitation would be slight, however,
compared with the many advantages this approach would give:

> A data-transfer loop exploiting the auto-increment features of the FSRs
> could really scream, if we wouldn't have to test every iteration, ``Oops,
> have we wrapped around to non-RAM addresses now?''

Not only that, but the likelihood of an errant PIC program thrashing
its port pins would be greatly reduced if only instructions which are
hardcoded as accessing a port could alter that port, and also allow
the amount of address space dedicated to I/O to be larger (thereby
eliminating the horendous amount of bank-switching that is required
in some apps like open-collector emulation).

> I would suggest a ``mode'' bit, in the BSR, to select compatibility in cases
> where anyone still wants INDF0/1 to walk through the SFRs.

Probably not a bad idea.

> I have a complete paper with more details on this idea, in case anyone cares
> to look at it more closely.  Anyone who wants to see a PIC17CXX REALLY scream!

I don't know how many layers of lawyers you would have to go through
for Microchip to be able to really look at something like that.
Corporations have to be very careful when accepting outside ideas,
because of the risk that you might, e.g., have stolen the idea from
someone else, or might have thought of something they're already
doing (in which case they'd naturally not want to pay you), etc.

Personally, I have some ideas I'd like to see them implement with
regard to serial memory devices.  But for now at least I can only
dream (maybe if I won the lottery I could make the chips myself and
allow Microchip to buy me out--dream dream).

PS--To everyone who complained about WINMAIL.DAT--It should be
**GONE, KAPUT, FINISHED, OUTA HERE, BYE BYE MS EXCHANGE! **

More... (looser matching)
- Last day of these posts
- In 1997 , 1998 only
- Today
- New search...