OtherCrashOverride wrote:There is also the concept of 'barrier to entry' which is very high for the RPi. If its too complicated at the start, it may dissuade further use.
I agree this may be where the RPF could do some improvements, there are a few things I have in mind which could improve things.
* fixing the audio quality from the audio jack.
- Prevents the need for adding a USB sound device and the ALSA/PulseAudio confusion that accompanies it
Unfortunately the quality of the PWM outputs, when talking about bits per sample, is fixed. The PI has very good audio when using HDMI, the audio jack is simply a backup solution. That said the signal could use some buffering, and perhaps more filtering. For better than 12-bit analog audio there is a solution already in place, but it seems to be suffering from unfamiliarity. I'm talking about the fact that the PI actually has a high quality digital audio interface (I2S) all it needs is the digital to analog translation chip (codec) and some connectors. The codec it6self was an option that was removed to get the price down to the current level, but the I2S interface was re-instated with the revision 2 PI.
* fixing the issue that inserting a USB device causes the system to reboot
- Prevents SD card corruption and end user surprise as USB is expected to be hot pluggable
This can be easily done by inserting a few resistors of a fraction of an ohm, plus a single large capacitor near the USB ports. In fact we more or less had it with the revision 1 boards, in the form of the USB polyfuses that acted as these resistors. Unfortunately it's a balancing act as too large resistors will bring back the same issue (voltage drops) that the polyfuses were removed for in the first place, and too small resistors may not help in all cases, if the power hungry and badly designed USB device can draw a rush-in current that the resistor cannot limit to the safe value that the capacitor can deliver, then a power-crash can still happen. The reason that you don't see this problem much with PC's is that they have far much stronger (50 Amps or more) power supplies that have no problem to rush an ampere or more to the USB port momentarily.
Still I think that, for example, two tiny 0.1 Ohm resistor and a 470uF elco could help reduce the problem so that most simple devices like keyboards, and memory sticks wont cause a reset. I expect this to happen, but be assured the RPF is very concerned about a return of the previous polyfuse troubles, so they will be careful with reinstating any resistance.
* replacing the SD card slot with something of higher quality
- Prevents breaking your PI from the 'normal' wear and tear of an *educational* product where SD cards are swapped often
I don't think the current card holder is as dramatically bad as you imply here, but as with anything better quality comes with a higher price. Currently the holders I have seen seems to be fine, as long as you don't drop the PI on a hard surface with a card in the holder, and the card in the holder captures the impact, thereby breaking the card holder. For normal wear and tear the holders I have seen seem adequate. Its possible that between different releases of the PI, and/or different manufacturers the quality may have differed.
* providing a bare minimum, entry level, clear plastic case
- Prevents static damage from handling the device and prevents shorting it out from placing it on something conductive. Both of which may be a surprise to the uninitiated.
Static isn't as big an issue as people think, and a case doesn't necessarily prevents ESD mishaps, its possible to discharge into an exposed connector just as well. Even a minimal hard plastic case would cost several dollars. But I heard the educational release will come with a very simple case (perhaps also because maybe the PI that comes with it will have a slightly different form factor, and won't fit in existing cases, but that is my own speculation). As for shorting on the underside, a much cheaper solution (pennies) would be four rubber stick-on feet, that would already be sufficient.
* adding a single, momentary contact switch that informs the GPU to boot recovery at startup and is user defined after boot
Actually that feature already exists, there is one GPIO pin that is programmed as an input, and has its own pullup resistor. Its the RxD pin. Opposite it there is a GND pin, by placing a jumper between the RxD and the GND pin you pull it down, and the boot software recognizes this as a special condition, and starts up in a special "safe mode" specifically equipped to act as a recovery console.
- Allows a shutdown button to be implemented to prevent SD card corruption and a simple way for the user to get back to factory defaults when something goes wrong.
I don't see the use, what would be useful instead is support for safe power down, a pin that controls the "off function" of a "smart power supply", that goes "active" just after completing shutdown, but otherwise is inactive from the start.
Currently NOOBS has to initialize the USB hub and enumerate devices before it can tell if the 'recovery key' is pressed.
See my previous comment on recovery mode entry, but without a keyboard to control recovery functions entering a recovery mode is also a bit pointless
* 4GB flash on-board with NOOBS factory installed
- Turn it on and it works! Mess it up and you can restore without requiring access to a PC with a SD card slot and installing imaging software.
Actually this idea has a bit of merit, but I would rather use a more tiny amount (few hundred Kilobyte) that can be placed in a cheap serial EEPROM, (one that uses the same SPI interface as the SD-card boots with), perhaps its therefore possible to use the GPU's boot code to boot from that EEPROM. It could contain the equivalent of a BIOS, which could assist in alternative boot methods, and could initiate a text console that tells the user what happens during initial boot loading, so he isn't "blind" as he is now when the card won't boot. Perhaps its possible with something more substance than a single ACK LED what is wrong when booting fails. That would assure people that their PI is "alive".
- Allows the use of more robust development tools and environments on a full featured PC rather than the complications and limitations of developing on the device itself. If you make it easier to program, maybe more people will.
That's wholly against the spirit of the PI. The PI is designed as a replacement
for the existing PC, so that a kid can work with it without fear of corrupting a PC.
Robust development tools can already run on the PI itself.