Opinions on P1 pin usage

Wuerfel_21

Hi,Im currently trying to design a propeller-based board-thing. I literally sat there for about 2 hours thinking about what to include, being mainly limited by the 32 I/o pins...
So i came up with this:
0..4 = GPIO5 = SD Card CLK6= SD Card MISO7 = SD Card MOSI8 = SD Card select + LED9 = SD Card detect10 = Audio right11 = Audio left12 = SRAM CLK13 = SRAM MISO/SIO014 = SRAM MOSI/SIO115 = SRAM select16..19 = Video DAC 120..23 = Video DAC 224 = Mouse data25 = Mouse clock26 = Keyboard data27 = Keyboard clock28 = I2C SCL29 = I2C SDA30 = Programming header TX31 = Programming header RX
(SD card isn't on the same bus as SRAM so they can be used at the same time. Also i heard that SD's do wired things until they're properly set up.)(SRAM will be Microchip 23LC1024-I/P)(Second video will be used for debugging or broadcast mode)
What do you think? Did i make a mistake?(Me? A mistake? unbelivable!)

Phil Pilgrim (PhiPi)

Except for video (and you got that right), all pins on the Prop are created equal. How could you possibly in error?
"Me? A mistake? unbelivable!" Well, you might check your spelling.

-Phil

Peter Jakacki

A dedicated SD card detect is redundant if you sense the SD card's internal pullup on the chip select line. Make sure you don't add a pullup here as there is never any need for it and it only messes up this card detect scheme as recommended in the SD card specifications.

Here's a tip too if you really want to use PS/2 keyboards and mice, all modern ones that are PS/2 compatible normally come with a bulky gender bender. Do yourself a favor and just use USB sockets on you board rather than hard to get PS/2 but run them as PS/2 protocol as the keyboard and mice themselves sense whether to use USB or PS/2 and the gender-bender is nothing but a dumb and awkward connector.

Another thing, I never understand the need for "stereo" sound as it is rarely ever needed as stereo. I always use mono to a stereo socket, saves another pin.

Also I have shared SD clock and data in with the I2C but you are correct in that there are some cards that do funny things, but the clock is normally fine to share anyway and I try to stick to Sandisk cards which never give me problems.

Wuerfel_21

Thanks!
About the SD card, how would the prop differentiate between pulled up and floating? On the AVR, pins connected to nothing read random values, i assume its the same on the propeller. Also, looking at the SD card driver reveals this crazy hookup:
(WTF, where is the codebox?)// Advanced SPI Circuit: (Uses 4 I/O Pins)////                                   3.3V//                                    |//                                    R 10KOHM//                                    |// Data Out Pin Number          

---

SD/SDHC/SDXC/MMC data out pin - pin 7 on the card.////                                   3.3V//                                    |//                                    R 10KOHM//                                    |//                                    

---

Write Protect Pin - Connected to ground when the card is writable.//                                    |                           Floats when the card is not writable.// Write Protect Pin Number     ---   R 10KOHM                    The card socket should provide this pin.//                                |   |// Clock Pin Number            

---

SD/SDHC/SDXC/MMC card clock pin - pin 5 on the card.////                                   3.3V//                                    |//                                    R 10KOHM//                                    |//                                    

---

Card Detect Pin - Connected to ground when the card is inserted.//                                    |                         Floats when the card is not inserted.// Card Detect Pin Number       ---   R 10KOHM                  The card socket should provide this pin.//                                |   |// Data In Pin Number          

---

SD/SDHC/SDXC/MMC data in pin - pin 2 on the card.////                                   3.3V//                                    |//                                    R 10KOHM//                                    |// Chip Select Pin Number      

---

SD/SDHC/SDXC/MMC chip select pin - pin 1 on the card.////                                   3.3V//                                    |//                                    R 10KOHM//                                    |//                                    

---

SD/SDHC/SDXC data 1 pin - pin 8 on the card.////                                   3.3V//                                    |//                                    R 10KOHM//                                    |//                                    

---

SD/SDHC/SDXC data 2 pin - pin 9 on the card.////                                   3.3V//                                    |//                                    

---

SD/SDHC/SDXC/MMC VDD pin - pin 4 on the card.////                                    

---

SD/SDHC/SDXC/MMC VSS1 pin - pin 3 on the card.//                                    |//                                   GND////                                    

---

SD/SDHC/SDXC/MMC VSS2 pin - pin 6 on the card.//                                    |//                                   GND(code end)
Would that work?

Peter Jakacki

To test for a floating input all you need to do is to drive it low for a few microseconds and then turn it back into an input, wait a few more microseconds, then test it. If it is pulled up it will read high by then or if not it will still be low.

Wuerfel_21

That sounds plausible...still, the circuit from the sd driver seems more reliable.
It would then be:
0..5 = GPIO6 = SD Card CLK/Write Protect7= SD Card MISO8 = SD Card MOSI/Card detect9 = SD Card select10 = Audio right11 = Audio left12 = SRAM CLK13 = SRAM MISO/SIO014 = SRAM MOSI/SIO115 = SRAM select16..19 = Video DAC 120..23 = Video DAC 224 = Mouse data25 = Mouse clock26 = Keyboard data27 = Keyboard clock28 = I2C SCL29 = I2C SDA30 = Programming header TX31 = Programming header RX

Peter Jakacki

Plausible? More reliable? How so? The specification released by the SD association specifies that and I use that method in commercial products. But what do we know compared to the "Arduino" people?

Wuerfel_21

Well, thats the circuit i pulled from http://obex.parallax.com/object/16 ...Looking at some propeller-with-sd boards schematics: i found out:C3 connects SD to crazy multiplexed SPI bus, without any pullups i can find. (Its driving CS from a couter + demultiplexer)El Jugador doesn't seem to care and just pulls up all of MISO/MOSI/CLK/CS.Board of education uses schematic from SD driver, minus the write protect as micro sd's dont have that.

prof_braino

Can I ask what your target is?  It looks like you want to make a terminal.
What would this "propeller-base board thing" be used for: programming the prop, or controlling another system, or games?

Knowing the final intention up front can help when starting the design.

Wuerfel_21

I would like to do cool stuff with the TV output, but who can say no to playing/making games?

Tracy Allen

"propeller-based board-thing"?

Don't forget pullups on the i2c lines.

I agree with Peter about using the chip select internal pullup for detecting card present. If you don't like the microsecond pulse idea, then connect the pin to ground with a 20M? resistor or even a reverse biased diode.  That is enough to keep the pin at ground (and testable) until a card is inserted. The pullups on the other pins are usually superfluous too.  Will your system normally have a card present? Forget about the complicated connections to the card detect and write protect switches. 

For audio, unless you use a special amplifier, there will be a click when the audio starts as it biases to half-voltage.   I don't like that and use a differential prop output to a BTL (bridge tied load) amplifier.   There are stereo preamps that have anti-click circuitry.

With regard to the code block, Phil came up with an html workaround, a template if you will:
http://forums.parallax.com/discussion/161593/forum-request-scrolling-codebox-please
Until such time as the forum regains the BBcodes.

Wuerfel_21

Yes, the system will usually have a card inside, with a bootloader on the eeprom listing program files and booting them.Also i don't care about a little click, as my tv goes PFLUNNG when i turn it on anyways. Although i dont see where the click comes from in a circuit like this (pulled from parallax ftp(pulled from C3 schematic, audio_mono goes to I/O pin):

Cluso99

All prop I/o pins have a natural bias to read low. So it's not really necessary to drive the pin low and release then read.
Many prop circuits don't have a pull-up on SCL. I recommend pull-ups on both SDA and SCL.
I have been placing a 10K pull-up on SD-CS before Peter pointed out the spec. However, I often share this pin which requires a pull-up anyway.
I have also been putting a 10K pull-up on reset and including an option for the transistor circuit. This allows cheap usb-serial dongles to be used.

Mark_T

Plausible? More reliable? How so? The specification released by the SD association specifies that and I use that method in commercial products. But what do we know compared to the "Arduino" people?




In my experience the capacitive coupling between neighbouring pins is enough for a floating
pin to pick up the waveform of neighbouring driven pins quite easily.