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.
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.
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.
...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.
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.
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.
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.
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?
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...
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?
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.
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.
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.
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.
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.
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.
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?
That is, dozens of possibilities in a PDIP8 with some imagination, not much grief, etc....
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, 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.)
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.
Comments
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.
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.
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.
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.
GND is right next door, fine and handy.
But what's on the pin just above RES?
A duplicate of RES? Or maybe GND?
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...
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?
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.
Unless I'm missing something big, it seems the way to go is with shared pins for the memories.
Bill
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.
Don
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?
Below is what I have now.
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.
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....
Copy form on to the other with no problem.
It's GOING to be an issue, you know that. Right?