Hi,
Are the schematic and PCB layout CAD files for the EOMA68 computer card and the various housings available for download? I'm wondering if I can fabricate some of the housings on my own using a CNC mill. Hence, my interest in them.
Sorry I had to ask. I searched very hard through the crowdsupply page and the rhombus-tech site, but couldn't find them.
Thanks, Arun.
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Sun, May 12, 2019 at 12:26 AM Arun Isaac arunisaac@systemreboot.net wrote:
Hi,
Are the schematic and PCB layout CAD files for the EOMA68 computer card and the various housings available for download? I'm wondering if I can fabricate some of the housings on my own using a CNC mill. Hence, my interest in them.
Sorry I had to ask. I searched very hard through the crowdsupply page and the rhombus-tech site, but couldn't find them.
http://rhombus-tech.net/crowdsupply/
which leads to
http://hands.com/~lkcl/eoma/kde_tablet/3dcase
the Card is using an off-the-shelf PCMCIA case, no CAD exists. having one (to be able to replace it) would be great.
the micro-desktop case is done using pyopenscad and pydxf.
the laptop is also pyopenscad.
no, i'll not be converting 18 months of work over to a GUI-based system that forces me to use a mouse :)
l.
http://rhombus-tech.net/crowdsupply/
which leads to
Thanks!
I am not able to open the PCB and schematic files at http://hands.com/~lkcl/eoma/microdesktop/ and http://hands.com/~lkcl/eoma/laptop_15in/ . I tried gEDA PCB and KiCAD. What software should I use? Are these OrCAD files? Can I open them using any free software?
no, i'll not be converting 18 months of work over to a GUI-based system that forces me to use a mouse :)
No problem! I too am happy with text oriented interfaces. :-)
On Thu, May 16, 2019 at 8:03 PM Arun Isaac arunisaac@systemreboot.net wrote:
http://rhombus-tech.net/crowdsupply/
which leads to
Thanks!
I am not able to open the PCB and schematic files at http://hands.com/~lkcl/eoma/microdesktop/ and http://hands.com/~lkcl/eoma/laptop_15in/ . I tried gEDA PCB and KiCAD. What software should I use?
Mentor PADS 9.6.
Are these OrCAD files?
no - ORCAD is unbelievably badly designed.
Can I open them using any free software?
no. KiCAD and gEDA simply aren't up to the job of dealing with this type of project. i dedicated several months making a huge effort to design a Card in KiCAD, it was... well, it wasn't time wasted: it was "time discovering that KiCAD is so inadequate that its use would *ACTIVELY* prevent and prohibit the completion of the entire goal"
no, i'll not be converting 18 months of work over to a GUI-based system that forces me to use a mouse :)
No problem! I too am happy with text oriented interfaces. :-)
:)
you'd be the second person - in the entire world - to be using pyopenscad. yes, really. solidpython was abandoned by its author: fortunately i recognised its potential and rescued it before he went ahead with a radically different (unsuitable) direction, which i don't believe he ever completed. i kept the name "pyopenscad"
the actual code is quite ingenious and very simple: it creates mirror-objects of openscad objects (which as you know, SCAD is just a thin wrapper around libCGAL anyway). when you create a python-based pyopenscad object by calling the function "cube(5,6,3)", that stores in-memory sufficient information to, duh, create a cube of dimensions x=5, y=6, z=3.
however what *actually* happens is, when you call the function that requests generation of openscad output, the *python object tree* is recursively walked, and each python object simply outputs *EQUIVALENT OPENSCAD TEXT* that matches precisely and exactly what the python code asked for.
i have the following in ~/.vimrc so that i can hit the "comma" key: map , ^[:w^M:!python %:t^M^M
by setting up 2 xterms on the left side (one for editing, one to view library routines used *by* that file), and opening openscad on the laptop_model.scad file mostly full-screen to the right, the above macro will *automatically* do a file-save followed by *execution* of that file.
this will get that file (the python program) to execute, generating a new version of laptop_model.scad....
... openscad will *AUTOMATICALLY* notice that and re-render the model.
now, the only thing is: the laptop model is so absolutely massive that even a high-end GPU has severe difficulty rendering it. don't for god's sake try to view the laptop models without OpenGL having been set up. an Intel GPU (950 etc. etc.) is perfectly sufficient.
at the top of the laptop_model file you will see there's a "part-selection" enum that is used further down to select which parts to render.
in the riki200 3D printer i made this much more sophisticated, going with an object-orientated approach, and adding in options to auto-generate the STL files.
however, laptop_model.py is the earlier precursor and i stuck with a function-based approach that made a lot of sense due to the reduced simplicity of the program (the riki200 includes BOM-generation and much more).
let me know how you get on.
l.
KiCAD and gEDA simply aren't up to the job of dealing with this type of project. i dedicated several months making a huge effort to design a Card in KiCAD, it was... well, it wasn't time wasted: it was "time discovering that KiCAD is so inadequate that its use would *ACTIVELY* prevent and prohibit the completion of the entire goal"
That's very disappointing. I was hoping to fabricate the PCBs for at least the housings. Now, it looks like I have to redo the PCBs in KiCAD. :-( Will you be providing KiCAD files in the future? Being able to use only free software is a highly desirable feature. And, just out of curiosity, in what way, did you find KiCAD inadequate?
you'd be the second person - in the entire world - to be using pyopenscad. yes, really.
No, I don't use pyopenscad per se. But, I am comfortable using text and programming interfaces. I'm not a big fan of using the mouse. So, I have no issue with the CAD designs being available only in pyopenscad.
solidpython was abandoned by its author: fortunately i recognised its potential and rescued it before he went ahead with a radically different (unsuitable) direction, which i don't believe he ever completed. i kept the name "pyopenscad"
the actual code is quite ingenious and very simple: it creates mirror-objects of openscad objects (which as you know, SCAD is just a thin wrapper around libCGAL anyway). when you create a python-based pyopenscad object by calling the function "cube(5,6,3)", that stores in-memory sufficient information to, duh, create a cube of dimensions x=5, y=6, z=3.
however what *actually* happens is, when you call the function that requests generation of openscad output, the *python object tree* is recursively walked, and each python object simply outputs *EQUIVALENT OPENSCAD TEXT* that matches precisely and exactly what the python code asked for.
i have the following in ~/.vimrc so that i can hit the "comma" key: map , ^[:w^M:!python %:t^M^M
by setting up 2 xterms on the left side (one for editing, one to view library routines used *by* that file), and opening openscad on the laptop_model.scad file mostly full-screen to the right, the above macro will *automatically* do a file-save followed by *execution* of that file.
this will get that file (the python program) to execute, generating a new version of laptop_model.scad....
... openscad will *AUTOMATICALLY* notice that and re-render the model.
now, the only thing is: the laptop model is so absolutely massive that even a high-end GPU has severe difficulty rendering it. don't for god's sake try to view the laptop models without OpenGL having been set up. an Intel GPU (950 etc. etc.) is perfectly sufficient.
at the top of the laptop_model file you will see there's a "part-selection" enum that is used further down to select which parts to render.
in the riki200 3D printer i made this much more sophisticated, going with an object-orientated approach, and adding in options to auto-generate the STL files.
however, laptop_model.py is the earlier precursor and i stuck with a function-based approach that made a lot of sense due to the reduced simplicity of the program (the riki200 includes BOM-generation and much more).
let me know how you get on.
Thank you for the detailed explanation. But, for now, my interest is primarily in the PCB designs. I'll be trying out the CAD designs only if I can fabricate the PCB. So, for now, that is a blocker. :-(
On Sat, May 18, 2019 at 4:05 PM Arun Isaac arunisaac@systemreboot.net wrote:
KiCAD and gEDA simply aren't up to the job of dealing with this type of project. i dedicated several months making a huge effort to design a Card in KiCAD, it was... well, it wasn't time wasted: it was "time discovering that KiCAD is so inadequate that its use would *ACTIVELY* prevent and prohibit the completion of the entire goal"
That's very disappointing. I was hoping to fabricate the PCBs for at least the housings. Now, it looks like I have to redo the PCBs in KiCAD. :-( Will you be providing KiCAD files in the future?
the question needs to be read as, "will someone pay me the extraordinarily large sum needed to spend vast amounts of time - estimated somewhere around 7-12 months - just to deal with the complete utter lack of any kind of professional capabilities that KiCAD simply and utterly fails to have, which would approximately triple or quadruple the completion time"
Being able to use only free software is a highly desirable feature. And, just out of curiosity, in what way, did you find KiCAD inadequate?
where the f*** do i even start???
* corruption of schematics * assumptions by the developers that adversely affected understandability * violation of "principle of least surprise" https://en.wikipedia.org/wiki/Least_surprise * intransigence on the part of the developers to fix the problems when reported (despite other people reporting the same) * corruption of PCB files (destruction of traces) * total lack of DRC * total lack of being able to specify track, pad, component, net, net group, via and other clearances in any kind of meaningful way * total lack of matrix interdependent clearances between the same * total lack of differential-pair support * total lack of any kind of "assisted routing"
you name it, it's not there. i'm staggered that anyone who has worked with *professional* PCB layout software would even remotely take KiCAD seriously.
eagle - even the monetarily-zero-cost version, which i used to create a far better 40V 32-bit-capable version of the RAMPS 1.4 (btw, RAMPS 1.4 is so dangerous it's actually burned peoples' houses to the ground) - is better, by miles.
do take that as a warning that if you are considering using KiCAD, you'll know what to expect.
you'd be the second person - in the entire world - to be using pyopenscad. yes, really.
No, I don't use pyopenscad per se. But, I am comfortable using text and programming interfaces. I'm not a big fan of using the mouse. So, I have no issue with the CAD designs being available only in pyopenscad.
great.
let me know how you get on.
Thank you for the detailed explanation. But, for now, my interest is primarily in the PCB designs. I'll be trying out the CAD designs only if I can fabricate the PCB. So, for now, that is a blocker. :-(
i'm absolutely serious: you'd be better off with the [monetarily-zero-cost] eagle, then, just before production, export / convert to KiCAD format if you absolutely insist on using it.
hypothetically you could use both applications, working round the monetarily-zero-cost limitations (2-layer), importing from one to the other, 2 layers at a time.
or just pay for an eagle license.
yes, really, KiCAD is so bad (and the developers so incapable of understanding how critical the flaws are in what they've written) that yes, i'm a software libre advocate, recommending to you, another software libre developer, to use proprietary PCB CAD software.
l.
Hello, I am unable to withstand this old and out of the objective review of KiCAD. Therefore I want to write something. I was more than five years *professional* user of PADS from Mentor Graphics. And for now, I am using KiCAD.
The troubles which Luke mention disappeared in last years when CERN invest a large amount of work and money to bring KiCAD on a professional level.
And yes, Arun, unavailability of easily sharable CAD design formats is a blocker of potential widespread use by the community. But I personally hope, there will be enough appeal of open design files that I or someone else redesign it in KiCAD. But such redesign is not mandatory on the current stage of the project. Because of the project idea must be verified first and it could be done with the design data created in almost anything. The piece which currently missed is proof of "That really works".
Jakub
so 18. 5. 2019 v 17:25 odesílatel Luke Kenneth Casson Leighton < lkcl@lkcl.net> napsal:
On Sat, May 18, 2019 at 4:05 PM Arun Isaac arunisaac@systemreboot.net wrote:
KiCAD and gEDA simply aren't up to the job of dealing with this type of project. i dedicated several months making a huge effort to design a Card in KiCAD, it was... well, it wasn't time wasted: it was "time discovering that KiCAD is so inadequate that its use would *ACTIVELY* prevent and prohibit the completion of the entire goal"
That's very disappointing. I was hoping to fabricate the PCBs for at least the housings. Now, it looks like I have to redo the PCBs in KiCAD. :-( Will you be providing KiCAD files in the future?
the question needs to be read as, "will someone pay me the extraordinarily large sum needed to spend vast amounts of time - estimated somewhere around 7-12 months - just to deal with the complete utter lack of any kind of professional capabilities that KiCAD simply and utterly fails to have, which would approximately triple or quadruple the completion time"
Being able to use only free software is a highly desirable feature. And, just out of curiosity, in what way, did you find KiCAD inadequate?
where the f*** do i even start???
- corruption of schematics
- assumptions by the developers that adversely affected understandability
- violation of "principle of least surprise"
https://en.wikipedia.org/wiki/Least_surprise
- intransigence on the part of the developers to fix the problems
when reported (despite other people reporting the same)
- corruption of PCB files (destruction of traces)
- total lack of DRC
- total lack of being able to specify track, pad, component, net, net
group, via and other clearances in any kind of meaningful way
- total lack of matrix interdependent clearances between the same
- total lack of differential-pair support
- total lack of any kind of "assisted routing"
you name it, it's not there. i'm staggered that anyone who has worked with *professional* PCB layout software would even remotely take KiCAD seriously.
eagle - even the monetarily-zero-cost version, which i used to create a far better 40V 32-bit-capable version of the RAMPS 1.4 (btw, RAMPS 1.4 is so dangerous it's actually burned peoples' houses to the ground) - is better, by miles.
do take that as a warning that if you are considering using KiCAD, you'll know what to expect.
you'd be the second person - in the entire world - to be using pyopenscad. yes, really.
No, I don't use pyopenscad per se. But, I am comfortable using text and programming interfaces. I'm not a big fan of using the mouse. So, I have no issue with the CAD designs being available only in pyopenscad.
great.
let me know how you get on.
Thank you for the detailed explanation. But, for now, my interest is primarily in the PCB designs. I'll be trying out the CAD designs only if I can fabricate the PCB. So, for now, that is a blocker. :-(
i'm absolutely serious: you'd be better off with the [monetarily-zero-cost] eagle, then, just before production, export / convert to KiCAD format if you absolutely insist on using it.
hypothetically you could use both applications, working round the monetarily-zero-cost limitations (2-layer), importing from one to the other, 2 layers at a time.
or just pay for an eagle license.
yes, really, KiCAD is so bad (and the developers so incapable of understanding how critical the flaws are in what they've written) that yes, i'm a software libre advocate, recommending to you, another software libre developer, to use proprietary PCB CAD software.
l.
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
On Sunday, May 19, 2019, Jakub Kákona kaklik@mlab.cz wrote:
Hello, I am unable to withstand this old and out of the objective review of KiCAD. Therefore I want to write something. I was more than five years *professional* user of PADS from Mentor Graphics.
Which means that you have been extremely well trained as an experienced engineer.
Which in turn means that now you do not strictly need the DRC and editing assistance that PADS provides.
I started out the other way round. I began with KiCAD and it was s***. I wasted 6 months.
Then, a few years later (after CERN's improvements I believe) a high profile project tried to do an A64 layout, including DDR3. It was successful but absolute hell.
And for now, I am using KiCAD.
Great. Does it have
Push and shove
Auto assist routing
Track length DRCs
Group track min and max DRC
Impedance estimation
Clearance DRCs on any to any of VIA Track Net TrackGroup DiffPair Polygon
Does the routing assist feature respect the clearance DRCs above
And have they fixed that damn awful utterly stupid naming where the library editor uses part and another name then when you actually use them the names change?
And if you create a multipart does it still destroy pins?
And if you lay out tracks that have not been added to the layer DRC, does it,still destroy them WITHOUT WARNING?
And has the extremely poor attitude of the developers towards experienced engineers been fixed?
The troubles which Luke mention disappeared in last years when CERN invest a large amount of work and money to bring KiCAD on a professional level.
And yes, Arun, unavailability of easily sharable CAD design formats is a blocker of potential widespread use by the community. But I personally hope, there will be enough appeal of open design files that I or someone else redesign it in KiCAD.
Indeed, this would be fantastic.
It would also be fantastic to have, finally, an import and export function from PADS to KiCAD and vice versa.
I did begin exploring the DCOM interface to PADS, it is inadequate.
But such redesign is not mandatory on the current stage of the project.
Because of the project idea must be verified first and it could be done with the design data created in almost anything. The piece which currently missed is proof of "That really works".
Jakub
so 18. 5. 2019 v 17:25 odesílatel Luke Kenneth Casson Leighton < lkcl@lkcl.net> napsal:
On Sat, May 18, 2019 at 4:05 PM Arun Isaac arunisaac@systemreboot.net wrote:
KiCAD and gEDA simply aren't up to the job of dealing with this type of project. i dedicated several months making a huge effort to
design
a Card in KiCAD, it was... well, it wasn't time wasted: it was "time discovering that KiCAD is so inadequate that its use would *ACTIVELY* prevent and prohibit the completion of the entire goal"
That's very disappointing. I was hoping to fabricate the PCBs for at least the housings. Now, it looks like I have to redo the PCBs in KiCAD. :-( Will you be providing KiCAD files in the future?
the question needs to be read as, "will someone pay me the extraordinarily large sum needed to spend vast amounts of time - estimated somewhere around 7-12 months - just to deal with the complete utter lack of any kind of professional capabilities that KiCAD simply and utterly fails to have, which would approximately triple or quadruple the completion time"
Being able to use only free software is a highly desirable feature. And, just out of curiosity, in what way, did you find KiCAD inadequate?
where the f*** do i even start???
- corruption of schematics
- assumptions by the developers that adversely affected
understandability
- violation of "principle of least surprise"
https://en.wikipedia.org/wiki/Least_surprise
- intransigence on the part of the developers to fix the problems
when reported (despite other people reporting the same)
- corruption of PCB files (destruction of traces)
- total lack of DRC
- total lack of being able to specify track, pad, component, net, net
group, via and other clearances in any kind of meaningful way
- total lack of matrix interdependent clearances between the same
- total lack of differential-pair support
- total lack of any kind of "assisted routing"
you name it, it's not there. i'm staggered that anyone who has worked with *professional* PCB layout software would even remotely take KiCAD seriously.
eagle - even the monetarily-zero-cost version, which i used to create a far better 40V 32-bit-capable version of the RAMPS 1.4 (btw, RAMPS 1.4 is so dangerous it's actually burned peoples' houses to the ground) - is better, by miles.
do take that as a warning that if you are considering using KiCAD, you'll know what to expect.
you'd be the second person - in the entire world - to be using pyopenscad. yes, really.
No, I don't use pyopenscad per se. But, I am comfortable using text and programming interfaces. I'm not a big fan of using the mouse. So, I
have
no issue with the CAD designs being available only in pyopenscad.
great.
let me know how you get on.
Thank you for the detailed explanation. But, for now, my interest is primarily in the PCB designs. I'll be trying out the CAD designs only
if
I can fabricate the PCB. So, for now, that is a blocker. :-(
i'm absolutely serious: you'd be better off with the [monetarily-zero-cost] eagle, then, just before production, export / convert to KiCAD format if you absolutely insist on using it.
hypothetically you could use both applications, working round the monetarily-zero-cost limitations (2-layer), importing from one to the other, 2 layers at a time.
or just pay for an eagle license.
yes, really, KiCAD is so bad (and the developers so incapable of understanding how critical the flaws are in what they've written) that yes, i'm a software libre advocate, recommending to you, another software libre developer, to use proprietary PCB CAD software.
l.
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
btw, arun, jakub: don't get me wrong, i'm *angry* at how KiCAD and other libre PCB development software is not up to the job, and how its lack of features makes being an extremely experienced electrical design engineer an absolutely essential prerequisite for its use.
l.
On Saturday 18. May 2019 18.49.32 Jakub Kákona wrote:
And yes, Arun, unavailability of easily sharable CAD design formats is a blocker of potential widespread use by the community. But I personally hope, there will be enough appeal of open design files that I or someone else redesign it in KiCAD.
I guess you, Jakub, must be involved with the following...
https://github.com/MLAB-project/Modules https://github.com/MLAB-project/kicad-mlab
Does that mean that the SoC modules referenced there are KiCad designs?
On the topic of KiCad and designs related to the EOMA68-A20 cards, it is worth noting that the Olimex A64-OLinuXino board schematic and layout is available in KiCad format:
https://github.com/OLIMEX/OLINUXINO/tree/master/HARDWARE/A64-OLinuXino/A64-O...
It seems like earlier boards were done with Eagle, but I guess that they made the jump to KiCad in the last couple of years. An important aspect of the above board is the availability of component/footprint libraries:
https://github.com/OLIMEX/KiCAD
I am not going to argue in favour of KiCad's usability or otherwise, particularly since my computer probably doesn't have the performance to make it work very well, but it was possible to at least play around with the A64- OLinuXino design once I had set up some symbolic links to let KiCad find the libraries. (Also KiCad 5.0.2+dfsg1-1 was needed - from Debian testing - rather than the surprisingly earlier 5.0.0+dfsg1-1 found in Debian unstable.)
So perhaps someone who is better at KiCad might have some fun adapting that design. It is open (source) hardware, after all. There were a few people on this list a few years ago who might have given this a go, but I don't know what happened to them.
Paul
On Sun, May 19, 2019 at 10:09 PM Paul Boddie paul@boddie.org.uk wrote:
On the topic of KiCad and designs related to the EOMA68-A20 cards, it is worth noting that the Olimex A64-OLinuXino board schematic and layout is available in KiCad format:
https://github.com/OLIMEX/OLINUXINO/tree/master/HARDWARE/A64-OLinuXino/A64-O...
this is the project i was referring to that was a nightmare to develop. there's a FOSDEM talk about it.
btw, just so that people are aware: tsvetan has consistently lied to a *lot* of people and caused huge problems for the EOMA project.
l.
On Monday 20. May 2019 04.22.41 Luke Kenneth Casson Leighton wrote:
On Sun, May 19, 2019 at 10:09 PM Paul Boddie paul@boddie.org.uk wrote:
On the topic of KiCad and designs related to the EOMA68-A20 cards, it is worth noting that the Olimex A64-OLinuXino board schematic and layout is available in KiCad format:
https://github.com/OLIMEX/OLINUXINO/tree/master/HARDWARE/A64-OLinuXino/A64 -OLinuXino_Rev_D
this is the project i was referring to that was a nightmare to develop. there's a FOSDEM talk about it.
I'd have to review what has been said about it: there are usually indications of problems in the Olimex blog articles, either in the articles themselves or in the comments. Right now, I only recall problems with the A64 kernel support, as usual, and nothing much about developing the hardware.
Various Olimex talks have covered KiCad, but my impression was that they were largely happy about it. This doesn't mean that these projects are necessarily collaborative or have people actually looking at the designs. I didn't find any discussion in their forums about such things.
One of my motivations for looking closer was to see whether people can actually open these files and do things with them. As far as I can tell, these files seem to be usable, although one would have to go through the entire process to find out whether they genuinely reproduce the same board, of course.
Anyway, here are some articles I found about this board and KiCad:
https://olimex.wordpress.com/2015/10/16/we-work-on-a64-olinuxino-the-first-o...
https://olimex.wordpress.com/2015/11/20/a64-olinuxino-update-2/
https://olimex.wordpress.com/2015/11/10/a64-olinuxino-update-schematic-almos...
https://olimex.wordpress.com/2016/01/08/a64-olinuxino-oshw-linux-computer-is...
https://olimex.wordpress.com/2016/01/22/a64-olinuxino-routing-completed-but-...
https://olimex.wordpress.com/2016/02/17/a64-olinuxino-64-bit-arm-oshw-design...
There isn't really much detail in these articles, but I suppose it gives an impression of the timeline.
btw, just so that people are aware: tsvetan has consistently lied to a *lot* of people and caused huge problems for the EOMA project.
Sure, but I thought that I should at least mention that Olimex have made the component/footprint libraries and designs available for KiCad. This might give anyone interested a head start on doing something similar, or at least provide an indication of how much work is involved.
Maybe the design/libraries effectively use modified versions of the standard components/footprints and that it wouldn't be much effort to replicate that work independently. But this would only make designs with other SoCs like the A20 more feasible and give more confidence to people that it can be done.
Paul
P.S. Note that I wouldn't necessarily recommend the A64 as the basis of a product given the apparently ongoing software problems:
https://olimex.wordpress.com/2019/03/08/a64-olinuxinogot-mainline-linux-kern...
Also, this board is distinct from the Olimex A64-based laptop and SOM board, with the latter being completely proprietary, as I understand it.
On Monday 20. May 2019 13.18.14 Paul Boddie wrote:
Also, this board is distinct from the Olimex A64-based laptop and SOM board, with the latter being completely proprietary, as I understand it.
I thought that I should point out, however, that the laptop board designs including the CPU board appear to be freely available:
https://github.com/OLIMEX/DIY-LAPTOP/tree/master/HARDWARE
Again, in case anyone wanted to take a closer look.
Paul
On Tue, May 21, 2019 at 5:43 PM Paul Boddie paul@boddie.org.uk wrote:
Again, in case anyone wanted to take a closer look.
thanks paul.
l.
On Tuesday 21. May 2019 21.57.16 Luke Kenneth Casson Leighton wrote:
On Tue, May 21, 2019 at 5:43 PM Paul Boddie paul@boddie.org.uk wrote:
Again, in case anyone wanted to take a closer look.
thanks paul.
No problem! Actually, looking a bit closer at PCB-related topics, I started to wonder about a few things. Maybe they are actually covered in the specifications or on the wiki, but I didn't manage to find what I was looking for.
First of all, investigating the EOMA68 computer card characteristics, I didn't find the physical dimensions of such cards other than mentions of their thickness. I imagine that the dimensions would be the same as those of the different PC Card (PCMCIA) profiles:
https://web.archive.org/web/20080822091349/http://www.pcmcia.org/pccard.htm#...
I did find a PCB size of 85mm x 55mm in diagrams on the Engineering Board pages:
https://www.elinux.org/Embedded_Open_Modular_Architecture/EOMA68/Engineering... https://www.elinux.org/Embedded_Open_Modular_Architecture/EOMA68/MiniEnginee...
Also, the A10 news page has mentions of these dimensions from several years ago:
http://rhombus-tech.net/allwinner_a10/news/
However, the PC Card documentation indicates that the actual housing of such a card is only 54mm wide, so I don't see how existing PC Card housings would accommodate such a PCB.
There is also the matter of the length of a PCB. Again, the PC Card housing is supposedly 85.6mm, which leaves a board length of 85mm as being plausible. Have these measurements been confirmed or maybe subsequently revised?
I do remember that EOMA68 cards (maybe of an earlier generation) were produced. Then again, looking at the A10 news page, there is a picture of a PCB layout from 2013 with dimensions of 78.1mm x 47.3mm, although it isn't completely clear what the screenshot is really showing.
Another thing that I wondered about is the width of the board when accommodating a board edge connector like the Amphenol 95622-004LF, which seems to be a low-cost and readily-available connector. It seems that the board edge needs to be less than 50.8mm across because such connectors enclose the contact area on each side.
Is that generally how these connectors work? I see that pictures of EOMA68 computer card PCBs seem to have a narrower edge connector part, with the rest of the board presumably spanning the interior of a PC Card housing.
I am only really asking these questions because I have been looking at making some footprints and other resources, and at least the fundamental board dimensions should be an obvious thing to discover, but I just didn't see them mentioned as prominently as I had thought they would be.
Paul
On Fri, May 31, 2019 at 3:47 PM Paul Boddie paul@boddie.org.uk wrote:
Also, the A10 news page has mentions of these dimensions from several years ago:
http://rhombus-tech.net/allwinner_a10/news/
However, the PC Card documentation indicates that the actual housing of such a card is only 54mm wide, so I don't see how existing PC Card housings would accommodate such a PCB.
that's what cost USD $15k when the engineer we paid didn't read the spec properly. i told him to source one of the caseworks, measure the INNER dimensions of the area as defined by the plastic, and use those.
he FAILED to listen, and instead produced a PCB of the OUTER dimensions that, clearly, wouldn't even fucking well fit inside the fucking case.
he also failed to run basic DRC which showed that he'd added a power track that shorted across a GND pad.
I do remember that EOMA68 cards (maybe of an earlier generation) were produced.
yes.
Then again, looking at the A10 news page, there is a picture of a PCB layout from 2013 with dimensions of 78.1mm x 47.3mm, although it isn't completely clear what the screenshot is really showing.
Another thing that I wondered about is the width of the board when accommodating a board edge connector like the Amphenol 95622-004LF, which seems to be a low-cost and readily-available connector. It seems that the board edge needs to be less than 50.8mm across because such connectors enclose the contact area on each side.
https://cdn.amphenol-icc.com/media/wysiwyg/files/drawing/95622.pdf
that's a really weird connector. it appears to be a socket, however it is one that fits on the *edge* of a PCB, of a very specific height (am having difficulty working that out from the diagram). it's probably requiring 1.2mm PCB however that is guess-work.
no wait, Cross Section C, it's 1.5mm, and that also tells us it's the PCMCIA *header*.
btw, 1.5mm is useless because the clearance on TOP components is nowhere near enough.
I am only really asking these questions because I have been looking at making some footprints and other resources, and at least the fundamental board dimensions should be an obvious thing to discover, but I just didn't see them mentioned as prominently as I had thought they would be.
the PCB has to fit inside the casework, and the casework's *external* dimensions are required to conform to PCMCIA.
PCMCIA, is, obviously (https://www.google.com/search?q=PCMCIA+card+dimensions) 5.0 x 85.6 x 54.0 mm
however the reason why there's no prominent mention of the *inner* dimensions is because, obviously, they're critically dependent on what *casework* is chosen, *NOT* repeat *NOT* on a hard spec.
it is *PCMCIA case size conformance* that is the hard requirement, *NOT* the actual PCB size.
example: the PCB size (its length) will also critically depend on the PCMCIA header dimensions. if the header is N mm deep, then obviously, if you make a PCB that is exactly 85.6 mm long, it will stick out the end of the PCMCIA casework by N mm, won't it?
so this is why you don't see "PCB dimensions" mentioned as a fixed quantity anywhere in the EOMA68 specification, because the PCB dimensions must be *CALCULATED*, based on the PCMCIA *PARTS* that are selected for use in production.
l.
On Friday 31. May 2019 17.06.14 Luke Kenneth Casson Leighton wrote:
On Fri, May 31, 2019 at 3:47 PM Paul Boddie paul@boddie.org.uk wrote:
Also, the A10 news page has mentions of these dimensions from several years ago:
http://rhombus-tech.net/allwinner_a10/news/
However, the PC Card documentation indicates that the actual housing of such a card is only 54mm wide, so I don't see how existing PC Card housings would accommodate such a PCB.
that's what cost USD $15k when the engineer we paid didn't read the spec properly. i told him to source one of the caseworks, measure the INNER dimensions of the area as defined by the plastic, and use those.
The inner dimensions are actually interesting for practical reasons, which was why I was asking about the range of PCB sizes.
[...]
I do remember that EOMA68 cards (maybe of an earlier generation) were produced.
yes.
There was a run of cards done at one point (or more). Did anyone actually do anything with those cards at the time? I seem to remember confusion about engineering boards, people having one kind of board and not the other, and so on. Did they all end up in people's desk drawers or something?
Then again, looking at the A10 news page, there is a picture of a PCB layout from 2013 with dimensions of 78.1mm x 47.3mm, although it isn't completely clear what the screenshot is really showing.
Again, it was interesting to see this with regard to what kind of PCB sizes would actually be produced.
Another thing that I wondered about is the width of the board when accommodating a board edge connector like the Amphenol 95622-004LF, which seems to be a low-cost and readily-available connector. It seems that the board edge needs to be less than 50.8mm across because such connectors enclose the contact area on each side.
https://cdn.amphenol-icc.com/media/wysiwyg/files/drawing/95622.pdf
that's a really weird connector. it appears to be a socket, however it is one that fits on the *edge* of a PCB, of a very specific height (am having difficulty working that out from the diagram). it's probably requiring 1.2mm PCB however that is guess-work.
no wait, Cross Section C, it's 1.5mm, and that also tells us it's the PCMCIA *header*.
Yes, my interpretation of Section C-C is that 1.5mm is the minimum board thickness, with the usual 2.2mm connector.
btw, 1.5mm is useless because the clearance on TOP components is nowhere near enough.
When you note that 1.5mm is useless, do you mean that within a housing (casework), a 1.5mm board takes too much space from, say, 3.3mm (Type I) or 5.0mm (Type II), and that a thinner board is needed?
Computer card heights/thicknesses mentioned here, by the way:
https://www.elinux.org/Embedded_Open_Modular_Architecture/EOMA68/FAQ
I could understand 3.3mm being difficult, with 0.9mm left on each side of the board, but 5.0mm should leave 2.6mm (minus casework) on one side. Then again, I know the margins can be pretty small with these things.
I am only really asking these questions because I have been looking at making some footprints and other resources, and at least the fundamental board dimensions should be an obvious thing to discover, but I just didn't see them mentioned as prominently as I had thought they would be.
the PCB has to fit inside the casework, and the casework's *external* dimensions are required to conform to PCMCIA.
Yes.
PCMCIA, is, obviously (https://www.google.com/search?q=PCMCIA+card+dimensions) 5.0 x 85.6 x 54.0 mm
This is what I found, but I wondered why it wasn't mentioned on the specification pages, or why 55mm appears in the diagrams. I did find two pages with the 85mm x 54mm x 5mm dimensions on the Rhombus Tech site, however:
http://rhombus-tech.net/allwinner/a31/orders/ http://rhombus-tech.net/freescale/iMX6/orders/
however the reason why there's no prominent mention of the *inner* dimensions is because, obviously, they're critically dependent on what *casework* is chosen, *NOT* repeat *NOT* on a hard spec.
it is *PCMCIA case size conformance* that is the hard requirement, *NOT* the actual PCB size.
Yes, it was really for an indication of what kind of PCB sizes result from these hard requirements that prompted me to ask. That and a need to question why there were boards made that were wider than the apparent external width of the card housing.
example: the PCB size (its length) will also critically depend on the PCMCIA header dimensions. if the header is N mm deep, then obviously, if you make a PCB that is exactly 85.6 mm long, it will stick out the end of the PCMCIA casework by N mm, won't it?
Yes, so my impression is that a PCB using the Amphenol part referenced above would give up 6mm of the total board length budget, yielding a 79.6mm PCB, perhaps minus whatever any rear part of the casework might require. Again, not having any experience with the casework, it would be interesting to know what the margins are, especially if ports would be exposed.
so this is why you don't see "PCB dimensions" mentioned as a fixed quantity anywhere in the EOMA68 specification, because the PCB dimensions must be *CALCULATED*, based on the PCMCIA *PARTS* that are selected for use in production.
Yes, so my query was mostly motivated by a lack of familiarity with the variables unknown to me, which are mainly related to how bulky the casework is.
Paul
On Saturday, June 1, 2019, Paul Boddie paul@boddie.org.uk wrote:
On Friday 31. May 2019 17.06.14 Luke Kenneth Casson Leighton wrote:
On Fri, May 31, 2019 at 3:47 PM Paul Boddie paul@boddie.org.uk wrote:
Also, the A10 news page has mentions of these dimensions from several years ago:
http://rhombus-tech.net/allwinner_a10/news/
However, the PC Card documentation indicates that the actual housing of such a card is only 54mm wide, so I don't see how existing PC Card housings would accommodate such a PCB.
that's what cost USD $15k when the engineer we paid didn't read the spec properly. i told him to source one of the caseworks, measure the INNER dimensions of the area as defined by the plastic, and use those.
The inner dimensions are actually interesting for practical reasons, which was why I was asking about the range of PCB sizes.
If there is no user facing connector, there is the possibility of a range of length.
If it is ok to stick the PCB out the end of the Card just like WIFI and Eth PCMCIA used to do, length is limited only by practicalities.
Otherwise, there is no "range": the casework really does define the PCB size to around a 0.1 mm tolerance or less.
[...]
I do remember that EOMA68 cards (maybe of an earlier generation) were produced.
yes.
There was a run of cards done at one point (or more). Did anyone actually do anything with those cards at the time? I seem to remember confusion about engineering boards, people having one kind of board and not the other, and so on. Did they all end up in people's desk drawers or something?
Pretty much.
Then again, looking at the A10 news page, there is a picture of a PCB layout from 2013 with dimensions of 78.1mm x 47.3mm, although it
isn't
completely clear what the screenshot is really showing.
Again, it was interesting to see this with regard to what kind of PCB sizes would actually be produced.
78.1 x 47.3 is what is required for the litkconn casework, and there is no wiggle room on that.
Another thing that I wondered about is the width of the board when accommodating a board edge connector like the Amphenol 95622-004LF,
which
seems to be a low-cost and readily-available connector. It seems that
the
board edge needs to be less than 50.8mm across because such connectors enclose the contact area on each side.
https://cdn.amphenol-icc.com/media/wysiwyg/files/drawing/95622.pdf
that's a really weird connector. it appears to be a socket, however it is one that fits on the *edge* of a PCB, of a very specific height (am having difficulty working that out from the diagram). it's probably requiring 1.2mm PCB however that is guess-work.
no wait, Cross Section C, it's 1.5mm, and that also tells us it's the PCMCIA *header*.
Yes, my interpretation of Section C-C is that 1.5mm is the minimum board thickness, with the usual 2.2mm connector.
btw, 1.5mm is useless because the clearance on TOP components is nowhere near enough.
When you note that 1.5mm is useless, do you mean that within a housing (casework), a 1.5mm board takes too much space from, say, 3.3mm (Type I) or 5.0mm (Type II), and that a thinner board is needed?
Both.
Computer card heights/thicknesses mentioned here, by the way:
https://www.elinux.org/Embedded_Open_Modular_Architecture/EOMA68/FAQ
I could understand 3.3mm being difficult, with 0.9mm left on each side of the board, but 5.0mm should leave 2.6mm (minus casework) on one side. Then again, I know the margins can be pretty small with these things.
They are. This was described several times on this list and in at least one update.
The stainless steel is 0.1mm thick. That leaves 4.8mm.
The SDMMC sits 1.9mm above the PCB, as does the mid mount USB OTG.
The 2.2uH Inductors were also very very specifically chosen to fit under a 1.9mm threshold, they are 3.2 x 3.2 mm and are quite expensive compared to cheaper wire wound inductors which come in around the 2.5mm height mark.
Also the SoC is around the same height, plus various large capacitors (1206 10uF) and one large diode have all had to be special item "Low Profile" orders, all 1.9mm or lower.
So now we are down to 2.9mm.
On the underside the *MID MOUNT* Micro HDMI and USB OTG connectors sit 1.6mm below the PCB.
No components above that height are permitted, it has meant a couple of redesigns, moving some large 0805 capacitors topside.
These underside capacitors, particularly under the CPU and DRAM, are absolutely essential for stabilising power during peak loads, and they clearly cannot go on TOP because they have to be extremely short tracks. Being NEXT to the SoC would NOT be okay. They HAVE to go underside, as close to the BGA pin where power is drained as physically possible.
Aside from the Micro HDMI and OTG mid mount connectors there is nothing over a 1mm height. Still, that is enough.
2.9 minus 1.6 is 1.3mm
That leaves a mere TENTH of a millimetre spare clearance if using a 1.2mm PCB.
Can you see that for this type of design a 1.5mm PCB would be completely impractical?
If on the other hand there were no mid mount connectors it MIGHT be possible.
Anyway this is why Litkconn header and casework were selected because it has all 68 PCMCIA pins on TOP instead of a twin pair staggered in height.
I am only really asking these questions because I have been looking at making some footprints and other resources, and at least the
fundamental
board dimensions should be an obvious thing to discover, but I just didn't see them mentioned as prominently as I had thought they would
be.
the PCB has to fit inside the casework, and the casework's *external* dimensions are required to conform to PCMCIA.
Yes.
PCMCIA, is, obviously (https://www.google.com/search?q=PCMCIA+card+dimensions) 5.0 x 85.6 x 54.0 mm
This is what I found, but I wondered why it wasn't mentioned on the specification pages, or why 55mm appears in the diagrams. I did find two pages with the 85mm x 54mm x 5mm dimensions on the Rhombus Tech site, however:
If you see any that are wrong please do correct them.
http://rhombus-tech.net/allwinner/a31/orders/ http://rhombus-tech.net/freescale/iMX6/orders/
however the reason why there's no prominent mention of the *inner* dimensions is because, obviously, they're critically dependent on what *casework* is chosen, *NOT* repeat *NOT* on a hard spec.
it is *PCMCIA case size conformance* that is the hard requirement, *NOT* the actual PCB size.
Yes, it was really for an indication of what kind of PCB sizes result from these hard requirements that prompted me to ask. That and a need to question why there were boards made that were wider than the apparent external width of the card housing.
Engineer whom we paid $15k to didn't listen to instructions.
We got access to a Senior Engineer after that, at a massive discount.
That was Mr Xu and he was brilliant. The PCB he did was visually stunningly beautiful.
example: the PCB size (its length) will also critically depend on the PCMCIA header dimensions. if the header is N mm deep, then obviously, if you make a PCB that is exactly 85.6 mm long, it will stick out the end of the PCMCIA casework by N mm, won't it?
Yes, so my impression is that a PCB using the Amphenol part referenced above would give up 6mm of the total board length budget, yielding a 79.6mm PCB, perhaps minus whatever any rear part of the casework might require.
Sonething like that, yes.
Again, not having any experience with the casework, it would be interesting to know what the margins are, especially if ports would be exposed.
0.1mm would be an acceptable tolerance.
so this is why you don't see "PCB dimensions" mentioned as a fixed quantity anywhere in the EOMA68 specification, because the PCB dimensions must be *CALCULATED*, based on the PCMCIA *PARTS* that are selected for use in production.
Yes, so my query was mostly motivated by a lack of familiarity with the variables unknown to me, which are mainly related to how bulky the casework is.
The case is very very specifically tied to the connector.
It's no good ordering random headers and hoping that the plastic and metal case will fit it.
The ends of the connector for example may have a different shape from another manufacturer part.
Bottom line, it is basically absolutely critical to get a matched set of casework and connector.
The casework forms the basis of fitting in the rails.
No casework, the bare PCB can be misaligned on insertion, not just horizontally by a couple of pins, it can even be misinserted by an entire row.
I deliberately overordered litkcon cases and headers, as a just in case. And the AMP socket and rails, too. Meaning, some can be ordered from Mike direct, if you really need them.
And overordered somewhat on the JAE mid mount micro HDMI Type D, after going through FOUR redesigns due to HDMI Connectors going EOL, sigh
L.
Paul
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
On Friday 31. May 2019 23.49.57 Luke Kenneth Casson Leighton wrote:
On Saturday, June 1, 2019, Paul Boddie paul@boddie.org.uk wrote:
The inner dimensions are actually interesting for practical reasons, which was why I was asking about the range of PCB sizes.
If there is no user facing connector, there is the possibility of a range of length.
If it is ok to stick the PCB out the end of the Card just like WIFI and Eth PCMCIA used to do, length is limited only by practicalities.
Yes, this makes sense.
Otherwise, there is no "range": the casework really does define the PCB size to around a 0.1 mm tolerance or less.
It was mostly needing to know how wide a PCB might need to be. Obviously, one can play it safe by keeping the width well within 54mm.
[...]
There was a run of cards done at one point (or more). Did anyone actually do anything with those cards at the time? I seem to remember confusion about engineering boards, people having one kind of board and not the other, and so on. Did they all end up in people's desk drawers or something?
Pretty much.
Do you have any reflections on that? Was there a realistic expectation that people might develop software or hardware to take advantage of those boards? Could more have been done to accelerate the initiative with this access to actual hardware?
[...]
Again, it was interesting to see this with regard to what kind of PCB sizes would actually be produced.
78.1 x 47.3 is what is required for the litkconn casework, and there is no wiggle room on that.
Right.
[Amphenol 95622-004LF]
When you note that 1.5mm is useless, do you mean that within a housing (casework), a 1.5mm board takes too much space from, say, 3.3mm (Type I) or 5.0mm (Type II), and that a thinner board is needed?
Both.
[...]
They are. This was described several times on this list and in at least one update.
Knowing your policy on information existing only on the list, I had hoped to see more information on the wiki, but it is useful to get more details again now.
The stainless steel is 0.1mm thick. That leaves 4.8mm.
The SDMMC sits 1.9mm above the PCB, as does the mid mount USB OTG.
The 2.2uH Inductors were also very very specifically chosen to fit under a 1.9mm threshold, they are 3.2 x 3.2 mm and are quite expensive compared to cheaper wire wound inductors which come in around the 2.5mm height mark.
Also the SoC is around the same height, plus various large capacitors (1206 10uF) and one large diode have all had to be special item "Low Profile" orders, all 1.9mm or lower.
I must admit that I don't have a wide experience of SoC heights, with the only one to hand here being an Ingenic JZ4780 that doesn't really seem very tall.
So now we are down to 2.9mm.
On the underside the *MID MOUNT* Micro HDMI and USB OTG connectors sit 1.6mm below the PCB.
No components above that height are permitted, it has meant a couple of redesigns, moving some large 0805 capacitors topside.
These underside capacitors, particularly under the CPU and DRAM, are absolutely essential for stabilising power during peak loads, and they clearly cannot go on TOP because they have to be extremely short tracks. Being NEXT to the SoC would NOT be okay. They HAVE to go underside, as close to the BGA pin where power is drained as physically possible.
Aside from the Micro HDMI and OTG mid mount connectors there is nothing over a 1mm height. Still, that is enough.
2.9 minus 1.6 is 1.3mm
That leaves a mere TENTH of a millimetre spare clearance if using a 1.2mm PCB.
Can you see that for this type of design a 1.5mm PCB would be completely impractical?
Yes, it mostly makes sense.
If on the other hand there were no mid mount connectors it MIGHT be possible.
Anyway this is why Litkconn header and casework were selected because it has all 68 PCMCIA pins on TOP instead of a twin pair staggered in height.
Are such headers (I wasn't aware of the terminology) easy to find? Searching for PCMCIA headers in the mainstream channels, even using convenient sites like Octopart, is excruciating.
[...]
This is what I found, but I wondered why it wasn't mentioned on the specification pages, or why 55mm appears in the diagrams. I did find two pages with the 85mm x 54mm x 5mm dimensions on the Rhombus Tech site, however:
If you see any that are wrong please do correct them.
The diagrams are the challenge since they are not readily editable. However, they possibly need reworking, anyway, partly due to their vintage.
[...]
Again, not having any experience with the casework, it would be interesting to know what the margins are, especially if ports would be exposed.
0.1mm would be an acceptable tolerance.
Right. Good to know, thanks.
[...]
Yes, so my query was mostly motivated by a lack of familiarity with the variables unknown to me, which are mainly related to how bulky the casework is.
The case is very very specifically tied to the connector.
It's no good ordering random headers and hoping that the plastic and metal case will fit it.
The ends of the connector for example may have a different shape from another manufacturer part.
Bottom line, it is basically absolutely critical to get a matched set of casework and connector.
Yes, I understand that although the connector should be standardised, how the "non-mating" side of the connector fits into the housing might be wildly different from one kind of connector/header to the next.
The casework forms the basis of fitting in the rails.
No casework, the bare PCB can be misaligned on insertion, not just horizontally by a couple of pins, it can even be misinserted by an entire row.
This seems pretty unfortunate, really. It does seem that the Amphenol connector tries to guard against this - as well as I interpret the drawings - and I wonder if others also do so. But I wouldn't really know about these kinds of assembly problems.
Do you think that, ultimately, some other connector standard would be more accessible? That is, easier to develop for without substantial tooling investment.
I deliberately overordered litkcon cases and headers, as a just in case. And the AMP socket and rails, too. Meaning, some can be ordered from Mike direct, if you really need them.
And overordered somewhat on the JAE mid mount micro HDMI Type D, after going through FOUR redesigns due to HDMI Connectors going EOL, sigh
Yes, very frustrating.
Paul
On Sat, Jun 1, 2019 at 7:05 PM Paul Boddie paul@boddie.org.uk wrote:
Otherwise, there is no "range": the casework really does define the PCB size to around a 0.1 mm tolerance or less.
It was mostly needing to know how wide a PCB might need to be. Obviously, one can play it safe by keeping the width well within 54mm.
the connector end clearly has to be wide enough to actually fit the connector pins. that's somewhere around the 41 mm mark.
[...]
There was a run of cards done at one point (or more). Did anyone actually do anything with those cards at the time? I seem to remember confusion about engineering boards, people having one kind of board and not the other, and so on. Did they all end up in people's desk drawers or something?
Pretty much.
Do you have any reflections on that? Was there a realistic expectation that people might develop software or hardware to take advantage of those boards?
the vivaldi project - where its leader aaron seigo lied to a *lot* of people in order to keep his standing with his team, after agreeing to the hardware spec *and* the approach taken (which then didn't work out, and he ran out of money to do another iteration) - that really f*****d things up.
it didn't help that the people that he'd picked to work on the hardware and the website failed to listen to what i was saying: they made a board that didn't conform to the spec, and started publicly making unauthorized statements about what would go into the EOMA68 specification.
that was the big opportunity to reach a lot more people - hardware and software engineers.
it also didn't help that tsvetan has consistently and repeatedly lied to people in the sunxi community (and other businesses) about the goals and business collaboration that we proposed to him. his lying has caused several people in both the hardware and software communities to walk away, because they believed his lies.
they didn't come and ask me, "is this true?", meaning that they *wanted* to believe the lying.
Could more have been done to accelerate the initiative with this access to actual hardware?
that was the idea: unfortunately, as those people were volunteers, they didn't take it further. someone will, at some point.
Knowing your policy on information existing only on the list,
que? no, the wiki's there for people to edit and make the information more accessible.
Also the SoC is around the same height, plus various large capacitors (1206 10uF) and one large diode have all had to be special item "Low Profile" orders, all 1.9mm or lower.
I must admit that I don't have a wide experience of SoC heights, with the only one to hand here being an Ingenic JZ4780 that doesn't really seem very tall.
it doesn't... and yet if you check, you'll find that the ethernet port is 10mm high (5x higher than the limit for components inside an EOMA68 Card on the TOP layer), a double-height USB2 stack is just over 12mm, and even the TOP mount Micro USB-OTG port will be somewhere around the 4mm mark.
this is what has made the EOMA68 project so ridiculously difficult compared to "Just Yet Another SBC". availability of TOP mount standard-sized components like USB2, ETH, USB-OTG, SD/MMC, they're dead easy to get hold of, plus if the locations are slightly "off", so what?
it was pure fluke for example that the MicroSD, Micro-HDMI and Micro-USB-OTG happen to fit in between the "teeth" of the Litkconn PCMCIA stainless steel shells (the ones that notch into the plastic).
Anyway this is why Litkconn header and casework were selected because it has all 68 PCMCIA pins on TOP instead of a twin pair staggered in height.
Are such headers (I wasn't aware of the terminology) easy to find?
no they're not - PCMCIA is only now used in some obscure locations: France still has Satellite "Conditional Access Module" cards, and the supplier that i found in shenzhen has a big customer in Korea that still buys PCMCIA parts.
Searching for PCMCIA headers in the mainstream channels, even using convenient sites like Octopart, is excruciating.
try finding a mid-mount Micro HDMI Type D, or a mid-mount Micro-USB-OTG.
then check to see if they're not "last available supply in the world" (having been manufactured over 5-8 years ago, and Digikey is the last company in the world with the last remaining parts)...
If you see any that are wrong please do correct them.
The diagrams are the challenge since they are not readily editable. However, they possibly need reworking, anyway, partly due to their vintage.
i hand-edited them anyway.
Bottom line, it is basically absolutely critical to get a matched set of casework and connector.
Yes, I understand that although the connector should be standardised, how the "non-mating" side of the connector fits into the housing might be wildly different from one kind of connector/header to the next.
they're all designed to slot together according to *external* dimensions, because that's what PCMCIA specified. the *internal* dimensions are what you cannot just go and mix-and-match random parts on, because the *internal* dimensions were never part of the PCMCIA specification.
The casework forms the basis of fitting in the rails.
No casework, the bare PCB can be misaligned on insertion, not just horizontally by a couple of pins, it can even be misinserted by an entire row.
This seems pretty unfortunate, really.
PCMCIA was never designed as a "bare PCB mechanism" for engineers, it was designed as a *mass-volume* standard, easy for *users*.
It does seem that the Amphenol connector tries to guard against this - as well as I interpret the drawings - and I wonder if others also do so.
in combination with the correct matching casework, of course. being incompatible with the PCMCIA *external* specification would have been disastrous.
Do you think that, ultimately, some other connector standard would be more accessible? That is, easier to develop for without substantial tooling investment.
if one existed i would have found it and written a spec based around it.
as the number of pins would be completely different, it would *be* an entirely different standard, and would take a good year or so to properly review and get right.
and would require basically leaving all other standards unfinished and require additional funding to complete.
best to get this standard out the door, first.
l.
On Saturday 1. June 2019 21.18.34 Luke Kenneth Casson Leighton wrote:
On Sat, Jun 1, 2019 at 7:05 PM Paul Boddie paul@boddie.org.uk wrote:
Knowing your policy on information existing only on the list,
que? no, the wiki's there for people to edit and make the information more accessible.
That's what I meant. So I was looking on the Rhombus Tech and eLinux.org sites for information, but it wasn't so easy to find the essentials.
[...]
It does seem that the Amphenol connector tries to guard against this - as well as I interpret the drawings - and I wonder if others also do so.
in combination with the correct matching casework, of course. being incompatible with the PCMCIA *external* specification would have been disastrous.
On the topic of connectors and casework, I happened to come across this selection of products:
http://www.morethanall.com/products/index/btype_id/5/type_id/62
(It was while investigating the Olimex KiCad footprints that I found an obscure product code for a microSD connector, this then yielding the above site when searching the Web.)
I just thought I'd post the details here in case it happened to be of interest, the company being based in New Taipei City, no less.
Paul
On Tue, Jun 11, 2019 at 8:09 PM Paul Boddie paul@boddie.org.uk wrote:
http://www.morethanall.com/products/index/btype_id/5/type_id/62
(It was while investigating the Olimex KiCad footprints that I found an obscure product code for a microSD connector, this then yielding the above site when searching the Web.)
I just thought I'd post the details here in case it happened to be of interest, the company being based in New Taipei City, no less.
ahh superb.
On Wed, Jun 12, 2019 at 1:58 AM Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:
On Tue, Jun 11, 2019 at 8:09 PM Paul Boddie paul@boddie.org.uk wrote:
http://www.morethanall.com/products/index/btype_id/5/type_id/62
(It was while investigating the Olimex KiCad footprints that I found an obscure product code for a microSD connector, this then yielding the above site when searching the Web.)
I just thought I'd post the details here in case it happened to be of interest, the company being based in New Taipei City, no less.
ahh superb.
added here http://rhombus-tech.net/pcmcia_sources/
On Wednesday 12. June 2019 02.09.12 Luke Kenneth Casson Leighton wrote:
added here http://rhombus-tech.net/pcmcia_sources/
I have updated this page with some more details and some remarks about the physical constraints involved. If such remarks belong elsewhere, feel free to move them.
It was interesting to work through some of the calculations. The 0.4mm offset of one of the header parts seems like a curious figure until one does the calculations and determines that it must be intended for boards of 1.2mm thickness (or less) with components mounted on the upper side.
Indeed, headers employing such an offset might conceivably be interesting when considering sockets on the "non-EOMA68" edge of a computer card, since these headers would maximise the space available to components on the upper side of a board, presumably permitting top-mount sockets to be used. I don't know whether this would have influenced the choice of sockets in the current batch of boards, but I wonder if it might be influential or useful to consider for any subsequent production.
I hope this was helpful, anyway.
Paul
P.S. I have also been working on KiCad footprints for some of the parts I have found, in case anyone is still interested in such things.
On Sun, Jun 16, 2019 at 5:14 PM Paul Boddie paul@boddie.org.uk wrote:
On Wednesday 12. June 2019 02.09.12 Luke Kenneth Casson Leighton wrote:
added here http://rhombus-tech.net/pcmcia_sources/
I have updated this page with some more details and some remarks about the physical constraints involved. If such remarks belong elsewhere, feel free to move them.
no, great idea.
It was interesting to work through some of the calculations. The 0.4mm offset of one of the header parts seems like a curious figure until one does the calculations and determines that it must be intended for boards of 1.2mm thickness (or less) with components mounted on the upper side.
yyep. so the female header on the Card clearly has to be at a fixed height relative to the plastic and the metal case, which means that the offsetting of the SMT pins on the header will actually raise or lower the PCB that is connected to it.
therefore, get this wrong, and the PCB will be so low that you can't get any components on one of the two sides.
Indeed, headers employing such an offset might conceivably be interesting when considering sockets on the "non-EOMA68" edge of a computer card, since these headers would maximise the space available to components on the upper side of a board, presumably permitting top-mount sockets to be used.
interestingly, there's nothing to stop you putting the card inside the PCB at a slight angle, such that whilst at the PCMCIA header end there is plenty of room (relatively speaking) on either side of the PCB, and at the other end the PCB becomes flush with the floor of the metal case.
I don't know whether this would have influenced the choice of sockets in the current batch of boards, but I wonder if it might be influential or useful to consider for any subsequent production.
the issue is that even if the 1.2mm PCB is flush with the 5.0mm floor (leaving no room for underside components for about... 35 possibly even as much as 40mm (half) the Card, which would hugely complicate the design, the connectors are still around 3.3mm in height (USB-OTG, Micro-HDMI Type D)
5.0 - 0.1 (thickness of the metal) - 1.2 (PCB thickness) = 3.7mm
3.7 - 3.3 (height of the connector) = 0.4mm
minus another 0.1mm for the top case shield.
so that leaves only 0.3mm clearance, which means that the connectors will poke out in a completely asymmetric way, which is very ugly.
the mid-mount option gave a reasonably symmetric above- and below- gap that doesn't look quite so ugly.
plus, having 50% of the PCB impossible to put components on the BOTTOM side means that the PMIC area would need redesigning (again), spreading out the components to fit the ones that normally go on BOTTOM.
I hope this was helpful, anyway.
yes, very.
Paul
P.S. I have also been working on KiCad footprints for some of the parts I have found, in case anyone is still interested in such things.
superb. if you send me an ssh key i can arrange to add you to the repo that i started 6 years ago: http://git.rhombus-tech.net/?p=eoma.git;a=summary
l.
On Monday 17. June 2019 08.40.22 Luke Kenneth Casson Leighton wrote:
On Sun, Jun 16, 2019 at 5:14 PM Paul Boddie paul@boddie.org.uk wrote:
On Wednesday 12. June 2019 02.09.12 Luke Kenneth Casson Leighton wrote:
added here http://rhombus-tech.net/pcmcia_sources/
I have updated this page with some more details and some remarks about the physical constraints involved. If such remarks belong elsewhere, feel free to move them.
no, great idea.
Phew!
[...]
interestingly, there's nothing to stop you putting the card inside the PCB at a slight angle, such that whilst at the PCMCIA header end there is plenty of room (relatively speaking) on either side of the PCB, and at the other end the PCB becomes flush with the floor of the metal case.
I think you'd really have to be confident amount the manufacturing process to do this.
I don't know whether this would have influenced the choice of sockets in the current batch of boards, but I wonder if it might be influential or useful to consider for any subsequent production.
the issue is that even if the 1.2mm PCB is flush with the 5.0mm floor (leaving no room for underside components for about... 35 possibly even as much as 40mm (half) the Card, which would hugely complicate the design, the connectors are still around 3.3mm in height (USB-OTG, Micro-HDMI Type D)
5.0 - 0.1 (thickness of the metal) - 1.2 (PCB thickness) = 3.7mm
3.7 - 3.3 (height of the connector) = 0.4mm
minus another 0.1mm for the top case shield.
so that leaves only 0.3mm clearance, which means that the connectors will poke out in a completely asymmetric way, which is very ugly.
I guess that the solution involving extending the board to provide connectors, in that classic PCMCIA/CardBus style seen with things like USB adapter cards, wasn't desirable because it would demand extra casework to be done at quite some expense. So the mid-mount connectors were a reasonable compromise.
the mid-mount option gave a reasonably symmetric above- and below- gap that doesn't look quite so ugly.
plus, having 50% of the PCB impossible to put components on the BOTTOM side means that the PMIC area would need redesigning (again), spreading out the components to fit the ones that normally go on BOTTOM.
Yes, I can imagine that limiting the components to one side brings its own challenges. For simple cards only providing flash memory and other such things (Web searches yield some kind of card for Mercedes vehicles of this nature), I guess that it isn't a major concern.
[...]
P.S. I have also been working on KiCad footprints for some of the parts I have found, in case anyone is still interested in such things.
superb. if you send me an ssh key i can arrange to add you to the repo that i started 6 years ago: http://git.rhombus-tech.net/?p=eoma.git;a=summary
I'll send you that, trying to remember the preferred form of the exported key this time. ;-)
Paul
On Monday, 17 June 2019 13:15:18 CET Paul Boddie wrote:
On Monday 17. June 2019 08.40.22 Luke Kenneth Casson Leighton wrote:
repo that i started 6 years ago: http://git.rhombus-tech.net/?p=eoma.git;a=summary
I'll send you that, trying to remember the preferred form of the exported key this time. ;-)
Currently, the above repository is only available securely via the following address:
https://git.hands.com/?p=eoma.git;a=summary
Meanwhile, I updated the wiki page describing PCMCIA/CardBus component details:
https://rhombus-tech.net/pcmcia_sources/
(Thanks for Phil for fixing the wiki!)
One interesting thing that came up, given the conversation that was had over two years ago, was this product and corresponding brochure about PC Card casings and tooling:
https://www.ittcannon.com/products/starcard-snappy/
https://www.ittcannon.com/Core/medialibrary/ITTCannon/website/Literature/ Catalogs-Brochures/PC_Card_Final.pdf?ext=.pdf
On page 37 of the brochure, there are some pictures of the tools that would be used to facilitate assembly and disassembly. I seem to remember complaints about assembly, and I found some remarks on this list from back in 2017...
"the litkconn P/N 68F casework basically is a "total disassmbly" job. it's a pain in the ass and takes several minutes."
http://lists.phcomp.co.uk/pipermail/arm-netbook/2017-May/013788.html
In the crowdfunding updates, the awkwardness of assembly is also mentioned here:
"Additionally, I am considering sending out the PCB and casework unassembled, with full and precise assembly instructions for backers to follow. It’s not hard: it just needs to be done very carefully. This will save a considerable amount of time and money, as the cards casework will need hand-assembly (quantity 1,000)."
https://www.crowdsupply.com/eoma68/micro-desktop/updates/pcbs-and-components...
So, I guess that with the above product family, one would want to invest in that tooling as well as the actual products, just to do things as the manufacturer intended. It is an interesting insight into part of the process that goes into making the product.
I also had a bit more luck searching for product documentation today and also found this:
https://media.digikey.com/pdf/Data%20Sheets/Hirose%20PDFs/NX1.pdf
The product itself is about to be discontinued, but there's an interesting pictorial assembly guide including a picture of an assembly jig.
Paul
Paul Boddie paul@boddie.org.uk writes:
On Monday, 17 June 2019 13:15:18 CET Paul Boddie wrote:
On Monday 17. June 2019 08.40.22 Luke Kenneth Casson Leighton wrote:
repo that i started 6 years ago: http://git.rhombus-tech.net/?p=eoma.git;a=summary
That wasn't working because I'd neglected to add the rhombus name to the git.hands.com certificate, and I'm now serving that with nginx, which I've configured to redirect http to https, so that repository is now served via https which was then breaking with the name mismatch.
BTW the most straightforward URL is:
https://git.rhombus-tech.net/eoma
(which is the same thing as https://git.hands.com/eoma )
Currently, the above repository is only available securely via the following address:
Yeah, that was down to the certificate, and is now fixed.
Meanwhile, I updated the wiki page describing PCMCIA/CardBus component details:
https://rhombus-tech.net/pcmcia_sources/
(Thanks for Phil for fixing the wiki!)
Glad to see that the new nginx setup seems to be working for people (it's also considerably less load-inducing than the old hybrid nginx/apache setup that left most CGI stuff to apache)
If you notice any oddities, please mention them, as I may have missed something in the move.
Cheers, Phil.
On Sun, Jan 30, 2022 at 10:29 PM Philip Hands phil@hands.com wrote:
If you notice any oddities, please mention them, as I may have missed something in the move.
brilliant, thanks for sorting this Phil, really appreciated you're keeping things running.
l.
On Sunday, 30 January 2022 23:38:04 CET Luke Kenneth Casson Leighton wrote:
On Sun, Jan 30, 2022 at 10:29 PM Philip Hands phil@hands.com wrote:
If you notice any oddities, please mention them, as I may have missed something in the move.
brilliant, thanks for sorting this Phil, really appreciated you're keeping things running.
Thanks once again to Phil!
Did you ever hear anything more from Chris about the boards that were sent to him? Or did you get an opportunity to look at the ones that were sent your way?
https://www.crowdsupply.com/eoma68/micro-desktop/updates/100-a20-computer-ca...
Obviously, Pablo did look at one board back in June/July 2020, prior to the above update, but he didn't get very far, unfortunately. It seems that of the 100 cards that were manufactured, Chris ended up with at least 90 of them:
http://lists.phcomp.co.uk/pipermail/arm-netbook/2021-March/016421.html
He was apparently busy getting a wireless networking dongle RYF certified in June of last year:
http://lists.phcomp.co.uk/pipermail/arm-netbook/2021-June/016427.html
So, I wonder if anything happened since then.
Paul
P.S. While I wasn't looking, Intel followed on from its Compute Card...
https://www.intel.com/content/dam/www/public/us/en/documents/guides/compute-...
...with a range of NUC Elements products:
https://www.intel.com/content/www/us/en/products/details/nuc/elements.html
https://www.intel.com/content/dam/www/public/us/en/documents/brochures/nuc-e...
They even have a laptop product using the NUC Compute Element:
https://www.intel.com/content/dam/www/central-libraries/us/en/documents/inte...
The Compute Element being a more conservative evolution of the Compute Card, I suppose.
On Sat, 18 May 2019 16:25:13 +0100 Luke Kenneth Casson Leighton lkcl@lkcl.net wrote: <snip>
Eagle - even the monetarily-zero-cost version, which I used to create a far better 40V 32-bit-capable version of the RAMPS 1.4 (btw, RAMPS 1.4 is so dangerous it's actually burned peoples' houses to the ground) - is better, by miles.
<snip>
I didn't know you were an opensource arsonist. :)
Do you have some KiCAD files of the incendiaries you used? :)
Anonymous
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Sun, May 19, 2019 at 11:42 PM David Niklas doark@mail.com wrote:
On Sat, 18 May 2019 16:25:13 +0100 Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:
<snip> > Eagle - even the monetarily-zero-cost version, which I used to create > a far better 40V 32-bit-capable version of the RAMPS 1.4 (btw, RAMPS > 1.4 is so dangerous it's actually burned peoples' houses to the > ground) - is better, by miles. <snip>
I didn't know you were an opensource arsonist. :)
:)
working with eagle a couple years ago i was so shocked by the unprofessional use of 0.5 amp thermals in RAMPS 1.4 i felt compelled to document it:
https://reprap.org/wiki/RAMPS_1.4#WARNING_-_THERMAL-isolation-related_DESIGN...
there is not enough space and the 0.5 amp thermals are completely inadequate anyway, leading to in some cases only something like 2.5 A maximum safe current capacity when the total load can be as high as 6.0A. that can result in something like a 25 to 30C temperature rise above ambient for the rest of the PCB.
once one of the thermal tracks burns out you get runaway.
yes i met someone who had imported RAMPS 1.4 into Canada, and sold them. yes, one burned someone's apartment down. yes the FCC fined the company and prohibited them from selling electronics.
Do you have some KiCAD files of the incendiaries you used? :)
very funny :)
arm-netbook@lists.phcomp.co.uk
-
Arun Isaac -
David Niklas -
Jakub Kákona -
Luke Kenneth Casson Leighton -
Paul Boddie -
Philip Hands