Sorry I missed the above replies until now.gregd99 said:
Wouldn't you just use a Linux terminal window as a place to write debug output?
Of course, but I don't always intend to have a screen connected to it, so a simple text output is very useful. Also, the debug in this case would need to be different to the verbose debug you use in non-embedded programming. For my purposes it is a handy tool.ridge said:
Keeping in mind the intended end users and goals of the Raspi, and how the Broadcom ARM device is a lot more complicated than the simple devices many of us first learned on, I have a few thoughts…
The Raspi is a full up computer with an OS. A bit overwhelming to use as an introduction to microprocessor hardware architecture.
The Gertboard approach of an external 8-bit micro controller (PIC, AVR) as an introductory hardware reference system is best in my opinion. Learning clock timing, predefined pin functions, current source and sink limitations, and lots of other basics on a simple architecture is a needed accessory for the Raspi.
A socketed (sub 1$ cost) 8-bit micro as a target system, with the Raspi as the host development system will keep it simple for beginners.
Something like the WinAVR GCC toolchain running on the Raspi, talking to a simple 8-bit micro that can be breadboard mounted.
I love the Gertboard approach and I really hope to get one, and if I can build my skills up, produce guides for that too. However...in some ways that could also be rather overwhelming too (lots of extra electronics etc). Of course, there is room for both approaches (boards like the Gertboard will be excellent for learning with).
However, adding a few components to the GPIO pins I would say is a small baby step. Adding additional boards etc is a bigger step, but yes very important and far easier for learning the whole picture. The oddities, such as controlling the GPIO through linux can easily be smoothed by libraries and access functions so that it resembles any other basic method (see Gerts example code), a lot can be done with very little (when the device is $25, a lot of people will limit what they plan to spend on extras).
People shouldn't be scared to try connecting simple stuff to the RPi GPIO, obviously we just have to be careful to protect it and advise people suitably. This is why I'm doing it, since I'm not 100% sure about all of it so I'm building up the information (open for comment/corrections etc) so that we can recommend the best possible solutions.
I am currently looking at the details for the switch input, one thing I am not sure about is the resistor connected on the GPIO input (a lot of circuits omit this).
I'm guessing that in this configuration, it probably isn't needed (since connection is either direct to ground or through the top resistor). If round the other way, i.e active high -switch on top, it would be preferable for protection. Or is it helpful to protect if the GPIO pin is set as an output instead??? What criteria should the value of this resistor be determined by?
I currently have the top resistor as around 10K, which should keep the current low anyway. The capacitor, 470nF will probably suit, if for some reason software de-bouncing isn't used.