[Arm-netbook] [eoma68] mini desktop pc

[joem]

On Wed, 2013-12-04 at 12:22 +0000, luke.leighton wrote:
> On Wed, Dec 4, 2013 at 9:14 AM, joem <joem at martindale-electric.co.uk> wrote:
> > On Tue, 2013-12-03 at 11:35 +0000, luke.leighton wrote:
> >> On Tue, Dec 3, 2013 at 10:00 AM, joem <joem at martindale-electric.co.uk> wrote:
> >>
> >> > 1. You need the internal 3.3V line brought out from EOMA68 to one of the
> >> > pins for general circuit design reasons.
> >>
> >>  not going to happen.  sorry. designs need to take that into account.
> >> apart from anything there will be boards in the future that don't
> >> *have* a 3.3V line (for whatever reason).
> >
> > Not a request.
> > The 3.3V line is the pull up line for GPIO lines.
> > Something to get right in next revision.
> 
>  joe: it's still not going to happen.  there are not enough pins.  I/O
> board designs will need to generate the correct 3.3v compatible TTL
> levels by having the correct regulators on the I/O board.  as 3.3v TTL
> levels are the same everywhere this is perfectly feasible.


Hmm... some misunderstanding going on here.
The "pull up line for GPIO" != any old power supply
line of same voltage.

It depends on circuit design.
If it were a TTL board, or something like a PIC running on 5V,
then the 5V line will have become the GPIO pull up line.
It just so happens that for the GPIO in the EOMA,
the pull up line for GPIO is specifically
the 3.3V line powering the GPIO.

(For ARM chips, the GPIO lines can usually be
 powered by a separate independent power supply to save power.
 So it can be set to 2.5V for example which will work
 so long as the circuits that it is interfacing to
 is designed to work with those levels.)


>  there is therefore not only enough pins available, but also this is a
> non-issue.

May be use up one more of the GND pins?

>  also there is the issue of backwards-compatibility if there are
> revisions.  any further revisions require complexity to be introduced
> into future revisions of both CPU Cards *and* I/O boards.  that is not
> going to happen.
> 
>  therefore please accept that i have carefully considered what you
> have said and the answer is no.
> 
> 
> >> > 2. Not sure about the USD75. Is it going to get cheaper any time soon?
> >>
> >>  in quantity 10k and above, probably yes.  because they will be
> >> designed differently.  and be a different product entirely.  so... no.
> >>
> >>  plus remember that $75 is for *two* boards, and tax, and shipping,
> >> and testing, and packaging, and profit (a small one) and everything
> >> else.
> >
> > Its $75 for CPU board and meb + shipping + taxes.
> 
>  yes.  QiMod Ltd is acting as the distributor, not the end-user
> supplier.  the choice of price for the pair of boards, being supplied
> by a 3rd party, is completely outside of QiMod Ltd's control.

I plan to buy a couple when they become generally available.
I got 50 x 5" 800x480 screens to play with at the moment :)
The price of these boards are coming down so fast its possible to build
desktop computing clusters. I worked out a proper 3D stackable case
design for that and ordered 6 x cubies a few days back. Easily modified
to fit the eoma which is better suited for cluster building because
a large part of the CPU board is not exposed to the elements.
So despite the slight premium compared to similar spec boards,
the main board not being exposed to the elements
will still make it a winner for cluster computing.


> >> > 3. At the moment there is no way to cooperate with everyone using
> >> >    closed sources PCB packages and the list of hardware mistakes
> >> >    are piling up as cost somewhere. This is driving a wedge through
> >> >    all things good and possible. I only want to work in open sourced
> >> >    KiCAD. The limitations are not significant
> >>
> >>  they are a complete show-stopper for someone with my limited
> >> available time, lack of knowledge and insufficient expertise.  simple
> >> as that.
> >
> > KiCAD web site has added a lot more video tutorials recently.
> 
>  the tutorials are not relevant, here.  joe: i've been working with
> KiCAD for around 4 to 5 years.  i am familiar with it.  compared to
> PADS it has completely inadequate functionality and design rule safety
> checks.
> 
>  regarding the speed at which designs can be created: that is
> completely irrelevant if i am creating completely wrong designs, isn't
> it?
> 
>  so until someone takes over designs who has the required knowledge
> and expertise, i have to stick with "safe" software packages.


Weelllllll! 

The stuff I get done takes hours to days and nearly everything I build
works first time. So lead by example I guess!!!!!!

When I get time, I break down Dr. Ajiths design
into pre-routed modules so it takes next to no time to glue together to
make into larger modules. Stuff that must be done in PADS can be
exported as Gerbers, KiCAD can import gerbers, so you could route the
DDR and CPU in PADs, export the gerber, pull Gerber into KiCAD and do
the non-critical stuff there by pulling in the various modules as
needed.

Any way its up to you. Speed up the work using well built and tried
and tested modules that everyone has shared, tried and tested, or go the
monolithic way. Less chance of donating help if doing monolithic designs
and going the PADs way or any other proprietary package. But so long as
it works, who cares? :)