microbit-foundation/microbit-reference-design

Eagle design currently only contains a layout/board

Opened this issue · 15 comments

jaustin commented

The reference design was carried out in Altium, and imported into Eagle.

If anyone has experience with Eagle import, and needs any Altium / Protel export versions and libraries, they can be supplied.

The other option, though time consuming, would be to simply redraw the schematic in Eagle and verify that the net lists are identical.

sjwiseman commented

Just to reinforce this - Eagle import of Altium Schematics through the Accel/Tango/P-CAD ASCII route seems to throw away all of my schematic parts. I / we really want to support makers using Eagle (and Kicad, and all other design packages, I'll help to port to anything). I'd just rather not enter it from scratch for each package - that way lie errors.

OwenBrotherwood commented

May be bad news.
From Help in Eagle Import in easyeda

General
ACCEL ASCII is also known as TangoPRO ASCII or P-CAD ASCII. It can be exported from P-CAD, Altium Designer and PROTEL and therefore allows conversion of designs in these formats to EAGLE. From Altium Designer only boards can be exported to this format.
The conversion to EAGLE works following:
First, in the directory of the input file, an EAGLE library with same name is generated. It contains the devices that are used. With this an EAGLE schematic or board with same name is generated. 
For ACCEL ASCII schematic files partly end with ".sch", EAGLE schematics get ending ".eagle.sch". The conversion of a schematic without board doesn't make much sense because the package information is missing which is necessary for creation of a board.
Because of different data models and powerfulness of the foreign systems and EAGLE the conversion has limits. Ideally certain cases should already be avoided in the original data. Otherwise certain post processing steps may be necessary. In any case we recommend to perform a DRC after import in order to find and eliminate potential weaknesses of the design.
In particular please note that the conversion of a schematic and related board into a consistent schematic board pair in EAGLE is not supported, because schematics in ACCEL ASCII do not contain package data which is necessary for the linking of parts and elements.
In some cases the creation of consistency is possible by manual post processing.
Layer assignment
Depending on the source system, signal, solder and other layer types have different names. For conversion a default assignment is used which may not always be correct. For this case you can change this individually with the option "Adjust layer mapping".
Conversion details:

Names: 
To follow EAGLE's naming conventions for different types of entities certain characters are replaced by '_', in particular '(', ')', '[', ']', ''' and space. '\\' is replaced by '/'. Control characters like '\\r' are not processed in a special way.
Texts:
All texts are converted to vectorfont in EAGLE. This allows a system independent representation for polygon calculation and CAM processing. The font can be changed to fixed or proportional where needed. All other text properties are taken over from ACCEL ASCII.
Pads and SMDs: 
For pad and SMD types following conversion agreement is used:
Square pad/SMD -> SQUARE pad/SMD,
Rectangle pad -> SQUARE pad with additional rectangle polygon,
Oval pad -> LONG pad in EAGLE (size and shape of original and converted pads are slightly different in this case),
Ellipse pad -> ROUND pad with additional approximation polygon consisting of four arcs,
Polygon pad -> SQUARE pad with additional polygon,
Round rectangle pad -> SQUARE pad and additional polygon with rounded corners,
Target pad -> ROUND pad,
Rectangle SMD -> rectangle SMD,
Oval SMD -> SMD with 100% roundness,
Ellipse SMD -> round SMD with additional approximation polygon consisting of four arcs,
Polygon SMD -> square SMD with additional polygon,
Round rectangle -> SMD with 25% roundness,
Target SMD -> SMD with 100% roundness.
Standalone pads (Free pads): 
For standalone pads an appropriate library package is created in EAGLE.
Vias:
Vias are converted the following way to EAGLE:
Oval -> ROUND, Rectangle -> SQUARE, Ellipse -> ROUND, Round rectangle -> SQUARE and Target -> ROUND.
The sizes of the EAGLE vias are adjusted to fit within the shape of the ACCEL vias to avoid clearance issues.
Contacts / Routing: 
In EAGLE coordinates of traces, pads, vias etc. have to match exactly in order to be properly routed. Otherwise airwires are generated. In some other systems certain deviations are allowed.In other systems it's possible that a longer trace crosses a pad without connecting point. In EAGLE this leads to an airwire to the next connecting point. In this case the trace needs to be splitted with SPLIT command in order to create an additional connecting point at the pad position. 
Copper polygons general: 
In EAGLE there's only one type for hatched polygons (horizontal and vertical stripes).The different possible hatch types in ACCEL ASCII like diagonal style for example, are all converted to this.
Thermals within polygons are also always horizontal and vertical. There's no specific thermal spoke width for each polygon, but a general value in the EAGLE design rules.
The removal of orphan property is converted to EAGLE but without threshold value (only on/off).
Copper polygons in poured state: 
In EAGLE polygons are saved always in unpoured state. The pour state is calculated dynamically by RATSNEST and depends on the parameters currently set.
Dimensions: 
As the data model for dimensions in EAGLE is much simpler than in ACCEL ASCII some details are not mapped to EAGLE.
Labels:
Input, output and bidirectional labels are all converted to Xref labels in EAGLE.
Attributes for layers: 
In EAGLE layers can't have attributes. This is skipped.
'zones' (in ACCEL schematic): 
'zones' are not supported and skipped.
OwenBrotherwood commented

https://easyeda.com/Doc/Tutorial/import.htm#Import and Import Altium Designer gives an ascii.
Next step is to test with Eagle

image

OwenBrotherwood commented

With the file that was used with easyeda, the following:

image

sjwiseman commented

Yeah, that's where I got to...
I was hoping that an Eagle guru would point out something obvious. Or non-obvious but manageable.
(I'm still hoping - and keen to help!)

  • 👍1
  • ❤️1
OwenBrotherwood commented

The first target of success is definable as Eagle.

At least one hardware manufacturer/sales outlet in Britain uses it with respect to micro:bit work.
The requirement for sucess is a valid holder of an Eagle license creates a support ticket in connection with the import of a baseline Altium simple design and a micro:bit reference design.
ie simple import has to work, and reference design may have problems that Eagle has not met before.

OwenBrotherwood commented

The necessary data is:

  1. Altium blob:
  • a simple design example
  • micro:bit reference design
  1. Altium export of "Accel Ascii"
  • a simple design example
  • micro:bit reference design

Then the "Eagle has landed"

OwenBrotherwood commented

I created an Altium with just a power point, saved as Accel Ascii and tried import.
Eagle didn't like it.
image

dmalnati commented

Hi all, I made some progress getting the reference design into KiCad6, wondering if any thoughts on how best to proceed. My work is in github.

I tried opening the KiCad files in this repot in KiCad 4, 5, and 6. None of them worked completely for any of the KiCad projects.

However, I'm finding some success in importing the Altium files directly. As noted in the KiCad forum (link), KiCad6 can now natively import Altium projects into both eeschema and pcbnew (independently). I am running KiCad 6.0.5.

Github Links

Below, I talk about what I've done so far, and my results are found in github below (a work in progress):

Altium Files

I strictly copied the .PchDoc and .SchDoc files from the Altium folder in this repot to an empty folder, and did the below.

PCB Import

To do the above, In pcbnew in standalone mode, import the .PchDoc file, then hit save, and it creates a .kicad_pro project file, a .kicad_pcb pcb file, as well as extracted all the 3dmodels (.step) files into a folder called ALTIUM_EMBEDDED_MODELS.

This pcb file is not quite stable, though, in that the models and footprints "work" when being viewed, but are referencing libraries and paths which are no longer real.

To solve this, I:

  • Created the 3dshapes folder by simply copying away the contents of the ALTIUM_EMBEDDED_MODELS to the given dir
    • I forgot to delete the ALTIUM_EMBEDDED_MODELS dir, so ignore it
  • Went through the pcb, reference by reference, and saved the "board" footprints to the library, linking to the new 3dshapes dir
    • Then did a global replace on the pcb of the old invalid library name with the new valid library name. (select component, press e, change footprint, change footprints with library id)
      • This is a tedious process btw, had to keep track in a spreadsheet of all the references replaced, and re-sort each time, and look for gaps in the ranges, and hunt down next not-yet-converted footprints, etc

Then I closed pcbnew.

Schematic Import

In eeschema in standalone mode, import the .SchDoc file, then hit save, and it creates a .kicad_pro project file (already existing), a .kicad_sch schematic file.

Then I closed eeschema.

Linking Schematic and PCB

Open KiCad, and open the .kicad_pro file, and you now see both the schematic and pcb files. This is where I could use some guidance.

At this point, at a minimum, the schematic needs:

  • Symbol reference designators (I recall only 2-4 were missing)
  • Footprints (all still reference the non-existent library the PCB was also previously associated with)

I'm debating the pros/cons and impact of synchronizing the schematic and pcb in two ways:

  • Annotate up the schematic, then going to the pcb and importing changes
  • Annotate the schematic, then from the schematic, tools->update schematic from pcb

I played around with it a bit but need to be more methodical, hence some of the imprecise statements below.

In both directions there are problems.

There seem to be differences in net names the pcb knows about vs the schematic.
There are a number of unconnected vias and pins in the PCB if you import the schematic into it.

In my final submit to github, from eeschema, I updated schematic from pcb. I shouldn't have submitted that before looking more carefully at the impact, and I'm going to roll it back.

The commit previous to that (link) is the point where no steps have been made to synchronize the pcb and schematic yet. Anyone who wishes to help may want to start at that point.

Next Steps

I have to turn my attention to something else for a short while but thought I would post this if anyone could help out in the meantime.

However I hope to return to this in not too long and share whatever progress I can make.

My hope is that I can get a fully functional MicrobitReferenceDesign that can be useful to others.

However my personal objective is to then chop away from that working reference for some embedded system I want to make which doesn't need all the fancy extras the Microbit has (I need the core, wireless, usb, and programming/debugging).

If we can get a working KiCad reference for everyone that's great. Unfortunately due to the number of issues synchronizing the pcb and schematic at the moment, I may find it easier to trash a lot of the reference design and fix fewer issues. Not ideal for the community, so I'm trying the harder road first.

Thanks!

sjwiseman commented
sjwiseman commented
dmalnati commented
bryn4 commented

https://easyeda.com/Doc/Tutorial/import.htm#Import

Gives

image

Hi,
is that schematic as exact as used in the original BBC microbit ?