Shop OBEX P1 Docs P2 Docs Learn Events
New Propeller Platform USB design — Parallax Forums

New Propeller Platform USB design

Martin HodgeMartin Hodge Posts: 1,246
edited 2015-04-09 19:40 in Propeller 1
Continuing from this thread...

It's alive and well!

DSCF6827s.JPG


It's 3am, more info after sleep.

--Update--

Here is a view of the SD card configured for P16-P19 operation.

DSCF6840s.JPG


The changes to the original design:
  • Added USB activity LED
  • Surface mount power switch
  • Reverse polarity protection diode
  • Removable pull-up resistor pack for uSD card
  • uSD card can be connected to P0-P3 or P16-P19 using solder bridge pads on the back
  • Seiko RTC chip with rechargeable supercap battery backup
  • External reset connection inserted in top header between P31 and GND
  • J11 for access to RTC chip interrupt outputs
  • Right angle reset button for easier access

Most up-to-date layout attached, along with a pallpark cost breakdown in ods format. ppusb_rtc.zip
«13456

Comments

  • RaymanRayman Posts: 13,800
    edited 2012-04-23 03:52
    Looks great! What's J1 for?
  • mindrobotsmindrobots Posts: 6,506
    edited 2012-04-23 05:01
    SWEEEEET!!!

    Looks good, get some sleep!!
  • Martin_HMartin_H Posts: 4,051
    edited 2012-04-23 06:12
    That board is nice looking. The sideways pointing reset button is a nice touch because you can still reach it with a module on top. I also like that you integrated the real time clock and backup battery with the Propeller Platform.
  • Martin HodgeMartin Hodge Posts: 1,246
    edited 2012-04-23 16:51
    Updated info added to top post.
  • william chanwilliam chan Posts: 1,326
    edited 2012-04-23 17:03
    How many pieces will you be making?
  • ColeyColey Posts: 1,108
    edited 2012-04-24 05:31
    Continuing from this thread...

    It's alive and well!

    DSCF6827s.JPG


    It's 3am, more info after sleep.

    --Update--

    Here is a view of the SD card configured for P16-P19 operation.

    DSCF6840s.JPG


    The changes to the original design:
    • Added USB activity LED
    • Surface mount power switch
    • Reverse polarity protection diode
    • Removable pull-up resistor pack for uSD card
    • uSD card can be connected to P0-P3 or P16-P19 using solder bridge pads on the back
    • Seiko RTC chip with rechargeable supercap battery backup
    • External reset connection inserted in top header between P31 and GND
    • J11 for access to RTC chip interrupt outputs
    • Right angle reset button for easier access
    Most up-to-date layout attached, along with a pallpark cost breakdown in ods format. ppusb_rtc.zip

    Hi Martin, it looks great!
    I realise I am a little late with this and maybe you've though about it already.
    Is there any way you can move the uSD card slot closer to the edge of the PCB?
    The reason I ask is that more and more now I provide a case for my projects and uSD slots are always a pain to get right, this being so far from the board edge gives you very little chance of providing a usable slot.

    regards,

    Coley
  • Martin HodgeMartin Hodge Posts: 1,246
    edited 2012-04-24 07:05
    William, I will make as many as is needed. At first in batches of 20-25, with relatively short lead times. I don't foresee there being any more demand than that though. (As of this writing there are still 18 of Gadget Gangster's left at Mouser)

    Coley, I have noticed that and yes there is still time to make changes. I'm pretty sure there's going to be one more revision. Stay tuned.
  • David BetzDavid Betz Posts: 14,511
    edited 2012-04-24 07:22
    William, I will make as many as is needed. At first in batches of 20-25, with relatively short lead times. I don't foresee there being any more demand than that though. (As of this writing there are still 18 of Gadget Gangster's left at Mouser)

    Coley, I have noticed that and yes there is still time to make changes. I'm pretty sure there's going to be one more revision. Stay tuned.
    Have you considered adding a SPI flash chip? This would allow you to run XMMC programs compiled with PropGCC and probably also with Catalina. A single SPI chip would probably be adequate and the data and clock lines could probably be shared with the SD card.
  • GordonMcCombGordonMcComb Posts: 3,366
    edited 2012-04-24 12:13
    Martin, What's the expected retail price point of this again?

    -- Gordon
  • cavelambcavelamb Posts: 720
    edited 2012-04-24 18:16
    Martin, What's the expected retail price point of this again?

    -- Gordon


    And when will they be available???

    I thought the SPI suggestion worthwhile.
    I don't need it (yet) but that's one of the real limitations of the Propeller - mo mem!

    Price is important, of course, but WHENCANIHAVEONE???

    :)

    Richard
  • David BetzDavid Betz Posts: 14,511
    edited 2012-04-24 18:23
    cavelamb wrote: »
    And when will they be available???

    I thought the SPI suggestion worthwhile.
    I don't need it (yet) but that's one of the real limitations of the Propeller - mo mem!

    Price is important, of course, but WHENCANIHAVEONE???

    :)

    Richard
    I guess I should have explained why I suggested the SPI flash chip. If you are going to program the Propeller using either PropGCC or Catalina, you are likely to find that not as much compiled C code will fit in Propeller hub memory as would fit on other more C-friendly microcontrollers because of the relatively low code density of LMM code. However, PropGCC's XMMC mode puts code in external memory (the SPI flash) and data in hub memory and performs pretty well. Having access to 1MB of code space greatly increases the size of programs you can run on the Propeller. I think Catalina probably supports a similar memory model so it would benefit too.
  • cavelambcavelamb Posts: 720
    edited 2012-04-25 04:54
    Ah! Thanks, Dave.
  • T ChapT Chap Posts: 4,198
    edited 2012-04-25 05:02
    Nice looking board! Just curious, is it just a cosmetic pref to not see names or values? Looks a lot cleaner without.
  • 4x5n4x5n Posts: 745
    edited 2012-04-25 06:41
    William, I will make as many as is needed. At first in batches of 20-25, with relatively short lead times. I don't foresee there being any more demand than that though. (As of this writing there are still 18 of Gadget Gangster's left at Mouser)

    Coley, I have noticed that and yes there is still time to make changes. I'm pretty sure there's going to be one more revision. Stay tuned.

    Is it to early for me to pre-order one or two? :smile:
  • Martin HodgeMartin Hodge Posts: 1,246
    edited 2012-04-25 08:58
    Wow, adding a footprint for an SPI memory chip was extremely easy. The only question I have now is, where to connect this pesky CS line.

    It's way too early to be talking about price, but I can definitely say it won't be less than GG was charging.
  • David BetzDavid Betz Posts: 14,511
    edited 2012-04-25 09:21
    Wow, adding a footprint for an SPI memory chip was extremely easy. The only question I have now is, where to connect this pesky CS line.

    It's way too early to be talking about price, but I can definitely say it won't be less than GG was charging.
    Thanks for adding the SPI flash! I'm afraid I'm not a good one to recommend which pin to use for CS. Probably we should get the opinion of other people who are actively using the current PP-USB board. I have one but haven't done much with it other than using it to test PropGCC.
  • JonnyMacJonnyMac Posts: 8,912
    edited 2012-04-25 11:58
    The only question I have now is, where to connect this pesky CS line.

    Until you started this, Martin, I was considering jumping back into the Propeller Platform game. My big gripe with the PP-USB is putting the uSD connections on P0..P3 (you've fixed that). FWIW, this is what I'd like to see:

    P0..P15 are completely free of any onboard hardware
    P16..P19 are used for the uSD
    P27 is SPI MISO
    P26 is SPI MOSI
    P25 is SPI CLK
    P24 would be the CS for an onboard SPI device
    P23..P20 would be free
  • David BetzDavid Betz Posts: 14,511
    edited 2012-04-25 12:57
    JonnyMac wrote: »
    Until you started this, Martin, I was considering jumping back into the Propeller Platform game. My big gripe with the PP-USB is putting the uSD connections on P0..P3 (you've fixed that). FWIW, this is what I'd like to see:

    P0..P15 are completely free of any onboard hardware
    P16..P19 are used for the uSD
    P27 is SPI MISO
    P26 is SPI MOSI
    P25 is SPI CLK
    P24 would be the CS for an onboard SPI device
    P23..P20 would be free
    Why can't the SD card and the SPI flash chip share the same MISO/MOSI/CLK pins?
  • Martin HodgeMartin Hodge Posts: 1,246
    edited 2012-04-25 13:52
    David, reusing the SD card's DI/DO/CLK like you say was the easy-way-out I took because there was room and connections right there. Red is top layer, blue bottom. There's plenty of room for another solder-bridge to select from two positions for the SPI-CS. Running the entire thing on P24-P27 is entirely doable as well. The question is, do you want to be able to access SD and SPI at the same time, or do you want to save pins? (I 'm guessing if a poll were taken it would come out to 50/50. :lol:)

    flash.gif


    Jon, it's your design originally, yes? I wouldn't get my feelings hurt if you took it over to "go big" with it. (Which reminds me, I need to be sure everyone who's contributed gets adequate attribution.)
    738 x 538 - 22K
  • David BetzDavid Betz Posts: 14,511
    edited 2012-04-25 14:08
    David, reusing the SD card's DI/DO/CLK like you say was the easy-way-out I took because there was room and connections right there. Red is top layer, blue bottom. There's plenty of room for another solder-bridge to select from two positions for the SPI-CS. Running the entire thing on P24-P27 is entirely doable as well. The question is, do you want to be able to access SD and SPI at the same time, or do you want to save pins? (I 'm guessing if a poll were taken it would come out to 50/50. :lol:)

    flash.gif


    Jon, it's your design originally, yes? I wouldn't get my feelings hurt if you took it over to "go big" with it. (Which reminds me, I need to be sure everyone who's contributed gets adequate attribution.)
    The GCC XMM code has provisions for sharing a SPI bus between its cache driver (which will want to access the SPI flash chip) and the filesystem driver that handles the SD card. In fact, there can be other clients of the SPI bus as well. This is arbitrated using a lock. So, from GCC's point of view there is no reason why we can't share the same SPI data/clock pins. The only downside is that any other SPI client would have to abide by the locking protocol to avoid collisions. Actually, even that isn't necessary if only a single COG accesses the SPI pins since the cache driver always releases the pins before returning.
  • pedwardpedward Posts: 1,642
    edited 2012-04-25 14:10
    I would go with John's layout. I found that not all SPI devices play nice with eachother. When all said and done, you still have 24 bits available. It's plausible that you might have 1 COG reading/writing to SD while another reads/writes to SPI RAM.
  • JonnyMacJonnyMac Posts: 8,912
    edited 2012-04-25 14:42
    The question is, do you want to be able to access SD and SPI at the same time, or do you want to save pins?

    I would like independent access to the SPI buss and the SD card.
    Jon, it's your design originally, yes?

    Yep; created the original version (DIP devices on the ExpressPCB miniboard layout) for my Nuts & Volts column. Nick had just started his business and I asked him to create kits for my column projects so that I wouldn't have to.
  • David BetzDavid Betz Posts: 14,511
    edited 2012-04-25 15:23
    I don't have any objection to separate pins. I just thought that people often complained about running out of pins. This was a possible solution but the separate pins will likely cause fewer problems with conflcting drivers.
  • JonnyMacJonnyMac Posts: 8,912
    edited 2012-04-25 15:28
    If I'm pulling WAV audio data off an SD card I don't want to be sharing its buss with an SPI ADC used for setting volume, balance, playback speed, etc. I know that's an extreme example, but most of my SD work is with audio playback and I need all the bandwidth on that buss I can get.

    I often expand simple pin IO using I2C or SPI expansion chips. They're easy and plentiful.
  • william chanwilliam chan Posts: 1,326
    edited 2012-04-25 16:37
    Will this board be easier to solder by hand?
    The GG PPUSB is difficult to solder by hand especially near the SD card.

    Will this board later be available for sale at Gadget Gangster website?
  • robbydrobbyd Posts: 6
    edited 2012-04-25 17:31
    Hello Martin !
    Great work !

    Could you tell me where to find this kind of SD Slot and where you get the Eagle Lib for that part ?

    Kind Regards

    robby
  • MJHanaganMJHanagan Posts: 189
    edited 2012-04-25 17:39
    I am very new to this Propeller device but with what little I have done so far I seem to always need an SPI interface, more I/O pins and more programming memory. I also would like to see more open prototype boards (aka shields?) as well as specific daughter boards (complete or in kit form) for the Propeller "platforms". I would much prefer to spend more time programming and playing rather than designing my own one-off circuit boards.

    Where will these be available and when? Will these be completed boards or kits?
  • cavelambcavelamb Posts: 720
    edited 2012-04-25 23:16
    JonnyMac wrote: »
    If I'm pulling WAV audio data off an SD card I don't want to be sharing its buss with an SPI ADC used for setting volume, balance, playback speed, etc. I know that's an extreme example, but most of my SD work is with audio playback and I need all the bandwidth on that buss I can get.
    I often expand simple pin IO using I2C or SPI expansion chips. They're easy and plentiful.

    I don't think this is an extreme example at all, J.
    In fact, quite a reasonable approach.
    (I like knobs better than up/down buttons).

    Playing audio is pretty demanding work.
    Even a dozen MS gap will be obvious. More would be down right unacceptable.

    I also thought your I/O mapping was right on - and it leaves a few extra pins available there (high numbers)
    to deal with a few extra toys.

    Sixteen general purpose I/O pins, with all the necessary stuff already installed on this board -
    looks like a real winner.
  • David BetzDavid Betz Posts: 14,511
    edited 2012-04-26 06:07
    cavelamb wrote: »
    I don't think this is an extreme example at all, J.
    In fact, quite a reasonable approach.
    (I like knobs better than up/down buttons).

    Playing audio is pretty demanding work.
    Even a dozen MS gap will be obvious. More would be down right unacceptable.

    I also thought your I/O mapping was right on - and it leaves a few extra pins available there (high numbers)
    to deal with a few extra toys.

    Sixteen general purpose I/O pins, with all the necessary stuff already installed on this board -
    looks like a real winner.
    Remember, we were talking about the SPI bus used to access an on-board SPI flash chip not a general purpose SPI bus. Even if Martin connects the SPI flash chip to the same SPI pins as the SD card uses, you'd still be free to use P25-27, as JonnyMac suggests, for a SPI bus to address off-board peripherals. The only devices that might interfere with each other using the shared SD/flash approach are the SD card and the SPI flash and those are easy to handle in PropGCC and probably also other applications that want to use both devices.
  • JonnyMacJonnyMac Posts: 8,912
    edited 2012-04-26 07:59
    In my projects I have more use for external SPI devices than an internal SPI RAM -- but that's just me. As this is a general purpose board I would suggest it not get too loaded down with features/devices that won't get day-to-day use. The C3 was a bit of a flop, I think, because it tried to do everything for everyone and didn't do any of it particularly well.
Sign In or Register to comment.