Shop Learn
New Propeller Platform USB design - Page 2 — Parallax Forums

New Propeller Platform USB design

2456

Comments

  • David BetzDavid Betz Posts: 14,366
    edited 2012-04-26 08:03
    JonnyMac wrote: »
    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.
    I agree that a general purpose board shouldn't have a lot of extra devices that may not be of use in all applications. My reason for suggesting a SPI flash chip is that it makes the general purpose board better at running large C or C++ programs without having to add additional hardware. It seems to me that improving the support for a generic programming language like C is appropriate if you think the board will be used often for C/C++ development. On the other hand, VGA, ADC, PS2, TV, and audio may not be necessary or even desired on a general purpose board.
  • JonnyMacJonnyMac Posts: 7,618
    edited 2012-04-26 09:32
    It's a fair point. Perhaps the general purpose SPI is moved to P20..P23 (one CS) and the P24..P27 pins are used for internal SPI RAM. Being the clever guy that he is, Martin could, perhaps, allow selective enabling of these lines.

    Do you have an example part for the SPI RAM? While I'm not interested so much in C, I do have a project coming that could benefit from extra RAM space if it's fast enough.
  • David BetzDavid Betz Posts: 14,366
    edited 2012-04-26 10:54
    JonnyMac wrote: »
    It's a fair point. Perhaps the general purpose SPI is moved to P20..P23 (one CS) and the P24..P27 pins are used for internal SPI RAM. Being the clever guy that he is, Martin could, perhaps, allow selective enabling of these lines.

    Do you have an example part for the SPI RAM? While I'm not interested so much in C, I do have a project coming that could benefit from extra RAM space if it's fast enough.
    I've been playing with SPI flash not SRAM although the C3 uses some 32k SPI SRAM chips. I believe they are Microchip 23K256 chips.
  • jazzedjazzed Posts: 11,803
    edited 2012-04-26 11:15
    @jmg offered an interesting summary here:

    http://forums.parallax.com/showthread.php?131954-My-attempt-at-23K256-SRAM-drivers.-Includes-8-bit-version.&p=1090646&viewfull=1#post1090646

    IPSiLog's parts are 64KB SPI-SRAM and are competively priced.
  • Nick McClickNick McClick Posts: 1,003
    edited 2012-04-26 11:28
    JonnyMac wrote: »
    ...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.

    My two cents, but I think the PP Kit is the perfect implementation of the 'Universal board'. The PPUSB violates that principle a bit with a microSD card slot, but it's really just a 10k pullup on P0..P3 when you're not using the slot. And you can always connect a slot elsewhere, like we did with the SDRAM module. There are so many demonstration projects that require SD, and it's an inexpensive addon, I'm happy we put it on the PPUSB.

    @Martin - The most requested features on the PPUSB were power over USB and an RTC. I can't think of any requests for SPI RAM. We did do a 32MB SDRAM Propeller Platform module, but it was a low volume item. If you can keep the price reasonable on your version, I think you'll have a winner.
  • David BetzDavid Betz Posts: 14,366
    edited 2012-04-26 11:34
    My two cents, but I think the PP Kit is the perfect implementation of the 'Universal board'. The PPUSB violates that principle a bit with a microSD card slot, but it's really just a 10k pullup on P0..P3 when you're not using the slot. And you can always connect a slot elsewhere, like we did with the SDRAM module. There are so many demonstration projects that require SD, and it's an inexpensive addon, I'm happy we put it on the PPUSB.

    @Martin - The most requested features on the PPUSB were power over USB and an RTC. I can't think of any requests for SPI RAM. We did do a 32MB SDRAM Propeller Platform module, but it was a low volume item. If you can keep the price reasonable on your version, I think you'll have a winner.
    Just to be clear, I wasn't asking for SPI SRAM. I was asking for SPI flash. This essentially puts the PP-USB into the same class as other microcontrollers with a fairly large amount of space for code. This is very useful if you want to program it in C. It shouldn't be necessary to plug in an add-on board just to run reasonable size C code.
  • Don MDon M Posts: 1,635
    edited 2012-04-26 11:36
    David- what SPI flash device are you suggesting?
  • David BetzDavid Betz Posts: 14,366
    edited 2012-04-26 11:39
    Don M wrote: »
    David- what SPI flash device are you suggesting?
    The Atmel AT26DF081A or maybe the SST 25VF080B. Those are both single bit SPI chips. The quad bit chips are faster but use more pins and I figured that pins are usually at a premium on a general purpose board.
  • jazzedjazzed Posts: 11,803
    edited 2012-04-26 11:59
    Single bit SPI Flash takes few pins, cost about $1 each (qty 10+), does not require a new FAB add-on to make it work, will out-perform SDcard for large memory programs, and can easily be made optional.

    The generic alternative is to make an SD card plugin FAB with some SPI device on it, but then you can't use the SD slot for it's intended purpose. I've considered this possibility many times and may just do that. Win-win situation.

    Another alternative is having a 6 pin header for an extra SPI chip module with just a different CS pin should be a fair compromise instead of adding another SPI chip to the board assuming the traces can be routed nicely.

    An on-board SPI chip foot print is much more attractive than the header though.
  • cavelambcavelamb Posts: 687
    edited 2012-04-26 19:29
    What's tied to the hole just above RES?
    GND is right next door, fine and handy.
    But what's on the pin just above RES?
    A duplicate of RES? Or maybe GND?
  • TubularTubular Posts: 4,355
    edited 2012-04-26 20:01
    David Betz wrote: »
    The Atmel AT26DF081A or maybe the SST 25VF080B. Those are both single bit SPI chips. The quad bit chips are faster but use more pins and I figured that pins are usually at a premium on a general purpose board.

    If anyone wants DIP versions of the SST25VF080, get in contact with me. They are hard to find - but are available directly from Microchip direct. I sent a few over to GG as well...
  • TubularTubular Posts: 4,355
    edited 2012-04-26 20:07
    JonnyMac wrote: »
    ... 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

    Jon
    Any particular reason for the order of pin functions P27...P25? Do you have hardware already that uses this order? Could SPI CLK be on P27?
  • JonnyMacJonnyMac Posts: 7,618
    edited 2012-04-26 20:19
    In fact, I do, but if that group was the SPI buss I'd be happy.
  • David BetzDavid Betz Posts: 14,366
    edited 2012-04-26 20:32
    I'm afraid I don't understand the goals of this proposed SPI bus. When I first suggested that a SPI flash chip be added and that it share MOSI/MISO/SCK with the SD card, I didn't anticipate that the same pins would also be used to connect other external SPI devices. After all, any three pins can be used for a SPI bus. There is nothing special about the ones that are currently slotted for the SD card. I still maintain that the SPI flash can share those lines and that if someone wants to stream data off of an SD card and send it to a SPI DAC, the DAC can use different pins for its SPI interface.

    So my proposal is this:

    P0..P15 are completely free of any onboard hardware
    P16..P19 are used for the uSD and on-board flash
    P27 is free but could be used for SPI MISO
    P26 is free but could be used for SPI MOSI
    P25 is free bug could be used for SPI CLK
    P24 would be the CS for an onboard SPI device
    P23..P20 would be free

    However, it might be better to put the flash CS on 20 so it is adjacent to the uSD SPI pins and CS and leave P21..P24 free.

    Would that work?
  • TubularTubular Posts: 4,355
    edited 2012-04-26 21:17
    David Betz wrote: »
    I'm afraid I don't understand the goals of this proposed SPI bus. When I first suggested that a SPI flash chip be added and that it share MOSI/MISO/SCK with the SD card, I didn't anticipate that the same pins would also be used to connect other external SPI devices. After all, any three pins can be used for a SPI bus. There is nothing special about the ones that are currently slotted for the SD card. I still maintain that the SPI flash can share those lines and that if someone wants to stream data off of an SD card and send it to a SPI DAC, the DAC can use different pins for its SPI interface.

    So my proposal is this:

    P0..P15 are completely free of any onboard hardware
    P16..P19 are used for the uSD and on-board flash
    P27 is free but could be used for SPI MISO
    P26 is free but could be used for SPI MOSI
    P25 is free bug could be used for SPI CLK
    P24 would be the CS for an onboard SPI device
    P23..P20 would be free

    However, it might be better to put the flash CS on 20 so it is adjacent to the uSD SPI pins and CS and leave P21..P24 free.

    Would that work?

    A lot of applications have a data flow from input device (ADC, Line Scan Sensor, Accelerometer etc) to logging output device (SD card, DAC, Flash memory etc). Its just much easier to code if you can have each cog handle separate pins for its respective SPI device. Its theoretically possible to interleave SPI access, but no fun if you *do* happen to have a few spare pins available for a second SPI.

    I think P20..23 free is marginally better because at least we can put TV output there (it has to be a boundary of 4 pins, P21..24 wouldn't work).

    Since we're examining pin usage, VGA output isn't well looked after by the current proposal, as it has to start on a boundary of 8 pins. Currently it would have to be on P0..7 or P8..15. An argument can therefore be made for
    P16..19 = TV or monochrome VGA (4 bits)
    P20..23 = First SPI device, or color VGA (upper 4 bits of)
    P24..27 = Second SPI device, or Kb & Mouse as per demo board

    This allows for a complete "KVM" console, while still leaving P0..15 free for expansion boards.
  • David BetzDavid Betz Posts: 14,366
    edited 2012-04-27 04:47
    Tubular wrote: »
    A lot of applications have a data flow from input device (ADC, Line Scan Sensor, Accelerometer etc) to logging output device (SD card, DAC, Flash memory etc). Its just much easier to code if you can have each cog handle separate pins for its respective SPI device. Its theoretically possible to interleave SPI access, but no fun if you *do* happen to have a few spare pins available for a second SPI.

    I think P20..23 free is marginally better because at least we can put TV output there (it has to be a boundary of 4 pins, P21..24 wouldn't work).

    Since we're examining pin usage, VGA output isn't well looked after by the current proposal, as it has to start on a boundary of 8 pins. Currently it would have to be on P0..7 or P8..15. An argument can therefore be made for
    P16..19 = TV or monochrome VGA (4 bits)
    P20..23 = First SPI device, or color VGA (upper 4 bits of)
    P24..27 = Second SPI device, or Kb & Mouse as per demo board

    This allows for a complete "KVM" console, while still leaving P0..15 free for expansion boards.
    Okay, if you think it's better to put the SPI flash on different pins than the SD card I certainly won't object. By the way, I verified with RossH that Catalina will be fine with either approach. It can handle shared pins and certainly will have no trouble with dedicated pins.
  • Martin HodgeMartin Hodge Posts: 1,246
    edited 2012-04-27 08:26
    But is it really necessary to have separate pins for two different storage devices? Remember, we're talking specifically about one SPI flash device to make C/C++ programming easier. It seems to me you would want to get the SPI flash on the same pins as the SD card in order to make room for your SPI ADC's and accelerometers on different pins. Think about the specific applications, are there really that many instances where you need to have two cogs streaming data from the uSD card to the Flash chip, or vice versa? Because that is what this boils down to. I would seem to me to be a much more versatile setup to get all your SPI memories on one set of pins and then let the user worry about where to plug in their SPI peripherals.

    Unless I'm missing something big, it seems the way to go is with shared pins for the memories.
  • wjsteelewjsteele Posts: 697
    edited 2012-04-27 09:16
    Shared IO or non shared pins could be done both ways with cuttable traces and jumper pads.

    Bill
  • jazzedjazzed Posts: 11,803
    edited 2012-04-27 09:38
    But is it really necessary to have separate pins for two different storage devices? Remember, we're talking specifically about one SPI flash device to make C/C++ programming easier. It seems to me you would want to get the SPI flash on the same pins as the SD card in order to make room for your SPI ADC's and accelerometers on different pins. Think about the specific applications, are there really that many instances where you need to have two cogs streaming data from the uSD card to the Flash chip, or vice versa? Because that is what this boils down to. I would seem to me to be a much more versatile setup to get all your SPI memories on one set of pins and then let the user worry about where to plug in their SPI peripherals.

    Unless I'm missing something big, it seems the way to go is with shared pins for the memories.

    IMHO you understand it pretty well. Other peripherals can live on the "shields".

    Are you having any luck with USB power? I followed the data sheet recommendation mostly except for the VCCIO stuff which is supplied by a separate regulator having USB5V input. It has worked out very nicely so far. I would have added an optional pull up on P30, but I didn't have room. I don't use Phil's circuit.
    1024 x 577 - 40K
  • Don MDon M Posts: 1,635
    edited 2012-04-29 19:18
    Martin- any decision on your design yet? I'd be interested in a few.

    Don
  • Martin HodgeMartin Hodge Posts: 1,246
    edited 2012-04-30 14:30
    I'm still working on it. The flash chip will share SPI pins with SD socket except for CS which will be settable to 3 or 4 different pins. Currently I'm "dead bugging" a few different alternatives to FT232-to-Propeller interfacing. So far I've tried Phil's circuit, which works very well with the right pull-ups. One of my own ideas, which works even better but is more expensive. And today I'm trying out the circuit in the FT232 datasheet that Jazzed mentioned.
  • RaymanRayman Posts: 12,027
    edited 2012-04-30 17:37
    Just noticed something about sharing SPI pins with SD...

    Unfortunately, I don't thing the drivers we have reliably turn off the MISO pin... So, there's a high chance of pin contention...
  • jazzedjazzed Posts: 11,803
    edited 2012-04-30 18:45
    Rayman wrote: »
    Just noticed something about sharing SPI pins with SD...

    Unfortunately, I don't thing the drivers we have reliably turn off the MISO pin... So, there's a high chance of pin contention...

    For C3 we have to go through a dance to make sure it's in the right mode.

    Fair observation, although it sounds like a driver omission or a lazy programmer.
    Given the high likely-hood that one is true, perhaps it's better to use separate MISO pins?
  • Don MDon M Posts: 1,635
    edited 2012-04-30 19:19
    I liked JonnyMacs earlier suggestion of using separate pins for SPI / SD card. That gets my vote.
  • Martin HodgeMartin Hodge Posts: 1,246
    edited 2012-04-30 21:56
    Time for some ASCII art...

    Below is what I have now.
    p0 ----+
    p1     |
    p2     |
    p3     |
    p4     |
    p5     |
    p6     |
    p7     |---- 16 completely free pins
    p8     |     of Propeller awesomeness
    p9     |
    p10    |
    p11    |
    p12    |
    p13    |
    p14    |
    p15 ---+
    p16 ---+
    p17    |---- uSD card slot AND Flash memory.
    p18    |     (But where to put Flash CS line?)
    p19 ---+
    p20 ---+
    p21    |
    p22    |     
    p23    |---- Even more free pinage! Put an off-board SPI device here if you want.
    p24    |
    p25    |
    p26 ---+
    p27 ---+
    p28    |
    p29    |---- Our standard I2C EEPROM and serial tomfoolery.
    p30    |
    p31 ---+
    


    Below is how the PP USB used to be set up and can still be used this way, for backward compatibility, by moving some solder blobs.

    p0 ----+
    p1     |---- uSD card slot AND Flash memory.
    p2     |     (But where to put Flash CS line?)
    p3 ----+
    p4 ----+
    p5     |
    p6     |
    p7     |
    p8     |
    p9     |
    p10    |
    p11    |
    p12    |     
    p13    |
    p14    |---- 23 completely free pins
    p15    |     of Propeller awesomeness
    p16    |
    p17    |
    p18    |
    p19    |
    p20    |
    p21    |
    p22    |     
    p23    |
    p24    |
    p25    |
    p26 ---+
    p27 ---+
    p28    |
    p29    |---- Our standard I2C EEPROM and serial tomfoolery.
    p30    |
    p31 ---+
    
  • jazzedjazzed Posts: 11,803
    edited 2012-04-30 22:44
    Martin, Do you have room for a DIP-8 where you can connect P20..25, GND, and VDD?

    If so people can just add one of these ....

    1MB QuadSPI Flash: http://search.digikey.com/us/en/products/W25Q80BVDAIG/W25Q80BVDAIG-ND/2208452
    2 channel ADC: http://search.digikey.com/us/en/products/MCP3202-CI%2FP/MCP3202-CI%2FP-ND/305924
    Differential ADC: http://search.digikey.com/us/en/products/MCP3301-CI%2FP/MCP3301-CI%2FP-ND/440171
    High res DAC: http://search.digikey.com/us/en/products/MCP4821-E%2FP/MCP4821-E%2FP-ND/951462
    128KB I2C EE: http://search.digikey.com/us/en/products/AT24C1024B-PU/AT24C1024B-PU-ND/1886125
    Tiny DIP8 AVR: http://search.digikey.com/us/en/products/ATTINY85-20PU/ATTINY85-20PU-ND/735469

    That is, dozens of possibilities in a PDIP8 with some imagination, not much grief, etc....
  • cavelambcavelamb Posts: 687
    edited 2012-04-30 22:54
    Flash on 20-23 and all sins forgiven...
    Copy form on to the other with no problem.
    It's GOING to be an issue, you know that. Right?
  • David BetzDavid Betz Posts: 14,366
    edited 2012-05-01 04:20
    jazzed wrote: »
    The reason I suggested adding a 1mb SPI flash chip is so that this new board could run large C programs (Catalina or PropGCC) out of the box without having to add any extra hardware. It wasn't intended to be a general purpose SPI bus which is why I thought sharing pins with the SD card wouldn't be a problem and would allow more pins for other hardware to be connected like the ones listed above. If you just provide a DIP8 footprint the board won't be able to run these larger programs without having that footprint populated. Also, the QuadSPI chips take up even more pins than the single SPI chips. Maybe it would be best to just forget the SPI flash entirely.
  • David BetzDavid Betz Posts: 14,366
    edited 2012-05-01 04:31
    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:)

    Attachment not found.

    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.)
    If people don't mind giving up the extra pins I guess separate ones are probably best. My goal was to get a SPI flash on the board taking up the fewest additional resources. It seems no one is worried about the extra pins so that is probably the best way to go.
  • Don MDon M Posts: 1,635
    edited 2012-05-01 05:41
    Is the Seiko RTC still included? My vote for a RTC if not.
Sign In or Register to comment.