Shop OBEX P1 Docs P2 Docs Learn Events
SRAM and questions — Parallax Forums

SRAM and questions

Matthew HayMatthew Hay Posts: 63
edited 2006-12-13 00:36 in Propeller 1
Has anyone attached any external RAM to the prop yet?· I'm looking for an SRAM chip to add to the Prop (which should arrive this week) with minimal extra hw.· Right now I'm not to concerned with the size but I'm wanting it in a DIP package with either 8 or 16 bit parallel data port and 3.3V.· I've tried searching through Digikey, Mouser, and Jameco but unfortunately I can't find what I want in a DIP package or 3.3V.· Ofcourse I've never went looking for memory in which I didn't already have a specific part number so I'm kind of lost here,·any information on where to look for something like this would be appreciated.

Also if I'm reading the Prop Manual correctly the cogs all have access to the pins no matter what the hub state right? so external memory should allow a faster access time then access to the hub memory?

Also anyone know of a cheap/easy to implement DIY touchscreen addon?· I've thought of an array of IR transmitter / recievers but wanted to know of any other possibility that would allow for a touch sense, so that if someone has their finger hovering but not touching I won't get a false reading).

Sorry if these are some dumb questions.

-Matt

Oh and just curious, why make spin an interpreted language instead of a compiled language?

Post Edited (osmoses) : 12/12/2006 10:55:12 PM GMT

Comments

  • AndreLAndreL Posts: 1,004
    edited 2006-12-12 23:17
    Next month look for an external SRAM cartridge for the HYDRA. And SPIN is interpretted by a byte code interpreter based on a number of decisions, which I would hypothesize are (I can't speak for chip directly of course):

    1. Since there is a byte code interpreter in there, then any language that targets the interpreter can run on the prop. So once Chip/parallax release the byte code specification or someone reverses is then people cna create any HLL that targets the byte code. And as long as the interpreter runs on one cog then the spin code bytes can be any size at all and come from hub memory, makes the architecture of the execution model easier.

    2. Each COG only has 512 words of memory, to support compiled programs a large memory model, caching and paging has to be built into the tool. When chip designed this chip, I don't think he was thinking of huge programs running, but smaller fast programs running, so 512 words probably seemed enough for ASM programs, but if HLL were to compile directly to ASM, it would eat that memory up pretty fast and not be as efficient at the byte code intrepreter as far as memory is concerned, it would be faster of course.

    3. You do NOT have to use spin or the interpretter if you don't want to, just write your own compiler and your own byte code interpreter. The spin system is just to help you get started, many people have already created their own compiled languages, byte code interpreters and so forth.

    4. Writing an optimizing compiler is HARD [noparse]:)[/noparse]

    Andre'
  • Mike GreenMike Green Posts: 23,101
    edited 2006-12-12 23:30
    1) All cogs have access to all the I/O pins (although only one cog can output at a time). The speed of external memory vs. hub memory depends on how you implement it. If you use most/all the I/O pins for address and data, it may be the same speed or slightly faster on average. If you need to multiplex anything, external memory will be slower than hub memory.

    2) The best completely DIY touchscreen would use IR emitter/sensors. Pretty much anything else needs a resistive membrane or special ultrasound emitter/sensor, not something for DIY.

    3) To reiterate Andre''s comment: Producing efficient instructions from a compiler is very very hard. With the extreme space constraints for assembly (512 instructions + data), it's not likely that you could have a compiler generate efficient code for any but the simplest program. Timing is also important for a lot of what would be done in assembler on the Propeller and a compiler is unlikely to do even a reasonable job on timing and space efficiency. SPIN is a very useful and reasonably powerful language that runs efficiently with minimal resources (one cog) on a Propeller and allows access to essentially all of the Propeller's features.
  • Paul BakerPaul Baker Posts: 6,351
    edited 2006-12-13 00:03
    With SRAM you can either get DIP with 5V supply or surface mount with 3.3V. Around the time they were migrating to 3.3V is the same time they were moving away from DIP packaging. It isn't any faster to access external SRAM than it is to access hub memory, you still have to advance the address and with writes toggle the /WE pin and handle the data, plus hub operations can work in 32 bit values, with only 32 IO pins you cant possibly deal with 32 bit data unless you're using latches and that slows access down even further to the point where it's slower than a hub access for the same width of data. With 8 bit data, you are about equal with reads being a little faster and writes being about the same or a little slower.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Paul Baker
    Propeller Applications Engineer

    Parallax, Inc.
  • Matthew HayMatthew Hay Posts: 63
    edited 2006-12-13 00:36
    Thanks for the replys.

    I wasn't trying to say anything bad about SPIN or that fact it is interpreted, I was just curious.

    So I really need to use SM with an adaptor board to get what I want or a Hydra SRAM cartridge with a connector that's found on the Hydra main board.

    So in theory could the external SRAM be used as a frame buffer . . . guess I'll wait till I get my PEKit to look into the video more and find out exactly how it works.

    Thanks again,
    Matt
Sign In or Register to comment.