Shop OBEX P1 Docs P2 Docs Learn Events
Pinout for P2 Edge with SPI PSRAM (AKA the P2-EC RAM)? — Parallax Forums

Pinout for P2 Edge with SPI PSRAM (AKA the P2-EC RAM)?

JRetSapDoogJRetSapDoog Posts: 954
edited 2021-05-15 08:26 in Propeller 2

I want to design a board that will be compatible with the upcoming Edge with SPI PSRAM, called the P2-EC RAM. Sorry, if last week's meeting had an update for the P2-EC RAM, I missed it (though I did check the posted video). But during a Zoom meeting a few weeks back, Chip said that the P2-EC RAM would use P40-57. That breaks down into 16 data pins (four for each of the four memory chips) on P40-P55, and a chip select pin and a clock pin on P56 and P57 (not sure of the order for those). And from somewhere else, I seem to recall that the LED's that are on the current Edge on P56 & P57 would not be present on the P2 EC-RAM (though I'm not sure if that's also true for the P2-EC Rev. C that is in the works). So that would seem to leave P32-P39 (the 8 lower pins of Port-B) entirely free on the P2-EC RAM. I'm just wondering if that is still the plan. I think that the P2-EC Rev. C will likely come out before the P2-EC RAM, so my apologies if I'm chomping at the bit.

Edit: Also, will there be any change to the two not-connected pins just above P37, as on the Rev. B Edge?

Comments

  • The pinout for P2-EC-32MB is not set in stone yet, but it's likely to be ready / shown at the P2LF week after next.

    The two NC's remain as NC pins for the upcoming RevC Edge (P2-EC) and no current plan to change that for the P2-EC-32MB either.

    Provisional P2-EC-32MB pinout:

    P57 CS_abcd (with 10K Pullup)
    P56 CLK_abcd (add cap and R to CLK signal)
    
    P55 SIO3_d  (nibble/byte/word boundary for streamer)
    P54 SIO3_c
    P53 SIO3_b
    P52 SIO3_a
    
    P51 SIO2_d
    P50 SIO2_c
    P49 SIO2_b
    P48 SIO2_a
    
    P47 SIO1_d
    P46 SIO1_c
    P45 SIO1_b
    P44 SIO1_a
    
    P43 SIO0_d
    P42 SIO0_c
    P41 SIO0_b
    P40 SIO0_a
    
    P39 < Possible LED >
    P38 < Possible LED >
    
  • VonSzarvas, thanks for that very useful (provisional) information, and also for the heads-up on the upcoming Live Forum meeting's potential content. And thanks for the details about the caps and resistors on the control pins (Chip had touched on those in the video referenced above, but it is nice to get confirmation or further details).

    As for the possible inclusion of LED's on P39 and/or P38, I presume that they would be buffered so that we could potentially use them for other things (despite some possible flickering). I wonder, though, how beneficial it is to have two LEDs. Yes, two LEDs can conveniently signify, for example, sending and receiving, but the ability to send and receive is almost a given with the chip (and the Prop Plug already does that for P62/63). And a lot of testing can be done with just a single LED (Two LEDs is twice as many as one, but one is infinitely more than none (such as for a simple "is alive" indicator)). But I suppose that having them hi-z buffered would help a lot. However, I'm not sure what restrictions, if any, buffered LEDs would place on how those pins can be used. If there are some restrictions (particularly with using them as inputs), a case could be made for omitting both LEDs to have a full 8-pin group available on Port-B for the user.

    Thanks also for the info about the NC pins. I've routed my board not to connect to those pins (like they way they were handled with the Rev. B Edge). But I asked about it because I seem to recall that one of you folks with parallax briefly asked about the community's receptiveness to a change there. However, I don't think that the question got answered. I'm not sure what kind of change was being considered. But whatever it was, it sounds like it got tabled. So I suppose that it's a mute issue now.

    Anyway, thanks again for your comments (here and elsewhere) and for all your hard work with the new design efforts (and for wrestling with all this stuff, as someone ultimately has to make the hard decisions and choose the good compromises).

  • pik33pik33 Posts: 2,350

    NCs on Edge module after P37 are necessary. The module can be inserted in wrong way into the slot (which I already did) and these NCs protect it from the magic smoke.

  • If these 2 extra P38 and P39 pins are up for grabs and won't be brought out to the edge connector, an option to use them for applications wanting dual independent memory bank control could be handy. So the 4 PSRAM memory devices could be fed with two separate CE pins and CLK pins (servicing 2 chips / 8 data bits each).

    In that case the way to connect them would be to pair them up so a single register write could control two output signals in the same operation, e.g. using a drvl #(1<<6)+CE_PINS changes two pins at the same time. This would still support the current case of a combined single memory bank that is 16 bits wide for the highest performance. That means that P38,P39 would be used for the two CLK pins, and P56,P57 would be the two CE pins, for example.

    You might not be able to share LEDs with CLK pins as this will add some load to the clock signals and we may need these clocks to run as high as 144-175 MHz or so for highest video resolutions/performance. If you want to keep the LEDs the safer option is to share the two CE pins with the LEDs (buffered) and just not use the RAMs when you want some extra LEDs for debug etc. I would wonder though if routing two rather high speed CLK pins right next to each other will interfere vs only using a single clock. The PCB layout would need some care there.

    My current PSRAM driver was developed for a 16 bit wide PSRAM data bus configuration with four devices but in theory at least another one could be modified for an 8 bit wide bus instead, and you could run two driver COGs independently (e.g. one bank for emulator, another one for video) or even run them inline within the emulator COG(s). This 16 bit driver could be trivially modified to drive two pin pairs of control signals without any real changes by just setting bit 6 in the control pin numbers passed in as parameters at startup time and by using the base I/O pin number of the pair by clearing its LSb. All the other instructions apparently just use this pin number in wypin, fltl, wrpins, drvl and drvh instructions according to grep output below, so a minor config change like this should work out nicely and all the transitions on both pairs of control signals would remain synchronized.

    RLs-MacBook-Pro:psram roger$ grep clkpin psramdrv.spin2
                if_nc           getbyte clkpin, pinconfig, #1   'read CLK pin number
                if_nc           fltl    clkpin                  'disable Smartpin clock output mode
                if_nc           wrpin   clkconfig, clkpin       'set clk to Smartpin transition output
                if_nc           wxpin   #1, clkpin              'configure for 1 clocks between transitions
                if_nc           drvl    clkpin                  'set clk state low
    clkpin                                          'shared with code patched during init
    clockpatch      wxpin   #1, clkpin              'adjust transition delay to # clocks
                                wypin   clks, clkpin            'start memory clock output 
                                getbyte clkpin, pinconfig, #1   ' a b c d e |  byte 1 holds CLK pin
                                wypin   clks, clkpin            'start clock output
                                getbyte clkpin, pinconfig, #1   '  a b c d e f | |  byte 1 holds CLK pin
                                wypin   wrclks, clkpin          'start memory clock output 
    
    RLs-MacBook-Pro:psram roger$ grep cspin psramdrv.spin2
                if_nc           getbyte cspin, pinconfig, #0    'read CS pin number
                if_nc           wrpin   #0, cspin               'clear smart pin mode
                if_nc           drvh    cspin                   'setup psRAM pins for all banks
    cspin                                           'shared with code patched during init
                                drvl    cspin                   'active low chip select
                                drvh    cspin                   'raise chip select
                                getbyte cspin, pinconfig, #0    ' a b c d e |  byte 0 holds CS pin
                                drvl    cspin                   'activate chip select
                _ret_           drvh    cspin                   '   a     |     |     d     |    f  de-assert chip select and return
                                drvh    cspin                   '         b     c           e       deassert chip select and continue
                                getbyte cspin, pinconfig, #0    '  a b c d e f | |  byte 0 holds CS pin
                                drvl    cspin                   'activate chip select
                _ret_           drvh    cspin                   '   | | |   d    |  |  |  h ' de-assert chip select or fall through
                                drvh    cspin
    
  • Cluso99Cluso99 Posts: 18,069

    Would there be a software benefit to have the 16 data bits on P32-47? Might save shifting?

  • @Cluso99 said:
    Would there be a software benefit to have the 16 data bits on P32-47? Might save shifting?

    It's not an issue as the streamer can offset the transfers of 16 bits using 8 bit GPIO boundaries.

  • Cluso99Cluso99 Posts: 18,069

    Thanks, good to know.

  • Is there already a spec what ps RAM Chip will be used?

  • Which PSRAM chip that was being considered was mentioned in a Live Forum meeting about two months back. A datasheet was briefly shown. I tried to find the video, but failed (I'm not entirely sure if it was recorded and published). Anyway, I seem to recall that the chip was made by a Chinese company. Just now I searched on the foregoing info and the company Lyontek came up. That seems to ring a bell, so the chip may be one of Lyontek's offerings, though I'm not sure.

    If we get an update on the Edge with PSRAM later this week, perhaps the chosen chip will be mentioned (keeping in mind that the design could have changed since the last time it was discussed). I'm hoping that we will learn the state of P38 and P39 then, too (whether fully free or with buffered LEDs), even if the board is still a ways out. But if not, that's okay. Ken mentioned that finishing the motor driver that Chip et al are working on is a higher priority at present in terms of, I'm guessing, what would best promote the P2 right now and satisfy outstanding customer requests.

  • Not sure what any final chip selection from Parallax will be but those Lyontek PSRAM parts as I understand it are also compatible with this same spec below, except that the ESP ones are rated to 133MHz @ 3.3V vs 144MHz for Lyontek:

    https://www.espressif.com/sites/default/files/documentation/esp-psram64_esp-psram64h_datasheet_en.pdf

    Any other manufacturers of high speed PSRAM with a SPI/QPI interface like these two companies make? I'm not sure. APmemory 6404 is one but that is small page oriented at high speed.

    I notice that Adafruit sell some PSRAM parts for $1.75ea which is pretty cheap (I guess it's possibly Lyontek's part, although the surface is scratched off, why?)

  • cgraceycgracey Posts: 14,133

    Turns out these 8MB PSRAM chips come in 2mm x 3mm packages.

  • @cgracey said:
    Turns out these 8MB PSRAM chips come in 2mm x 3mm packages.

    Very handy, that'll keep the layout wiring nice and short.

  • cgraceycgracey Posts: 14,133

    @rogloh said:

    @cgracey said:
    Turns out these 8MB PSRAM chips come in 2mm x 3mm packages.

    Very handy, that'll keep the layout wiring nice and short.

    Yes. The longest trace will be only ~15mm.

  • Congrats on getting the PSRAM chips so near the pins that they connect to (though I'm not sure from the render whether they have legs or are BGA packages).

    The Live Forum audio dropped out for 15 seconds or so when P38 & P39 were being discussed (topic begins at the 1:57:31 mark in the video recording , with the dropout starting at 1:58:49). But it seems fairly obvious from the board render and the comments after the dropout that LEDs will likely be attached (at least indirectly) to those pins. Is that a buffer chip for the LEDs in the upper-right corner of the P2 in the pic above with the render?

    And congrats on making basically a full computer system on a module, albeit using a microcontroller. We would have killed for this in the 80s or even the 90s, and it's still quite attractive today.

  • pik33pik33 Posts: 2,350

    Wow.

    Now this is (a new kind of) Amiga on a module... It can even fit inside the Amiga without removing the original Amiga...

    Now the question is - when and at what price they are planned to exist in the real world?

  • roglohrogloh Posts: 5,168
    edited 2021-05-27 12:12

    I'm interested to know what non-RAM connected port B signals will be available to the user of the P2-EC module on the reverse side of the module not shown above. Are the remaining pins 38 and 39 still exposed to the edge connector (hopefully buffered before driving the LEDs) as well as all signals from P58-63? Or is it some subset of these pins?

    I'm hopeful the P58-61 boot flash/SD I/O pins would still come out so you could choose to mount an SD card remote from the module in an enclosure for example and not be forced to use the onboard micro SD in all cases, but maybe it's not wired like that any more?


  • The back is not finalised, but here's the latest in-progress snapshot.
    LEDs are buffered; same as P2-EC

    We are trying to keep the right-side clear so that a future comms module/function could be added there. That will really be getting close to a computer module, and allow for things like hosted browser-based coding to realise the dream of becoming OS agnostic and future proof ! For now we can develop that using this module+WX accessory, and in the meantime that right hand spot is handy for a nice big logo :)

    Pricing is tough to judge, but I'd think $69.99 on the new P2-EC and $89.99 on the P2-EC-32MB. No doubt with launch and bundle discounts coming off those once Ken gets to thinking about it!

  • roglohrogloh Posts: 5,168
    edited 2021-05-27 12:52

    Thanks @VonSzarvas , that helps a lot.

    A future Wifi module would be a pretty cool addition for remote programming/debug when available. Maybe if there is any room in the meantime you could bring out the RX/TX/Reset and Vin+5V+3.3V power pins as some 0.1inch spaced holes on the P2-EC-32MB down that right side so people could easily design their own comms modules for this board too. Bluetooth or serial prop-plug or wifi or USB etc...lots of potential options.

  • @rogloh said:
    Maybe if there is any room in the meantime you could bring out the RX/TX/Reset and Vin+5V+3.3V power pins as some 0.1inch spaced holes on the P2-EC-32MB down that right side...

    Nice idea but that won't be possible.

    quick thoughts....
    The most compact way at the moment might be for someone to layout a shield with the right-angle edge socket, and the WX module tucked under that.
    Or solder the WX module and prop-plug header to the 64018 PCB. Both these ways still need power of course :)
    Or just use the 64019 mini-breakout bundle and a WX adapter. Plus a USB powerbank for portable use. That's the simplest way of course- almost no effort at all!! I'm sure we will do it that way "in house" for early development.

  • @VonSzarvas said:

    @rogloh said:
    Maybe if there is any room in the meantime you could bring out the RX/TX/Reset and Vin+5V+3.3V power pins as some 0.1inch spaced holes on the P2-EC-32MB down that right side...

    Nice idea but that won't be possible.

    Thanks for the additional details and the work-in-progress image of the backside, VonSzarvas. Much appreciated! We realize that you don't have to share these things with us.

    As for the "that won't be possible" comment, I wonder if that is more along the lines of "That's not in the cards," as opposed to some constraint(s) that make it impossible or difficult or unwise or unprofitable to do. That response made me think of the old joke about a motorist who asks a gas station attendant for directions to a certain place and the attendant says "You can't get there from here." But even if the above suggestion is technically possible, one can think of various reasons why Parallax might not want to do it, such as it adds another thing to support or document. And obviously it could affect sales of an enhanced module. Or perhaps it just adds more risk of noise on the power rails.

    Anyway, it looks like a great module (along with its enhanced predecessor). I was kind of shocked on seeing the speculative pricing, as I was expecting price increases of about half that, but it is what it is, and I'm no bean counter.

  • Are there any updates on this module?

  • It's in a queue for ordering; we are waiting for the non-RAM version PCBs to arrive first (aka. P2 Edge Rev C). After those are tested the RAM version can be ordered.

    The PCB fab is moving slowly at the moment... (painfully!). Last I saw the non-RAM version is due to arrive ~10th July. They have a 5-6 week lead, which is not typical, but the last couple orders have been getting longer.
    Feels like an eternity since we ordered those boards! But that's where things are. Extrapolating a similar lead on the RAM boards, I'd not expect to see them arriving to Parallax manufacturing before mid September.

Sign In or Register to comment.