New Propeller Platform USB design

Martin Hodge · 2012-04-23 00:02

Continuing from this thread...

It's alive and well!

It's 3am, more info after sleep.

--Update--

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

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

Rayman · 2012-04-23 03:52

Looks great! What's J1 for?

mindrobots · 2012-04-23 05:01

SWEEEEET!!!

Looks good, get some sleep!!

Martin_H · 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 Hodge · 2012-04-23 16:51

Updated info added to top post.

william chan · 2012-04-23 17:03

How many pieces will you be making?

Coley · 2012-04-24 05:31

Martin Hodge wrote: »

Continuing from this thread...

It's alive and well!

It's 3am, more info after sleep.

--Update--

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

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 Hodge · 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 Betz · 2012-04-24 07:22

Martin Hodge wrote: »

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.

GordonMcComb · 2012-04-24 12:13

Martin, What's the expected retail price point of this again?

-- Gordon

cavelamb · 2012-04-24 18:16

GordonMcComb wrote: »

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 Betz · 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.

cavelamb · 2012-04-25 04:54

Ah! Thanks, Dave.

T Chap · 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.

4x5n · 2012-04-25 06:41

Martin Hodge wrote: »

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?

Martin Hodge · 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 Betz · 2012-04-25 09:21

Martin Hodge wrote: »

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.

JonnyMac · 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 Betz · 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 Hodge · 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.

)

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.)

David Betz · 2012-04-25 14:08

Martin Hodge wrote: »

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. )

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.

pedward · 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.

JonnyMac · 2012-04-25 14:42

Martin Hodge wrote: »

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 Betz · 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.

JonnyMac · 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 chan · 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?

robbyd · 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

MJHanagan · 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?

cavelamb · 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 Betz · 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.

JonnyMac · 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.

New Propeller Platform USB design

Comments