RG1 1.8v regulator

Since we aren't getting much help from Pete in understanding how

the regulators work, is anyone able to attach a scope and measure

any oscillations?

On the scope I can see just a little bit of noise less than 20mV but no oscillations, I'm hitting the ethernet port with flood packets.

I'll put the ScopeMeter on a long term plot of 1V8.

About my comments on analysis, etc, the issue is that we have many variables moving at the same time that induce a large deviaton on any measurements, we are not following a common test procedure or similar instruments while testing different boards to be able to produce a reasonable bell curve.

So "it works for me" is valid report too, actually so far it has been working for me too in some aspects.

I'm still wating to see what else Pete has on his "list" ...

BTW I'm playing with the MK802 and the thing works out of the box with Android 4.0, no issues with the RF keyboard/touchpad, video and audio are great, yes I paid $72 for it but includes a power supply, HDMI cable, USB cable, USB adaptor, comes with a nice box and btw has a case !!, ohh and 1GB RAM, 4GB FLASH, the Cortex-A8 runs at 1GHz and the GPU at 500MHz. With all that now the R-pi feels more expensive ...

I've the little Gizmo attached to one of the corners of my monitor.

I'll try some time later to get Ubuntu running on it

-J

Cute, thanks for the pic.

Cortex-A8 seems a good foundation on which to base a multi-machine home ARM capability.  My BeagleBone and original-version 7" Samsung Galaxy Tab both use Cortex-A8, and so does the forthcoming Olimex A13-based board (all those A10 gadgets too).  Moreover, Cortex-M3 and M4 microcontrollers use the same ARMv7 instruction architecture, so in principle one could do development on a Cortex-A8 Linux machine to target a Cortex-M3/4 series microcontroller without needing cross-compilation.

More advanced application processors like Cortex-A9 MPcore and Cortex-A15 still retain the same basic ARMv7 instruction architecture as Cortex-A8, so there's a solid growth path into the future there too.  ARMv7 is effectively ARM's equivalent of the ubiquitous x86.

Morgaine.

Morgaine Dinova wrote:

 

He knows that his toast is buttered on the RPF side, and that being seen as a small hero here does not pay the rent.

I'm not sure the RPF is paying Pete much rent money either,

given that they have long claimed not to have any paid employees.

I think it's much more likely that he hasn't been doing much if any

RPi work lately because they aren't paying him much if anything. 

When Pete first responded to this issue, he didn't say the RPF

asked him to respond, or that he was responding on behalf of the

RPF, he said Mike Powell of element14 asked him to respond.

Of course, the RPF may have later asked him _not_ to respond further.

I suspect there is some checking going on regarding Pete's work

in designing the board, to see who is liable for fixing the problem.

If Pete did the work as an employee of RPF, then RPF would probably

be liable.  If Norcott was involved, then Norcott might be liable.

I notice that Pete appears to be deflecting some of the blame toward

Broadcom, in saying that the error was in the earlier prototype boards

and his work was extensively checked by the SoC experts.  I don't see

anybody stepping up and taking responsibility.

Morgaine Dinova wrote:

 

Cortex-A8 seems a good foundation on which to base a multi-machine home ARM capability.  My BeagleBone and original-version 7" Samsung Galaxy Tab both use Cortex-A8, and so does the forthcoming Olimex A13-based board (all those A10 gadgets too).  Moreover, Cortex-M3 and M4 microcontrollers use the same ARMv7 instruction architecture, so in principle one could do development on a Cortex-A8 Linux machine to target a Cortex-M3/4 series microcontroller without needing cross-compilation.

 

More advanced application processors like Cortex-A9 MPcore and Cortex-A15 still retain the same basic ARMv7 instruction architecture as Cortex-A8, so there's a solid growth path into the future there too.  ARMv7 is effectively ARM's equivalent of the ubiquitous x86.

 

Morgaine.

Cortex-A8 uses the ARMv7-A instruction set which includes both 32-bit ARM instructions plus 16/32bit Thumb/Thumb2  instructions.  Cortex-M3/4 use the ARMv7-M instruction set which only has Thumb/2 instructions.  So if you compile your programs and libraries using Thumb/2, you'll be able to run on both (unless you use integer divide -- Gotcha!)   But if you use ARM instructions, the binaries won't run on Cortex-M3/4.  Yes, it really is this complicated.  Take a look at the latest ARM ARMs (Architecture Reference Manuals).  Or better yet, download the quick reference cards.  They read like railroad time-tables with myriad footnotes.  OTOH, I am truly impressed that they're able to squeeze the intricacies of the ARM/Thumb/2 instruction sets into a few pages.

I guess ARMv7 is equivalent to the x86 in that both evolved from a simpler architecture into a dog's breakfast.  Both are a far cry from my personal favorite, PowerPC, which was a clean, well-designed architecture long before it was implmented as an IC.  OTOH, you can't get a PowerPC board that can run GNU/Linux for under US$120.

jamodio wrote:

 

BTW I'm playing with the MK802 and the thing works out of the box with Android 4.0, no issues with the RF keyboard/touchpad, video and audio are great, yes I paid $72 for it but includes a power supply, HDMI cable, USB cable, USB adaptor, comes with a nice box and btw has a case !!, ohh and 1GB RAM, 4GB FLASH, the Cortex-A8 runs at 1GHz and the GPU at 500MHz. With all that now the R-pi feels more expensive ...

 

I'll try some time later to get Ubuntu running on it

Thank you for the MK802 photo.  Cute little board, though it obviously has limited I/O.  Please let us know how Ubuntu (or any other GNU/Linux distro) goes.

I'm also going to watch the US$49 cubieboard (http://en.wikipedia.org/wiki/Cubieboard, http://cubieboard.org/).  If cubieboard becomes real and a good community develops, it (and other A10-based boards) could be effective competitors to RasPi.  Love those 2 mm headers!

jamodio wrote:

 

Since we aren't getting much help from Pete in understanding how

the regulators work, is anyone able to attach a scope and measure

any oscillations?

 

On the scope I can see just a little bit of noise less than 20mV but no oscillations, I'm hitting the ethernet port with flood packets.

I think it's really unlikely that you'd see oscillations.  My guess would be that only a handful of boards -- well fewer than 1% -- have RG1 Vref and IC3 Vref so close together that oscillation could occur.  I would guess that usually one or the other simply dominates.  OTOH, as the board heats up, dominance could shift from one regulator to the other, and you might see 1V8 oscillation at the crossover point.  But the dominance could just as easily diverge, and it could depend on NCP1117 manufacturer or lot.

I don't mind much about the limited I/O. On my projects list to try I've connecting it to a USB hub and to one of the IOIO boards from SparkFun that are already supported by Android and other Linux distros.

This is the IOIO board from SparkFun -> https://www.sparkfun.com/products/10748

-J

John Beetem wrote:

 

I think it's really unlikely that you'd see oscillations

Be sure to check all the way up in frequency.  The USB and ETH sections of LAN9512 are isolated with inductors specified at 100MHz, and I'm sure there's a reason for that.  HF parasitics could be very damaging even at very low amplitude.

I'm not sure the RPF is paying Pete much rent money either,

Yeah, my first thought on that was that Pete has a bill paying day job like the rest of us and is now doing this stuff in his spare time, effectively as a donation to the charity. We have no way of knowing what free time he may have or what he's willing to donate, so I'm not about to jugde him on that.

When he is here I for one will offer whatever assistance I can as he does seem to be open to the engineering issues.

The only other comment I'd make is that other than Eben, the other trustees don't seem to be much in evidence. There's been an occasional post by Jack Lang and a few more here by Pete, but I've seen nothing from say David Braeben or Robert Mullins other than some early interviews. So, IMHO, Petes input is welcome whenever he cares to join us.

I received  my Mk802 last week. The task I would like to use it for is to

log the performance data of my solar panels on the internet.

The Mk802 is to replace a cat5 cable, which runs from my garage, across

the back yard, over the dinning and living room floor to my desktop

Fedora system which currently does my logging. My requirements are to

use Wifi to replace the cable, run Linux, and accept an RS-485 dongle

to interface with my inverter. These requirements are better meet by

the Mk802, which has built in Wifi and 512MB or now 1GB ram, than the RPi.

My initial setup is with the Mk802 connected to my TV with the supplied HDMI

cable, the supplied power supply, an 8MB micro SD card, for the Fedora,

an unpowered hub with a keyboard and mouse, and the Wifi running.

So far I have not seen any problems with the USB devices. My Mk802

second generation case with cooling holes runs cooler than the power pack,

and I have not seen any Wifi problems which some people have reported.

My Mk802 is a 512 MB version running Fedora 17 and "top" shows some swapping

while running XFCE, two terminal emulators running, and a "yum update" in full

progress. Although the system is still fairly responsive.

Once I get the system setup, I plan to run it headless, with only the

RS-485 USB dongle and the power supply attached. With admin access via ssh

over the Wifi.