If you've used the external SRAM (as in STATIC, not serial) on a PIC or AVR-
which SRAM did you use? I'm having problems finding a 64Kx8 part that is
pin compatible (without gates other than an address latch) and is in stock
somewhere. I could go to a 2 32K SRAMs, but I'd rather not.
The PIC (17C) uses an ALE, /OE, /WR scheme, and the AVR uses an ALE, /RD,
/WR scheme. The PIC appears compatible with the 61XXX family of SRAMs (64Ks
are currently being made of Unobtanium [Un]), but in my brief search, I
haven't found any that are directly compatible with the AVR's scheme.
Serial RAMs are not an option, due to speed issues.
Just a dumb question: Serial RAM? I've heard of search EEPROM and serial
FLASH. I have had a couple applications where serial RAM would have been a
godsend. Does anybody make this? What capicity?
Thanks,
Bob Ammerman
RAm Systems
(high function, high performance, low level software)
<x-flowed>At 10:18 PM 6/1/00 -0400, you wrote:
>Just a dumb question: Serial RAM? I've heard of search EEPROM and serial
>FLASH. I have had a couple applications where serial RAM would have been a
>godsend. Does anybody make this? What capicity?
>
>Thanks,
>
>Bob Ammerman
>RAm Systems
>(high function, high performance, low level software)
Check http://www.ramtron.com They make nonvolatile 8k serial RAM that can be also
be used in a bus fashion for higher capacities. It's pretty reasonably
priced, too.
If you've used the external SRAM (as in STATIC, not serial) on a
PIC or AVR- which SRAM did you use? I'm having problems finding
a 64Kx8 part that is pin compatible (without gates other than an
address latch) and is in stock somewhere. I could go to a 2 32K
SRAMs, but I'd rather not.
You might have better luck finding a 128Kx8 ram and using half of it.
----- Original Message -----
From: Bob Ammerman
To: spam_OUTPICLISTTakeThisOuTMITVMA.MIT.EDU
Sent: Friday, June 02, 2000 4:18 AM
Subject: [PIC]: External SRAM on PIC (or AVR)
Just a dumb question: Serial RAM? I've heard of search EEPROM and serial
FLASH. I have had a couple applications where serial RAM would have been a
godsend. Does anybody make this? What capicity?
Thanks,
Bob Ammerman
RAm Systems
(high function, high performance, low level software)
> If you've used the external SRAM (as in STATIC, not serial) on a PIC or
AVR-
> which SRAM did you use? I'm having problems finding a 64Kx8 part that is
> pin compatible (without gates other than an address latch) and is in stock
> somewhere. I could go to a 2 32K SRAMs, but I'd rather not.
>
> The PIC (17C) uses an ALE, /OE, /WR scheme, and the AVR uses an ALE, /RD,
> /WR scheme. The PIC appears compatible with the 61XXX family of SRAMs
(64Ks
> are currently being made of Unobtanium [Un]), but in my brief search, I
> haven't found any that are directly compatible with the AVR's scheme.
> Serial RAMs are not an option, due to speed issues.
>
> Matt Bennett
>The PIC (17C) uses an ALE, /OE, /WR scheme, and the AVR uses an ALE, /RD,
>/WR scheme.
Is there really any difference except the *naming* of the "/OE" respective "/RD" signal?
I know AVR can be interfaced directly to standard SRAM with only an adress latch. (Tip: if not using the whole adress space, use an inverter on A15, to map the external SRAM to top adress space, and not waste it on overlapping internal SRAM.
BTW, 32Kx8 seem to be more available, and also cheaper than 8Kx8.
There have been lots of discussions about serial SRAM on the list over
the years. As far as I can tell, there aren't any of any significant size
out there. I WAS using the Dallas RamPort (DS1380 and DS1381) 'til they
discontinued them on us... I'm now moving designs over the the PIC18c452
which has enough RAM for several products. On one product I'm using the
18c452 with several latches to drive a 128kbyte SRAM (capacitor backed).
That takes several chips. Seems like SOMEONE would make a reasonably
large serial SRAM, but that doesn't seem to be the case.
Harold
On Fri, 2 Jun 2000 09:11:59 +0200 TOM THERON <.....mmsesysKILLspam.....ICON.CO.ZA> writes:
> PCF8570 from Philips, 256 x 8, i2c interface.
>
> Tom
>
> {Original Message removed}
Of all things, the palmtop I use a lot uses DRAM as it's main RAM - I
was CONVINCED this was SRAM, but it's not. 1/2Mb per chip, and I have 2
(1 Mb) pairs sitting here waiting for a future project. These're
Hitachi RAM, set in TSOP Left & Right sets (reversed pinout for one -
you can Bus the tri-state pins this way) - Interesting stuff. So I now
know that it's quite possible, WITH the right RAM, to go decently low
power (2 weeks off 2 1300mAh NiMH batt's with the rest of the machine
running off the same batteries) - Sorta shocked ME! If I keep upgrading
these machines, someone could talk me out of a pair, certainly you could
talk me out of part numbers (KM416V256ALLTR is the reversed one) - I can
find the other number if you cannot get there from here <G>
I have some info I can dig out that may show how they handle the refresh
process, too.
> There have been lots of discussions about serial SRAM on the list over
> the years. As far as I can tell, there aren't any of any significant size
> out there. I WAS using the Dallas RamPort (DS1380 and DS1381) 'til they
> discontinued them on us... I'm now moving designs over the the PIC18c452
> which has enough RAM for several products. On one product I'm using the
> 18c452 with several latches to drive a 128kbyte SRAM (capacitor backed).
> That takes several chips. Seems like SOMEONE would make a reasonably
> large serial SRAM, but that doesn't seem to be the case.
>
> Harold
>
> On Fri, 2 Jun 2000 09:11:59 +0200 TOM THERON <EraseMEmmsesysspam_OUTTakeThisOuTICON.CO.ZA> writes:
> > PCF8570 from Philips, 256 x 8, i2c interface.
> >
> > Tom
> >
There have been lots of discussions about serial SRAM on the list over
the years. As far as I can tell, there aren't any of any significant size
out there. I WAS using the Dallas RamPort (DS1380 and DS1381) 'til they
discontinued them on us... I'm now moving designs over the the PIC18c452
which has enough RAM for several products. On one product I'm using the
18c452 with several latches to drive a 128kbyte SRAM (capacitor backed).
That takes several chips. Seems like SOMEONE would make a reasonably
large serial SRAM, but that doesn't seem to be the case.
Harold
On Fri, 2 Jun 2000 09:11:59 +0200 TOM THERON <spamBeGonemmsesysspamBeGoneICON.CO.ZA> writes:
> PCF8570 from Philips, 256 x 8, i2c interface.
>
> Tom
>
> {Original Message removed}
Harold wrote:
> There have been lots of discussions about serial SRAM on the list over
>the years. As far as I can tell, there aren't any of any significant size
>out there. I WAS using the Dallas RamPort (DS1380 and DS1381) 'til they
>discontinued them on us... I'm now moving designs over the the PIC18c452
>which has enough RAM for several products. On one product I'm using the
>18c452 with several latches to drive a 128kbyte SRAM (capacitor backed).
>That takes several chips. Seems like SOMEONE would make a reasonably
>large serial SRAM, but that doesn't seem to be the case.
>
Bob Ammerman wrote:
>Exactly what my search turned up - nada nil nothing none :-(
>
You can always go to a PIC with a large 68-84 pinout, like Harold
is doing, but adequate RAM definitely *is* a problem for small PICs.
Maybe nada [from practical perspective] but --> Solutions Cubed has
the RAMPack, which has 8Kx8, RS-232 addressable, designed originally
for use with Basic Stamp, but expensive at $29.95 from Jameco. Can
expand to 32K.
I recently designed my own spin-off from the RAMPack. Uses 2 32Kx8
SRAMs, controlled by a PIC64 on a small 2"x2" pcb. Addressable via
RS-232, and also in byte-mode with address/data lines multiplexed.
Can also be addressed in nybble-mode, so you can run off a PIC using
as few as 8 interface lines. I just received the pcbs, but haven't
finished the s.w. yet. I may eventually add I2C access. Estimated
max read/write rate is 500KB/sec in burst-mode/byte-mode.
This is a more difficult approach [and more expensive] than going
to a larger pinout PIC, but I think a reasonable compromise for
drop-in to a system with a small PIC.
I had also considered going with a '4040, like Octavio, but you can't
have multiple data buffers or random access that way. An alternative
is 4 '161' chips, but that's a "real" PITA.
> -----Original Message-----
> From: Dan Michaels [SMTP:TakeThisOuToricomEraseMEspam_OUTLYNX.SNI.NET]
> Sent: Monday, June 05, 2000 4:52 PM
> To: RemoveMEPICLISTTakeThisOuTMITVMA.MIT.EDU
> Subject: Re: [PIC]: External SRAM on PIC (or AVR)
>
>
> I recently designed my own spin-off from the RAMPack. Uses 2 32Kx8
> SRAMs, controlled by a PIC64 on a small 2"x2" pcb. Addressable via
> RS-232, and also in byte-mode with address/data lines multiplexed.
> Can also be addressed in nybble-mode, so you can run off a PIC using
> as few as 8 interface lines. I just received the pcbs, but haven't
> finished the s.w. yet. I may eventually add I2C access. Estimated
> max read/write rate is 500KB/sec in burst-mode/byte-mode.
>
> This is a more difficult approach [and more expensive] than going
> to a larger pinout PIC, but I think a reasonable compromise for
> drop-in to a system with a small PIC.
>
> I had also considered going with a '4040, like Octavio, but you can't
> have multiple data buffers or random access that way. An alternative
> is 4 '161' chips, but that's a "real" PITA.
>
I would have though a PAL/GAL solution would have been better for speed and
cost in this type of application??
Of all things, the palmtop I use a lot uses DRAM as it's main RAM - I
was CONVINCED this was SRAM, but it's not. 1/2Mb per chip, and I have 2
(1 Mb) pairs sitting here waiting for a future project. These're
Hitachi RAM, set in TSOP Left & Right sets (reversed pinout for one -
you can Bus the tri-state pins this way) - Interesting stuff. So I now
know that it's quite possible, WITH the right RAM, to go decently low
power (2 weeks off 2 1300mAh NiMH batt's with the rest of the machine
running off the same batteries) - Sorta shocked ME! If I keep upgrading
these machines, someone could talk me out of a pair, certainly you could
talk me out of part numbers (KM416V256ALLTR is the reversed one) - I can
find the other number if you cannot get there from here <G>
I have some info I can dig out that may show how they handle the refresh
process, too.
> There have been lots of discussions about serial SRAM on the list over
> the years. As far as I can tell, there aren't any of any significant size
> out there. I WAS using the Dallas RamPort (DS1380 and DS1381) 'til they
> discontinued them on us... I'm now moving designs over the the PIC18c452
> which has enough RAM for several products. On one product I'm using the
> 18c452 with several latches to drive a 128kbyte SRAM (capacitor backed).
> That takes several chips. Seems like SOMEONE would make a reasonably
> large serial SRAM, but that doesn't seem to be the case.
>
> Harold
>
> On Fri, 2 Jun 2000 09:11:59 +0200 TOM THERON <mmsesysEraseME.....ICON.CO.ZA> writes:
> > PCF8570 from Philips, 256 x 8, i2c interface.
> >
> > Tom
> >
At 05:00 PM 6/5/00 +0100, you wrote:
.......
>>
>> I had also considered going with a '4040, like Octavio, but you can't
>> have multiple data buffers or random access that way. An alternative
>> is 4 '161' chips, but that's a "real" PITA.
>>
>I would have though a PAL/GAL solution would have been better for speed and
>cost in this type of application??
>
>Mike
>
Mike, yes, I considered that approach too. No good if you want
RS-232 or I2C accessibility. However, for simple counting, PAL
is possible. However, you do need 16 output registers [for 64KB],
8/16 inputs for addressing, and 3-4 control lines.
As far as I can tell this would require 2 24-bit PALs in series,
or else go need to go a gate-array. Got any specific suggestions
along this line? PAL or gate-array?
Nonvolatile is nice, but this does have a limited cycle lifetime, even for
reads. Without care to avoid 'burning' some locations of the chip you could
easily reach the lifetime limits in a matter of months of normal operation.
Bob Ammerman
RAm Systems
(high function, high performance, low level software)
Yep, the external RAM chip with a counter for address input makes a lot of
sense. I designed, but never implemented a scheme that would have the
following characteristics:
1: 12 I/O's (or maybe 11? if I recall correctly) required for access
2: easily adaptable to 2^16=64KB, 2^20=1MB, 2^24=16MB or more bytes of RAM
maximum
3: '161 counter chips for address inputs
4: Random access time on the order of about 10-20 PIC instruction cycles.
5: Sequential read access time on the order of about 3 PIC instruction
cycles (bsf CLOCKBIT, bcf CLOCKBIT, movf DATAREG,W).
6: Sequential write access time on the order of about 5 PIC instruction
cycles (movwf DATAREG, bsf CLOCKBIT, bcf WRITEBIT, bsf WRITEBIT, bcf
CLOCKBIT)
By the way, we can kind of tie this thread to the 'PIC on Internet' thread.
A reasonable amount of SRAM, even if non-sequential access is rather
inefficient, would go a long way to implementing a decent protocol stack.
It seems reasonable, but I sure would like to find the logic all wrapped up
in one chip. I even considered something like the XILINX chips, but too many
$$ for chips and especially for tools.
Bob Ammerman
RAm Systems
(high function, high performance, low-level software)
[and occasionally hardware, if it's digital :-)]
Bob Ammerman wrote:
>Yep, the external RAM chip with a counter for address input makes a lot of
>sense. I designed, but never implemented a scheme that would have the
>following characteristics:
>
>1: 12 I/O's (or maybe 11? if I recall correctly) required for access
>2: easily adaptable to 2^16=64KB, 2^20=1MB, 2^24=16MB or more bytes of RAM
>maximum
>3: '161 counter chips for address inputs
>4: Random access time on the order of about 10-20 PIC instruction cycles.
>5: Sequential read access time on the order of about 3 PIC instruction
>cycles (bsf CLOCKBIT, bcf CLOCKBIT, movf DATAREG,W).
>6: Sequential write access time on the order of about 5 PIC instruction
>cycles (movwf DATAREG, bsf CLOCKBIT, bcf WRITEBIT, bsf WRITEBIT, bcf
>CLOCKBIT)
>
I have a 20Mhz SRAM board I designed/had built [but still sitting in the
box], which uses 4 74AC161 chips + logic, but this is rather bulky for
a little PIC embedded system. So, I looked at putting the counter/logic
in a PAL, but here it even takes 2 24-pin chips AFAICT.
===========
>By the way, we can kind of tie this thread to the 'PIC on Internet' thread.
>A reasonable amount of SRAM, even if non-sequential access is rather
>inefficient, would go a long way to implementing a decent protocol stack.
>
Would this stack require extra code space, or just data RAM?
==============
>It seems reasonable, but I sure would like to find the logic all wrapped up
>in one chip. I even considered something like the XILINX chips, but too many
>$$ for chips and especially for tools.
>
Ha, in my neighborhood that's what you call a 40-pin PIC. Seems a waste
of a nice little PICy just to access address/data/control lines, but it
does unfortunately take all the available lines on the PIC - but then you
also have RS-232/I2C/custom s.w./etc capability. Try that on XILINX.
Bob Ammerman wrote:
>
> Yep, the external RAM chip with a counter for address input makes a lot of
> sense. I designed, but never implemented a scheme that would have the
> following characteristics:
I used this approach to aquire data from a PIC 74 at 10K samples and
store to a 128K RAM chip with inbuilt battery backup. (Dallas)
If you are using DIP RAM chips you can mount the address decoder
directly under the chip to save space. 10 pins to the PIC (8 for data),
but limitation is sequential read/write. Add a parallel to serial chip,
and probably 4 PIC pins used.
The track layout can be simplified because all the Q outputs from the
binary counter chip can be connected in any order to any of the RAM
address pins. The data will still read in or out the same for any given
address. Using this approach I just fanned out the address leads to the
nearest RAM pin.
Bob Ammerman wrote:
.....
>> I have a 20Mhz SRAM board I designed/had built [but still sitting in the
>> box], which uses 4 74AC161 chips + logic, but this is rather bulky for
>> a little PIC embedded system.
>
>*** Want to sell one?
>
Oops, I mis-spoke here. Should have said [note **additions** below]:
I have a **LOGIC BOARD WITH** 20Mhz SRAM **CAPABILITY EMBEDDED INTO IT**,
that I designed/had built [but still sitting in the box], which uses
4 74AC161 chips + logic, but this **CONCEPT** is rather bulky for a
little PIC embedded system.
Sorry. This isn't actually a RAM board, per se, but rather a logic board
with a bunch of other chips, all controlled by a 50mhz SX28, etc. It
has only 1 32Kx8 SRAM chip.
Hmmm, maybe I should redesign it, and sell it as a "RAM board". But
those 4 '161 chips/etc take up a lot of room. Would want to go with PAL
or something else in a re-design.
However, I do have actual "RAM board" pcbs in hand that I recently designed
--> 2 32Kx8 skinny SRAMs controlled by a PIC16C64/74. 2"x2", but much
slower/etc than above - as noted in a previous msg. Firmware is currently
vaporware.
===================
>> Ha, in my neighborhood that's what you call a 40-pin PIC. Seems a waste
>> of a nice little PICy just to access address/data/control lines, but it
>> does unfortunately take all the available lines on the PIC - but then you
>> also have RS-232/I2C/custom s.w./etc capability. Try that on XILINX.
>
>*** Yes: this is _EXACTLY_ right! (except for dedicated high speed logic, of
>course - A PIC can't create multiple multi-megahertz counters/shift
>registers/state machines). OTOH - I suppose it wouldn't be that big a deal
>to implement a UART or I2C on XILINX. The 'custom s.w. is another case of
>course). I guess it just comes done to using the right tools for the job.
>
"right tools for the job" or the cheapest tools for the target market
:-)). Even at $4/PIC, the PIC sol'n is just about competitive I think with a
couple of 24-pin PALs, or 4 counters + misc logic [factoring in real
estate/etc],
XILINX, etc/etc. In small qty.
Another possible is going to a 48/52-pin Scenix - could probably get
4-5 MByte/sec read/writes. Plus, of course, ability for custom s.w. again.
I did consider this route - shrunk back at using PQFP chips.
I am still looking at a custom PAL design. On and on.
MITVMA.MIT.EDU
