home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / sci / electron / 18796 < prev    next >
Encoding:
Internet Message Format  |  1992-11-12  |  1.6 KB
  1. Path: sparky!uunet!gossip.pyramid.com!olivea!isc-br!tau-ceti!jimc
  2. From: jimc@tau-ceti.isc-br.com (Jim Cathey)
  3. Newsgroups: sci.electronics
  4. Subject: Re: microcontrollers
  5. Keywords: sizes? External Memory Capability
  6. Message-ID: <2820@tau-ceti.isc-br.com>
  7. Date: 12 Nov 92 18:52:15 GMT
  8. References: <11NOV199219370593@rigel.tamu.edu>
  9. Organization: ISC - Bunker Ramo, Spokane, WA
  10. Lines: 26
  11.  
  12. In article <11NOV199219370593@rigel.tamu.edu> rahhelp@rigel.tamu.edu (Ronald A. Huizar) writes:
  13. >planning to use the MC68HC811E2 can only address about 64K of external 
  14. >...
  15. >about 3 Meg of memeory. To much for the E2. So I know that the 
  16.  
  17. Ever heard of bank-switching?  Your massive data needs can be easily
  18. handled this way, because you don't need simultaneous access to all
  19. that data.  Your application is specific (and simple) enough that you
  20. can afford to call a subroutine to fetch each sample from RAM that's
  21. not directly in your address space.  No problem.  A similar technique was
  22. used in many external print spoolers, which had 8048's in them.  These
  23. only can directly address something like 2K of memory (my memory's
  24. fading fast), but these used clever bit-banging techniques on DRAMs
  25. connected to I/O ports to store hundreds of K of data.
  26.  
  27. Engineering Rule #3b:  Work smart, not hard.
  28.  
  29. -- 
  30. +----------------+
  31. ! II      CCCCCC !  Jim Cathey
  32. ! II  SSSSCC     !  ISC-Bunker Ramo
  33. ! II      CC     !  TAF-C8;  Spokane, WA  99220
  34. ! IISSSS  CC     !  UUCP: uunet!isc-br!jimc (jimc@isc-br.isc-br.com)
  35. ! II      CCCCCC !  (509) 927-5757
  36. +----------------+
  37.             "PC's --- the junk bonds of the computer industry"
  38.