I'm trying to decide on a chip to use in a "laptop" (more of a
TI-85 for coding only) i'm going to make, the PIC17FR4x's look fast
enough, and can handle enough memory for what i'm trying to do. Is there
to be a EEPROM version of this chip in the future? (How many times can I
erase/reprogram the current EPROM version?) What kind of external memory
should I use with this, is it difficult to use external memory?
I'm planning on using the following:
- 320x(200/240) LCD
- 1 Parallel Port / (1/2) Serial Port(s)
- At least 1mb of Memory
- Qwerty keypad or mini-keyboard
>
> I'm trying to decide on a chip to use in a "laptop" (more of a
> TI-85 for coding only) i'm going to make, the PIC17FR4x's look fast
> enough, and can handle enough memory for what i'm trying to do.
Up to 128K. Or more with bank switching/paging...
> Is there
> to be a EEPROM version of this chip in the future?
Don't know. Most times whenever someone asks about more EEPROM parts
The response from Microchip has been along the lines of "too slow, not
cost effective, no request from real (read thousands of units).
But honestly for the 17CXX series makes it unnecessary because it's the
only PIC parts that can execute code from external memory anyway. So what you
can do is develop a loader in the internal EPROM that'll read the program
say from a serial EEPROM and load it into the external RAM, then execute it.
For development purposes it's fairly simple to load the external ram
directly from the development system into the external RAM. Or a combination
of both (development system -> on-board EEPROM via 17C42 -> external RAM
on reboot.
In any case you'll only have to program the 17CXX part enough times to get
a working loader, at which point you can program the board via the loader
program. It gives you the added advantage of removing the EPROM erase/program
step from the development cycle.
> (How many times can I
> erase/reprogram the current EPROM version?)
Not sure. it's in the data sheet. But EPROMs a designed to be erased/programmed
on the order of over 10,000 times. You'll probably not exceed the limit.
> What kind of external memory
> should I use with this, is it difficult to use external memory?
In reverse order: No and static cache RAM for the average PC. The reason for
the second is fivefold:
1) the 32Kx8 skinnyDIP package is space saving.
2) commodity pricing makes them cheap. Real cheap. In fact it's quite ease
to strip 256K of it from a non working PC MB with cache RAM aboard.
3) Fast. 20ns access time means no worries about the PIC outrunning it.
4) Can upgrade memory in 64K sements up to say 128K. Then look at a
bank switch scheme with larger memories
5) Static. no worries about refresh.
As for attaching it it's fairly simple, you add two 74X373/573 type latches
to latch the 16 bit address and then the PIC read/write a 16 bit data value.
It's all in the data book.
>
> I'm planning on using the following:
> - 320x(200/240) LCD
Does this have built in character/graphics drivers? If not then you'll probably
need another PIC to act as the interface to it. One of my biggest problems.
I have a Toshiba display from Timeline that I haven't gotten to work even
with the built-in drivers. Japanese translated English isn't real conducive
to easy understanding.
> - 1 Parallel Port / (1/2) Serial Port(s)
Be aware that the 17CXX only has one hardware serial port. If you want more
you'll have to add chips. I like the signetics 2691. Does anyone know of a
8250/16550 type chip that comes in a 28 pin skinnydip or smaller?
Be sure you make the parallel port 8 bit bidirectional....
> - At least 1mb of Memory
Bank switching or paging since the 17C42 can't handle it naturally? I've
always been partial to using a fast static RAM to act as a paging ram. Then
for each task you can map up to 128K of available memory from whatever pool
is available.
If you want that much memory you may want to consider another RAM alternative:
Pseudostaic. It's a dynamic RAM with refresh circuitry built in. All you have
to do is strobe the OE* line every once in awhile and it stays refreshed.
Nice thing is that it comes in 512Kx8 packages (Yup a 1/2 meg). So two chips
will give you a meg. Now once again who are you going to access it?
> - Qwerty keypad or mini-keyboard
When you find a source let me know. I have a mini (not micro) XT keyboard
(maybe 8 in across) that I'll get around to using one day....
And you still haven't dealt with a fundamental PIC flaw: the inaccessible
stack. It's significant because interrupt based task switching is almost
impossible to do because you can't change the stack for each task. Does anyone
know a workaround this short of completely implementing your own stack
by changing each 'call' into a 'push return address on my stack' followed
by a 'goto'? And even then presuming an interrupted based context switcher
how can you get the return address for the interrupt just to save it? Also
what's the effect of not doing a RETIE but instead a simple GOTO to the
next task? I've actually put a few seconds into thinking about the problem
and there's no easy way to solve it.
Even if Microchip had mapped just the top of the hardware stack into memory then
there's a possibility of implementing a usable multitasking executive. Because
the call stack can be easily implement using gotos and user stacks, A TOS
mapping would create the ability to store the current return address and change
it. I mean it's only 2 lousy bytes that I believe each PIC has in its address
space. A real bummer.
But as it stands I don't see how to do it. I do see from my own discussion that
cooperative multitasking is possible by avoiding calls, but it's puts you in the
position of being one errant infinite loop from system lock-up.
This is the one IMHO fatal flaw in the PIC17CXX design that makes it
unsuitable for general purpose computing designs.
So given my criticism let me throw out an oldie alternative: The Motorola
68020. Why you ask?:
1) Everything I've discussed here applies
2) It can access up to 16 Megs of memory with no bank switching. Paging is
still a good idea.
3) There are a lot of good cheap peripherals that will implement the stuff
you want. Like the 68881 dual serial port.
4) Absolutely no stack problems. I mean if Sun can run Unix on it then your
multitasking executive should be no problem...
5) It only needs one external EPROM/EEPROM to get going. But you can have
up to a 32 bit wide data path for excellent memory performance...
5) You can get a 20 Mhz part from BGMicro for $9.95. Yup. 10 bucks.
The biggest downsides are:
1) Power Hungry. Like in hungry hungry hippo hungry.
2) No nice built in stuff. Just the CPU. Of course adding memory is just about
as simple as the 17CXX.
Another possibility in the Motorola family is the 683XX series. I don't know
about pricing, but they have an extended 68020 core (called CPU-32), on board
peripherals (serial, parallel, DMA, timers) and come in low power/ low voltage
versions. I'm partial the 68340 and the 68332 is nice too.
Anyway it looks like a fun task. Something like this is on of the myriad
tasks on my design list: specifically a semi-portable, very flexible MIDI
sequencer. Of course that tast has been on my list longer than the completion
of my PhD (and I started that 6 years ago...)
> Don't know. Most times whenever someone asks about more EEPROM parts
> The response from Microchip has been along the lines of "too slow, not
> cost effective, no request from real (read thousands of units).
Hmm... I personally find this a little surprising; especially if MicroChip
could produce a product which could write its EEPROM under [perhaps limitted]
program control (e.g. code writes data value to be written to a pair of magic
registers, executes a computed goto to the desired spot, and 10ms later the
chip resets having written the word) I think there'd be a market for certain
types of upgradable consumer products.
> Does this have built in character/graphics drivers? If not then you'll
probably
> need another PIC to act as the interface to it. One of my biggest problems.
> I have a Toshiba display from Timeline that I haven't gotten to work even
> with the built-in drivers. Japanese translated English isn't real conducive
> to easy understanding.
Hmm... I've been wanting to use one of those, and thinking of getting one
from TimeLine. Have you tried just writing a hard-coded "hello world"?
[i.e. explicit code to toss the data onto the appropriate pins without any
real logic whatsoever]?
> And you still haven't dealt with a fundamental PIC flaw: the inaccessible
> stack. It's significant because interrupt based task switching is almost
> impossible to do because you can't change the stack for each task.
...
> Even if Microchip had mapped just the top of the hardware stack into memory
> there's a possibility of implementing a usable multitasking executive.Because
> the call stack can be easily implement using gotos and user stacks, A TOS
> mapping would create the ability to store the current return address and
> change it. I mean it's only 2 lousy bytes that I believe each PIC has in
> its address space. A real bummer.
While it may seem discouraging that the PIC does not have a software-address-
ible stack, it's also understandable. You need to realize that the PIC is
set up to support certain simultaneous data flows, and these flows are of
necessity not connected. While the 17C42 did map the accumulator into memory
(rather a surprise) in general mapping things into memory is not so simple as
you might imagine. Personally, the only way I could really imagine the PIC
allowing memory-mapped access to its stack would be to add a pair of registers
which could be PUSH'ed and POP'ed. While this would be useful and somewhat
do what you want, it still wouldn't be perfect. Alternatively, if the stack
pointer were addressible (even if the stack itself weren't) you could do some
multi-tasking that way.
> Another possibility in the Motorola family is the 683XX series. I don't know
> about pricing, but they have an extended 68020 core (called CPU-32), on board
> peripherals (serial, parallel, DMA, timers) and come in low power/ low voltage
> versions. I'm partial the 68340 and the 68332 is nice too.
Note: the 683xx CPU-32 core is NOT an extended 68020; rather, it is a varia-
tion on the 68010. Important differences include:
[1] Limit of 16 bit data bus.
[2] No code cache.
[3] "Loop mode": if you execute a one-word instruction followed by a one-word
branch back, I believe the instruction and the branch will only be fetched
twice (and executed the appropriate number of times in turbo-mode).
[4] I believe not all of the 68020 addressing modes are supported, though some
modes are added compared to the 68000.
[5] Some new interpolation instructions.
> > Does this have built in character/graphics drivers? If not then you'll
> probably
> > need another PIC to act as the interface to it. One of my biggest problems.
> > I have a Toshiba display from Timeline that I haven't gotten to work even
> > with the built-in drivers. Japanese translated English isn't real conducive
> > to easy understanding.
>
> Hmm... I've been wanting to use one of those, and thinking of getting one
> from TimeLine. Have you tried just writing a hard-coded "hello world"?
> [i.e. explicit code to toss the data onto the appropriate pins without any
> real logic whatsoever]?
Nope. I really couldn't decipher the pages timeline sent me to get anything
going. I'll probably stop by the Georgia Tech IC database and see if I
can get something clearer. The ideal situation is if someone had a
code fragment. Haven't seen one yet.
>
> > And you still haven't dealt with a fundamental PIC flaw: the inaccessible
> > stack. It's significant because interrupt based task switching is almost
> > impossible to do because you can't change the stack for each task.
> ...
> > Even if Microchip had mapped just the top of the hardware stack into memory
> > there's a possibility of implementing a usable multitasking
executive.Because {Quote hidden}
> > the call stack can be easily implement using gotos and user stacks, A TOS
> > mapping would create the ability to store the current return address and
> > change it. I mean it's only 2 lousy bytes that I believe each PIC has in
> > its address space. A real bummer.
>
> While it may seem discouraging that the PIC does not have a software-address-
> ible stack, it's also understandable. You need to realize that the PIC is
> set up to support certain simultaneous data flows, and these flows are of
> necessity not connected. While the 17C42 did map the accumulator into memory
> (rather a surprise) in general mapping things into memory is not so simple as
> you might imagine. Personally, the only way I could really imagine the PIC
> allowing memory-mapped access to its stack would be to add a pair of registers
> which could be PUSH'ed and POP'ed. While this would be useful and somewhat
> do what you want, it still wouldn't be perfect. Alternatively, if the stack
> pointer were addressible (even if the stack itself weren't) you could do some
> multi-tasking that way.
While I agree it isn't easy because of the pipelined nature of the PIC I'd
imagine that the stack would be an easier to map than other things because
operations that manipulate the stack, and operations that use the stack
won't be the same. I could live with a one or two instruction delay between
setting up the stack and using it.
I could live without push and pop. I really don't mind managing my own stacks
in software. The only thing I really need is to get able to get the interrupt
return address and set the interrupt return address. That's it. WIth that
all things become possible.
alphax.com
