Shop OBEX P1 Docs P2 Docs Learn Events
Memory add-on for the Propeller QuickStart useful for large C programs — Parallax Forums

Memory add-on for the Propeller QuickStart useful for large C programs

David CarrierDavid Carrier Posts: 294
edited 2013-04-04 17:28 in Propeller 1
I have had a memory add-on for the QuickStart on my to-do list for a while, and I now have time to work on it. There are several options, so I wanted to get some opinions on what would make it most useful for large C programs.

There are two routes to take. One route is a specialized board with a single type of memory, and only that type, leaving most I/O pins free. The second route is a board including every reasonable type of memory that an end product could use.

The first route targets a large percentage of developers, but will not have the types of memory some developers need. It could be a standard way to get started in C programming, buying it and the QuickStart together for around $50. It needs to be a type of memory that everyone is happy with, which means it should give the most bang for the buck.

The second route demonstrates the kinds of memories that are available and how well the Propeller works with them, but would not, in its entirety, be integrated into an end design. It is especially useful for developing and testing programs with each type of memory, to compare the results and decide what type to put into each individual design.

Here are the types of memories that I was looking into and a few part numbers for different sizes: If I go the first route, it would be just one of the above types of memory. If I go the second route it would probably be all of them.

Along the lines of the first route, I could also make a card that plugs into the socket on the Human Interface Board or Propeller Demo Board that adds a Quad SPI chip to make it easy to use large C programs with them. It could be quite cheap, maybe $15, but would require a Propeller QuickStart and Human Interface Board, which are $55 together. It could also work with breadboard projects.

Going down one route now does not preclude going down another route later, and having both boards available, but right now I am only working on one design.

Here are the questions I would like to get your opinion on:
  • Which route should the design take?
  • Which memory type would you prefer?
  • How should I connect it to get the most performance? (e.g. Connecting two Quad-SPI devices with their data pins on P7..P0)
  • Are there any other memory types that I should look into?
— David Carrier
Parallax Inc.
«1

Comments

  • Invent-O-DocInvent-O-Doc Posts: 768
    edited 2013-01-24 14:02
    Use quick start format, which is also useable on new project board. Want cheapest solution to run xmm. Probably won't buy it myself, would buy prop 2 if I need more memory.
  • SRLMSRLM Posts: 5,045
    edited 2013-01-24 14:54
    I would buy a board with a collection of the memory types iff there were useful* examples of using each type of memory with a PropGCC memory model.

    *I'm using useful here to mean: it demonstrates the functionality, it allows for contrasting between the various memory types, and it's well documented.
  • jazzedjazzed Posts: 11,803
    edited 2013-01-24 16:48
    Hi David,

    Glad you have time for this now.


    In my perspective the best bang for the buck in terms of pin count, cached performance, and chip cost is the dual QuadSPI Flash. One can argue that two QuadSPI chips are better than one with 10 pins total being used because performance is much higher reading a byte at a time on P0..P7 rather than using a single bit or 4 bits.

    Another reason I like 2x QuadSPI is that it is possible to make one chip QuadSPI Flash and another chip QuadSPI SRAM - this requires another pin for chip-select though and could be a jumper option (just inverting the chip select between the devices is not good enough).


    Different Memory Sizes
    QuadSPI Flash 1MB to 8MB per chip (XMMC only)
    QuadSPI SRAM 128KB per chip
    Single bit SPI Flash 256KB to 2MB+ per chip (1MB is the sweet spot) (XMMC only)
    EEPROM 64KB, 128KB, 256KB, 512KB (XMMC only)
    Standard SRAM up to 512KB per chip
    SDRAM 32MB to 128MB per chip (32MB x 8 bit is common)
    SDCard 2GB to 16GB (XMMC only)


    There are different optimizations for different considerations.

    Performance
    Memory Density
    Pin Count
    Cost
    Durability


    Performance
    The best cached perfomance is with a 10 pin (8 data bit + 2 control lines) Flash solution using XMMC (only code in external memory).
    XMMC also supports SRAM and the code can be loaded from SDCARD.
    The best non-cached perfomance, which Propeller GCC does not support, uses practically all propeller pins.

    Cached XMMC performance from best to worst:

    1) 10 pin 8 bit Quad-SPI Flash with data on pins P0..7 and control on any lines except P8 (prefer higher number IO pins).
    2) 10 pin 8 bit Quad-SPI SRAM with data on pins P0..7 and control on any lines except P8 (prefer higher number IO pins) boot from SDCard.
    3) Many pins SDRAM solution booting from SDCard.
    4) Many pins standard SRAM solution booting from SDCard (less address setup time, but slower burst read).
    5) 6 pin, 4 bit Quad-SPI Flash with data on pins P0..3.
    6) 6 pin, 4 bit Quad-SPI SRAM with data on pins P0..3 boot from SDCard.
    7) Single bit SPI Flash.
    8) Single bit SPI SRAM boot from SDCard.
    9) EEPROM >= 64KBytes.
    10) Worst performance: running code from SDCARD.

    Memory Density
    QuadSPI Flash can provide great code density and speed, but sometimes a solution may need more SRAM for global data. There is only so much one can do with 32KB memory.

    XMM-SINGLE or XMM-SPLIT provide the highest density. XMM-SINGLE can be used with a large SDRAM or SRAM. XMM-SPLIT can be used with a design like the C3.

    Pin Count (fewest to most)
    1) 2 pins: EEPROM provides the best pin count solution. A single 128KB EEPROM can hold lots of code but it is very slow (faster than SDCard though).
    2) 4 pins: Single bit SPI Flash or SDCard. There is a SPI Flash on an SDCard for boards that have an SDCard slot. Single bit SPI Flash is much faster than EEPROM and has greater density.
    3) 6 pins: QuadSPI Flash
    4) 10 pins: 2xQuadSPI Flash
    6) Standard SRAM or SDRAM

    Cost (cheapest to most expensive)
    1) Single bit SPI Flash (fast XMMC and relatively high density)
    2) QuadSPI SPI Flash (fast XMMC and relatively high density)
    2) QuadSPI SPI SRAM boot from SDCard (fast XMMC and relatively high density)
    3) EEPROM
    4) SDRAM low cost per MByte
    5) Standard SRAM
    6) FRAM (I2C or SPI)

    Durability
    NOR Flash is the least durable.
    EEPROM is more durable than NOR Flash.
    SDCard (NAND Flash) is more durable than EEPROM.
    FRAM is more durable than SDCard.
    Any SRAM or SDRAM is most durable.


    Thanks,
    --Steve
  • RaymanRayman Posts: 14,665
    edited 2013-01-24 18:12
    jazzed, that's a very nice overview.

    I am curious why you suggest not using P8 as a control line for dual-SQI.
    Can you elaborate on that point?
  • jazzedjazzed Posts: 11,803
    edited 2013-01-24 19:33
    Rayman wrote: »
    jazzed, that's a very nice overview.

    I am curious why you suggest not using P8 as a control line for dual-SQI.
    Can you elaborate on that point?

    There was some interference from P8 in another design I did. I got the two ideas confused.
    Looking at the byte-wide code that I have, it doesn't seem to matter.
    ' Write to flash from HUB
:data
  rdbyte  outa, ptr     ' P0..7 data
  or      outa, TCLK    ' clock high (CTRA could drive clock, but not used)
  add     ptr, #1       ' next byte
  djnz    len, #:data   ' do until len bytes are stored

' Read from Flash to HUB optimized with CTRA driving clock.
:loop
  mov     data,ina      ' read byte
  wrbyte  data,phsb     ' write to hub pointer
  djnz    len,#:loop    ' do until len bytes are stored
  • RaymanRayman Posts: 14,665
    edited 2013-01-25 02:41
    David,
    I'm working on my own board (RamPage 2), but I'll give my advice anyway...

    I'd say uSD for sure, that's a no-brainer.
    Second eeprom is interesting idea. Maybe I'd just leave an empty socket for one...

    As to flash and/or sram and width... It's a tough choice.
    If this is the only thing going to be attached to the Prop, I'd go with 8 or 16-bit wide SQI bus.
    Maybe it's possible to fill only a 4-bit bus and leave empty sockets or SMT pads to fill up to 16-bit bus...

    You definitely want flash. Whether or not you want sram is debateable. (I was disappointed to hear that running GCC or Catalina using SRAM for memory is rather slow).

    My RamPage2 only takes up a fraction of the area of the Quickstart.
    If you intend on a board the same size as Quickstart, you could add a lot more stuff...

    If you added VGA, KB, mouse and headphone connectors, then you have a pretty nice system...
  • RaymanRayman Posts: 14,665
    edited 2013-01-25 06:01
    jazzed, I think you're saying that one should worry about pin-pin coupling or noise if the control signals are close to the data signals.
    I was worried that you were saying there was a fundamental performance problem using P8.

    I have the clock signal (P8) right next to D7 (P7) on Rampage2. Maybe that's a worst case scenerio then... Hopefully I won't have this issue,
    and I'll know that I'm immune to interference from other pins.

    If I moved these signals somewhere else, then I'd have to worry about the user putting something on P8 that causes random errors that would probably drive them crazy...
  • jazzedjazzed Posts: 11,803
    edited 2013-01-25 08:10
    Rayman wrote: »
    jazzed, I think you're saying that one should worry about pin-pin coupling or noise if the control signals are close to the data signals. ...

    Interesting thought, but I didn't say that and I'm not sure there is any reason for concern. Maybe you can share your own experiences with it so we can fully understand what you mean.

    Are you able to program and read SQI in single bit mode? I've been told they don't work entirely in single bit mode.
  • jac_goudsmitjac_goudsmit Posts: 418
    edited 2013-01-25 11:45
    I think this is a great idea, as long as the pins can be jumpered somehow. I know using the lowest pins might make it more efficient because the code may not have to do any bit shifting, but for this exact reason, users may want to keep the lowest pins available for other hardware.

    If it's too difficult to make the pins configurable, maybe an alternative would be at least make it possible to let the Prop take the memory off the pins (High-Z mode) by using an extra pin. That way other hardware can use the same pins at least some of the time.

    In projects where performance is not an issue but the number of used pins is, the external memory should really be on the same two pins as the EEPROM, and work with I2C instead of SPI. I don't know if I2C RAM is available; a quick Google search says it isn't.

    ===Jac
  • RaymanRayman Posts: 14,665
    edited 2013-01-25 11:47
    There is an I2C to SPI converter chip that could be used... It would actually allow to talk to 4 different SPI devices... Throughput is pretty good too...
    But, probably not as fast as a direct connection...
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2013-01-25 17:06
    I'm excited by the 23LC1024 serial SRAM. Particularly as it is pin compatible with chips with less memory so you can have an 8 pin socket and simple change over the ram chip if you run out of memory. One good reason to add a DIP socket as well as a surface mount one. But maybe with the prices the way they are, you would never use chips with less memory than the 23LC1024 any more?

    I'm in two minds about flash. All the boards I build really need an SD card as a minimum as it is such a convenient way of moving large amounts of data/files from a PC to a propeller (.bmp's for instance) rather than downloading. And then when you have a SD card, the SD card can replicate all the things flash ram can do. At least as far as I can see. So 4 pins for SD and 4 for 23LC1024 and that leaves a lot of pins free. Then again, so easy to add just the pads for other chips and the end user can add them as needed. Surface mount pads don't take much room.

    jazzed's post #4 is a great summary.
  • jazzedjazzed Posts: 11,803
    edited 2013-01-25 18:09
    @Dr_Acula,

    I understand your point, and Propeller GCC has an automated SDCard to SRAM bootstrap feature to serve that need. Also Propeller GCC can run code just as fast from SRAM as it can from Flash in code only mode.

    My main concern with the 23LC1024 quad serial SRAM -vs- quad serial Flash though is program code density. Flash storage is easily 10x greater than 24LC1024. One could add a 2->4 decoder to get 512KB (etc...), but that's more real-estate too.

    Of course if you use two 23LC1024's in a byte wide configuration, you automatically get 256KB with the right cache driver.

    You've probably seen the SpinSocket Flash pictures:

    http://forums.parallax.com/attachment.php?attachmentid=98788&d=1358883277
    http://forums.parallax.com/attachment.php?attachmentid=98791&d=1358883757

    Those 2 little SOIC-8 parts can be Flash, SRAM, or both (or ADCs). That flexibility is a compelling case to me.

    The Propeller USB Key design has the same idea, on board USB, and an SD Card socket. I have boards, but need some QFN skills to help making it.I'd be happy to opensource it "as-is" at this point. I've considered redesigning it with the FT230 chip.
    http://forums.parallax.com/showthread.php/134602-Propeller-USB-Key?p=1037109&viewfull=1#post1037109
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2013-01-26 03:42
    I haven't seen those - nice boards jazzed!

    I'm not so good with any sort of surface mounting soldering but I'm quite happy to design DIP boards and some clever boffin can shrink them down later. Your USB Key sounds nifty.

    Re add-on memory, I have this general idea that one can have a motherboard and one can have daughter boards and can add on different types of memory in various ways and just change the software. I'm sure David is thinking along the same lines.

    I got stuck about 6 months ago with the touchscreens as they are so nifty but they took so many pins that all the cached GCC things didn't work. So - 6 months later and lots of designs later and I think I have an answer and it uses just 12 pins to talk to a touchscreen. With all the pins saved cf previous designs, I can see some very interesting synergies with what David is building and the whole GCC project.

    In general terms, I like the concept of buying a propeller chip, writing code and having fun, eventually running out of space, and then adding on various cheap and small memory expansion boards as the code expands. Spin doesn't work with this idea, but C does and I can envisage some really interesting modular designs. I very much agree that flexibility is a compelling case.
  • jazzedjazzed Posts: 11,803
    edited 2013-01-26 11:34
    So, what a could a memory or other plugin module look like?
    Quickstart stacking modules would probably be easiest except for tall component problems.

    Here is an alternative using generic "AppMod" style Dual row headers compatible with the HID single row header. 
    Odd side:

VIN
3.3V
P0..P7 data
GND
GND

Even side:

VIN (or key plug)
5.0V
P8..P16
GND
GND
  • WBA ConsultingWBA Consulting Posts: 2,934
    edited 2013-01-26 20:06
    I have a comment that comes from a theme I have deduced from various threads on the forum in the past months. Wouldn't it seem like a good idea to release a different version of the Quickstart specifically geared for dealing with add-on memory or other caveats of C users? Make a quickstart with options for memory ICs as discussed here, uSD, 5 volt rail, and an ADC chip. The memory ICs and ADC should be placed in a way to allow connections to pins chosen by the end user to some degree.
  • AntoineDoinelAntoineDoinel Posts: 312
    edited 2013-01-27 04:51
    Specifically referring to the QuickStart + Human Interface combination:

    I've come to the conclusion that at least 4 more pins could be recovered, to be used for a memory expansion.

    I mean, it's nice to have VGA and TV working at the same time, but how many times are you really going to use both at once?

    So one possible solution could be a memory expansion board that sits between QS and HIB and remaps some signals.
    This is made even easier by the design of the Human Interface Board, having amplified signals and very light load on propeller pins. TV then could easily share pins with VGA, uSD be moved to P12..P15, and a DemoBoard-like 8-pin connection, with the just recovered P0..P7 pins, made available for expansion.

    The layout would have one 2x20 male header on the underside, plugging to the QS, and one 2x20 female socket on the opposite site, reversed, to connect the HIB (which ends "reversed" too wrt to QS, but that's not an issue, I think).


    Pin (re)mapping
    • QS P0..P7 ends on the intermediate board, used for the memory interface. It's not propagated to the HIB!.
    • QS P8..P11 = pass thru to HIB, same pins.
    • QS P12..P15 = remapped to HIB P0..P3 (HIB uSD and HIB upper connector "P0..P3").
    • QS P16..P19 = pass thru to HIB P16..P19 (VGA) and also connected to HIB P12..P15 (TV).
    • QS P20..P23 = pass thru to HIB P20..P23 (VGA) and also connected to HIB P4..P47 (HIB upper conn. "P4..P7").
    • QS P24..P31 = pass thru to HIB, same pins
    Also the extra pins (RTS, CTS, etc) are passed thru to the HIB.


    Memory expansion

    Between the two connectors, there is plenty of space to place four 8-pin SMT chips:
    • 1x SN74LVC1G29 decoder
    • 2x 23LC1024 SRAM chips (256KBytes total)
    • 1x SQI Flash chip (2MBytes, or more?)
    • A few LEDs to indicate activity, placed in a row in front of the chips, near the "downlink" connector, so they are visible from that side... maybe 2 green for SRAMS, 1 yellow for uSD (P15), 1 red for Flash... no more blue, there are enough on of them already on the other two boards! :lol:

    Pins used for memory interface

    From QS point of view):
    • P0..P3 = connected to data bus of all the memory chips.
    • P4 = clock shared by all the memory chips.
    • P5 = master chip select to the 1G29 decoder.
    • P6..P7 = decoder address inputs, to select one of SRAM0 (Y1), SRAM1 (Y2), FLASH (Y0)

    Now I would design and make a few of those boards myself, if only I had the time.
    But if anyone likes the idea, feel free to use it.

    Alessandro
  • Bill HenningBill Henning Posts: 6,445
    edited 2013-01-29 14:15
    Hi David,

    I've designed a board that is a superset of what you are thinking about. Due to other commitments, I have not been able to finish the 8-bit wide drivers yet; the 4 bit SRAM drivers work.

    QuickLMM+ supports SRAM/FLASH/EEPROM in the "standard" QSPI compatible pinout, supporting one or two chips per bank, at one, two or four bits each, on D0-D7, with additional control logic for multiple banks, a uSD card, and more :)

    It fits the QuickStart (and now Propeller Project Board USB)

    I have found a couple of minor errata on the initial short run, but expect to have fully debugged boards in roughly 4-6 weeks.

    QuickLMM+ features:

    - up to six SOIC8/TDFN8/DIP8 QSPI memory devices (in pairs to form an 8 bit bus)
    - micro SD slot
    - optionally provides two 10 pin headers for my 10 pin modules
    - I2C expansion header
    - HCOMM header for SerPlug or 485Plug
    - hacker port allowing eight more qspi devices to be attached

    Photos and info at: http://forums.parallax.com/showthread.php/142826-The-Courier-dropped-off-the-prototypes-for-three-new-PCB-designs-today

    Sapieha did a beautiful job laying out the PCB as usual...
    David Carrier wrote: »
    I have had a memory add-on for the QuickStart on my to-do list for a while, and I now have time to work on it. There are several options, so I wanted to get some opinions on what would make it most useful for large C programs.

    There are two routes to take. One route is a specialized board with a single type of memory, and only that type, leaving most I/O pins free. The second route is a board including every reasonable type of memory that an end product could use.

    The first route targets a large percentage of developers, but will not have the types of memory some developers need. It could be a standard way to get started in C programming, buying it and the QuickStart together for around $50. It needs to be a type of memory that everyone is happy with, which means it should give the most bang for the buck.

    The second route demonstrates the kinds of memories that are available and how well the Propeller works with them, but would not, in its entirety, be integrated into an end design. It is especially useful for developing and testing programs with each type of memory, to compare the results and decide what type to put into each individual design.

    Here are the types of memories that I was looking into and a few part numbers for different sizes: If I go the first route, it would be just one of the above types of memory. If I go the second route it would probably be all of them.

    Along the lines of the first route, I could also make a card that plugs into the socket on the Human Interface Board or Propeller Demo Board that adds a Quad SPI chip to make it easy to use large C programs with them. It could be quite cheap, maybe $15, but would require a Propeller QuickStart and Human Interface Board, which are $55 together. It could also work with breadboard projects.

    Going down one route now does not preclude going down another route later, and having both boards available, but right now I am only working on one design.

    Here are the questions I would like to get your opinion on:
    • Which route should the design take?
    • Which memory type would you prefer?
    • How should I connect it to get the most performance? (e.g. Connecting two Quad-SPI devices with their data pins on P7..P0)
    • Are there any other memory types that I should look into?
    — David Carrier
    Parallax Inc.
  • RsadeikaRsadeika Posts: 3,837
    edited 2013-02-06 06:30
    So, when can we expect a memory add-on for the QS? Another thing that I would like to see is access to 5V, the modules that I work with require 5V, but no way to access that with any add-on boards that Parallax sells.

    Ray
  • Bill HenningBill Henning Posts: 6,445
    edited 2013-02-06 06:51
    Hi Ray,

    Early to mid March - I responded in more detail in my thread.

    http://forums.parallax.com/showthread.php/142826-The-Courier-dropped-off-the-prototypes-for-three-new-PCB-designs-today...?p=1162095&viewfull=1#post1162095
    Rsadeika wrote: »
    So, when can we expect a memory add-on for the QS? Another thing that I would like to see is access to 5V, the modules that I work with require 5V, but no way to access that with any add-on boards that Parallax sells.

    Ray
  • jazzedjazzed Posts: 11,803
    edited 2013-02-06 08:05
    A new QuadSPI RAM cache driver would be appreciated. Let me know if you need any help.

    When can we expect hardware from Parallax is an important question to answer.
  • David BetzDavid Betz Posts: 14,516
    edited 2013-02-06 08:12
    jazzed wrote: »
    A new QuadSPI RAM cache driver would be appreciated. Let me know if you need any help.

    When can we expect hardware from Parallax is an important question to answer.
    There is already a QuadSPI SRAM cache driver that works with Ray's RamPage2 module. Depending on how Bill's module differs from Ray's, it probably isn't difficult to get the driver to work with Bill's.
  • RsadeikaRsadeika Posts: 3,837
    edited 2013-02-06 09:54
    Actually, my last post is directed at Parallax, and to Bill, no offense, but I like completed boards, at a reasonable price, and not kits. Having access to 5V has to be mentioned again.

    Ray
  • David BetzDavid Betz Posts: 14,516
    edited 2013-02-06 10:37
    Rsadeika wrote: »
    Actually, my last post is directed at Parallax, and to Bill, no offense, but I like completed boards, at a reasonable price, and not kits. Having access to 5V has to be mentioned again.

    Ray
    Ray's RamPage2 is a completed board. You have to plug it into a Propeller host board though. It just has the memory chips. That's pretty easy to do.
  • David CarrierDavid Carrier Posts: 294
    edited 2013-02-20 09:12
    I’ve done some research, and here’s a few things I’ve found:
    • The non-volatile SPI SRAM is not quad SPI, but the quiescent current difference is marginal, so we can still add a battery backup to the normally volatile quad-SPI SRAM.
    • A US-built QuickStart add-on would have a minimum cost of around $30, mostly for connectors, labor, and overhead. The cost of the active components ends up having a minimal effect on the total price, so it won’t be much cheaper to have just one type of memory.
    • Between my last post on the subject and now, I have started the process to move the Human Interface Board manufacturing overseas, which means a likely future price drop.
    The third route is looking like the best option; a surface-mount only board that is easy to manufacture and will work in a breadboard or a Human Interface Board. There are only enough I/O pins for one SPI device at a time in 4-bit mode. I have attached a PDF file of the schematic and layout for such a device.

    It has the traditional connection for two SPI devices, with clock and data shared and a separate pin for each devices chip select. There is a free I/O pin, so I could separate the clocks, if that would add any capabilities. (Perhaps copying data from one device to the other, by setting one to read, setting the other to write, then clocking them together to transfer the data?)

    Let me know what you think.

    — David Carrier
    Parallax Inc.
    pdf
    pdf
    Propeller Memory Card schematic and layout Rev A.pdf
    86K
  • David BetzDavid Betz Posts: 14,516
    edited 2013-02-20 10:05
    It's too bad there isn't enough space on the HIB for even a single SPI flash chip.
  • jazzedjazzed Posts: 11,803
    edited 2013-02-20 10:22
    Got a part number or link for the devices being used? What sizes would be supported?

    Having separate clock would be useful. Someone may want to use one device for code and the second SRAM as a completely separate buffer chip.

    What is the motivation for battery backed SPI SRAM? I'm guessing infinite write cycles.
  • David CarrierDavid Carrier Posts: 294
    edited 2013-02-20 12:17
    Steve,
    I'm currently planning on a Windobond W25Q32FVSFIG for flash memory and a Microchip 23LC1024-I/SN for SRAM. The battery holder is MPD part number BK-912.

    I just realized that the Human Interface Board uses P0 through P3 for the microSD card socket. With the current pinout, if there is a card inserted, it could interpret some of the quad SPI data communications as commands for the SD card. I could either move the quad-SPI data pins to P4 through P7 or include a microSD card socket on the board. Either way, I should use the last unused pin as chip select for the microSD card socket. If having two clock pins too important, I could do something unconventional like tie the microSD card's chip-select pin to the quad-SPI devices clock pin, so that the SD card is never more than one clock pulse away from a falling edge on chip select, thereby unable to interpret any quad SPI communications as a command. It might do odd things with the microSD card though, like draw a lot of power. I tried to look up the timing limits in the official documentation from the SD Association, but it is "blank" in the simplified specification, which is all the SD Association has made public.

    As for the battery backup, it is for anyone developing a program that will use battery-backed SRAM, whether or not it is using flash memory. I'm not planning on including the battery, just the socket. If it ends up affecting the retail price, then I may remove it and leave a solder connection for an external battery.

    — David Carrier
    Parallax Inc.
  • jazzedjazzed Posts: 11,803
    edited 2013-02-20 12:45
    I'm not sure if any of it makes sense with only 3 pins available unless the SRAM can be used with DI and DO connected - a possibility.

    Seems like it would be better to just offer the SDcard-SPI Flash part from Tubular and make a different Quickstart add-on board entirely.
  • RaymanRayman Posts: 14,665
    edited 2013-02-20 13:30
    I like the idea of battery backed RAM although I'm not sure what I'd use it for.
    First thing that comes to my mind is to have 4 of the SPI RAM chips sharing a 4 bit bus with one SQI flash chip.
    Not sure how much sense that would make though...
  • David CarrierDavid Carrier Posts: 294
    edited 2013-02-20 16:16
    How about this, if I move the data bus so it is no longer the using 4 LSBs, it would work with an SD card present, although reading the data may take longer:


    Propeller
    Flash
    SRAM
    SD Card


    P0
    Chip Select
    —
    Data Out


    P1
    Clock
    Clock
    Clock


    P2
    —
    Chip Select
    Data In


    P3
    —
    —
    Chip Select


    P4
    Data 0
    Data 0
    —


    P5
    Data 1
    Data 1
    —


    P6
    Data 2
    Data 2
    —


    P7
    Data 3
    Data 3
    —


    If I added an SD card to the board instead of using the one on the Human Interface Board, I could do something like this:


    Propeller
    Flash
    SRAM
    SD Card


    P0
    Data 0
    Data 0
    Data In


    P1
    Data 1
    Data 1
    Data Out


    P2

    Data 2
    Data 2
    —


    P3

    Data 3
    Data 3
    —


    P4
    Clock
    Clock
    Clock


    P5

    Chip Select
    —



    P6

    —
    Chip Select
    —


    P7

    —
    —
    Chip Select


    Is it worth adding the socket, or could the code be made just as fast either way?

    I figure that with data on P0 through P3, sampling nibbles at 4 4/9 MHz writing data to hub RAM by the long, would compile down to something similar like this, with a data rate 2 2/9 MB/s, assuming well timed clock pulses from a counter module: 
    loop:
     mov Accumulator, ina
     and Accumulator, #$F
     shl Accumulator, #28

     wrlong Response, Index

     mov Working, ina
     and Working, #$F
     shl Accumulator, #24
     or Accumulator, Working

     add Index, #4

     mov Working, ina

     and Working, #$F
     shl Accumulator, #20
     or Accumulator, Working

     nop

     mov Working, ina
     and Working, #$F
     shl Accumulator, #16
     or Accumulator, Working

     mov Working, ina
     and Working, #$F
     shl Accumulator, #12
     or Accumulator, Working

     mov Working, ina
     and Working, #$F
     shl Accumulator, #8
     or Accumulator, Working

     mov Working, ina
     and Working, #$F
     shl Accumulator, #4
     or Accumulator, Working

     mov Working, ina
     and Working, #$F
     or Accumulator, Working

     mov Response, Accumulator
     djnz Count, #loop
    The same thing with the data on P4 through P7 would go like this: 
    Hex_F0 long $F0

loop:
     mov Accumulator, ina
     and Accumulator, Hex_F0
     shl Accumulator, #24

     wrlong Response, Index

     mov Working, ina
     and Working, Hex_F0
     shl Accumulator, #20
     or Accumulator, Working

     add Index, #4

     mov Working, ina

     and Working, Hex_F0
     shl Accumulator, #16
     or Accumulator, Working

     nop

     mov Working, ina
     and Working, Hex_F0
     shl Accumulator, #12
     or Accumulator, Working

     mov Working, ina
     and Working, Hex_F0
     shl Accumulator, #8
     or Accumulator, Working

     mov Working, ina
     and Working, Hex_F0
     shl Accumulator, #4
     or Accumulator, Working

     mov Working, ina
     and Working, Hex_F0
     or Accumulator, Working

     mov Working, ina
     and Working, Hex_F0
     shr Accumulator, #4
     or Accumulator, Working

     mov Response, Accumulator
     djnz Count, #loop
    Either way samples at the same speed. I'm sure there are ways to optimize it, I'm two instructions away from getting the rate up to 2.5 MB/s, but it doesn't seem like selecting which group of pins to mask off makes a difference. Writing would be similar, rotating the output long and writing a masked-off nibble to outa. The only difference is that the output would be rotated before the first write, instead of after. So, would it make a difference?

    Thank you,
    David Carrier
    Parallax Inc.
Sign In or Register to comment.