• neo900
  • operations
  • Issues
  • #2

Closed
Open
Opened 2016-07-27T12:51Z by Amer @mad_dev

KiCad migration PR

As per @wpwrak post:

Eagle to KiCad:

  • motivation
    • Nikolaus will definitely not be available for layout (gave signs in that sense Feb 2016, confirmed July 2016)
  • technical
    • we considered Altium, but too proprietary and expensive
    • KiCad routing capabilities are superior to Eagle's
    • we now use version control (git), making changes traceable
  • community
    • development process is now much more open (discussions on #neo900)
    • public access to design files ( https://neo900.org/git/?p=ee )
    • design process now uses only Free tools [right ?]
  • internal organization
    • we're no longer blocked/slowed by uncertainty about future GDC role
    • communication flow Neo900 <-> GDC was hampered by incompatible tools and workflow (for a long time)
    • this caused change requests to pile up, and we used white papers as a means of documenting what we couldn't change in the schematics in a timely manner
    • we can now operate in a more schematics-centric mode, using white papers only where something actually needs explaining
    • entire project team can make changes also to layout, if needed (though "dedicated" layouter is preferred)
    • ahycka offered to do it in Altium, seems sympathetic to idea of using KiCad (still to be confirmed - we first need to do our homework, see below)
  • progress
    • completed bulk of the conversion
    • now fixing bugs (some only discovered during conversion)
    • next weeks: incorporating material "parked" in white papers
    • next weeks: define BB-mX interface
    • ... ?
  • downside
    • reduced access to OMAP know-how (though we hope Nikolaus can review our work)

Please solve the reCAPTCHA

We want to be sure it is you, please confirm you are not a robot.

  • hellekin @hellekin Moved to www#5 (closed) · 2016-07-28T07:52Z

    Moved to www#5 (closed)