Raspberry Pi - Hardware Flaws and Fixups?

mmm, I really hope those "power issues" turn out to be just bad cable/adaptors/ppl doing it wrong.

You guys are working on it I suppose.

btw PeteL, what is requiring redesign (for full compliance)? That's what is bugging me, since it leads to another question: when will this be implemented (and then re-certified)? Before or after the queue of orders?

I guess "what are the changes needed" is more your cup of coffee (or better tea), so that's what I'd really like you to enlight me on.

Btw, is it just me or those 2k units feel a lot like a pre-serie?

"those 2K" should be "those 10k". The other 8k are Guaranteed to be exactly the same: they were produced feb-march just like the first 2k that are delivered right now.

and yes, I too would want to know what changes seem to be neccessary and when they will go through.

What is the HD interface? (schematics P4 left top)

What value is typical for the built-in pullup/pulldown? I expect that to be on the order of 50-100k. In that case you can encode 3^4 different board revisions with the 4 board-revision strap resistors:

read value. If zero, enable pullup, if one enable pulldown. If value now changes, the strap is left "open", so that's the third value.  (Ah! found them!).

There is an error in the schematics. p3 mentions the "USB" part of the LAN9512 as "model A only". That should be "Model B only" of course.

R22-R25, R28, C28 are missing their "Model B only" tag.

Why is there a line going from R25 to R22?

Due to space constraints the 100M led is labeled 10M on the board. How about calling that "FE" for "Fast Ethernet"? That's what 100M was called back in the days.

On the other hand, I would much rather have a BCM2835 GPIO pin control a led in that position. If we want, we can program it for the 100M/FE function in software, but it provides those who are going "bare bones" with an extra debugging option.

Similarly, the FDX led is nowadays a bit outdated. Why on earth are we still interested in that statusbit? Any reasonably recent setup will run full duplex, and it won't help in debugging in seeing that led remain off. Again: A gpio LED would be a nice replacement. The easiest way to notice a halff duplex link is to watch "dmesg": smsc95xx 1-1.1:1.0: eth0: link up, 100Mbps, full-duplex, lpa 0xC5E1

What is the purpose of D15, D16? I'm thinking: Protection against static discharges, right? The question is: Wouldn't it be better to connect their kathode to +5V0 instead of +5V0_HDMI? The +5V_HDMI is just a small net that only has the 100N C75 on it....

Are the HDMI_SDA and HDMI_SCL pins 5V tolerant? I wouldn't have guessed.

Just in case you missed it, I did - tied up in a meeting, Liz has posted the schematics on the main site.

I'll let everyone have their comments and inputs and review/respond in detail where I can in few days.

I will also start a new discussion here, PLEASE put all comments on the schema's there, and the folks who have already please cross post, it keeps it all nicely together and will be useful for people to read.

Cheers

Pete

Pete, I was just checking my 5V power, and found that with the Raspberry powered off, there was still about 1.3V on the 5V0 line. Removing cables one by one indicated this was coming from HDMI.

Turns out 5V0_HDMI is 2.7V. and the HDMI_SCL and HDMI_SDA are 3.something.

So apparently my IIYAMA monitor is partially powering the RASPI through the I2C datalines....

Why not use a BAV99S (from NXP) for D15 AND D16 (i.e. use the 6 pin, 4 diode version).

Same goes for D12, D13. And possibly D4 and D14. (but those are annoyingly far apart I guess).

On the other hand, I would much rather have a BCM2835 GPIO pin control a led in that position. If we want, we can program it for the 100M/FE function in software, but it provides those who are going "bare bones" with an extra debugging option.

 

Similarly, the FDX led is nowadays a bit outdated. Why on earth are we still interested in that statusbit? Any reasonably recent setup will run full duplex, and it won't help in debugging in seeing that led remain off. Again: A gpio LED would be a nice replacement. The easiest way to notice a halff duplex link is to watch "dmesg": smsc95xx 1-1.1:1.0: eth0: link up, 100Mbps,full-duplex, lpa 0xC5E1

I agree with that, FDX led is not really usefull, it would be much better if that could be used as a gpio led.

That way you can directly let kids program the led without the need for extra hardware.

Hans

Well, in principle you can use the FDX as a GPIO LED.  The difficulty is that you need to talk to the LAN9512 in USB-speak to configure and toggle it, and the driver may make this difficult.  Still, students would learn a lot about USB drivers trying to do it :-)

Was it here that someone asked me to measure the physical size of the 'pi? Mine is 55.9 x 84.9mm.

Yes me...  thx Roger.

Hans

I know it is only slightly different, and may not matter at all, but in a post on the Raspberrypi.org website one recipient (another case manufacturer actually) has said that: The board is 85.00 x 56.17

Pete. Very excited, I've been looking for the Raspberry Pi for the last two years to make an affordable audio player to generate sound effects and audio interpretation for museum exhibits. The aim would be to trigger the audio with a PIR via the GPIO. There would be no display so I need to use the 2.5mm audio jack. In this thread http://www.raspberrypi.org/forum/features-and-requests/possible-higher-bitrate-dac-in-the-future item  6 GERT mentions that there will be power supply noise on the audio. I don't have a Pi yet so don't know what this sounds like but for amplified sound effects background noise is important. I wonder if the situation can be improved in the next revision, or maybe the pwm lines brought out to the GPIO connector so users can implement their own clean power supply, driver and filter as described in the same thread. The GPIO solution would give 2 additional pwm outputs, assuming they can be decoupled from the audio software.

Regards

Ken Thompson