Code Monkey home page Code Monkey logo

housings_qfp.pretty's Introduction

KiCad README

For specific documentation about building KiCad, policies and guidelines, and source code documentation see the Developer Documentation website.

You may also take a look into the Wiki, the contribution guide.

For general information about KiCad and information about contributing to the documentation and libraries, see our Website and our Forum.

Build state

KiCad uses a host of CI resources.

GitLab CI pipeline status can be viewed for Linux and Windows builds of the latest commits.

Release status

latest released version(s) Release status

Files

  • AUTHORS.txt - The authors, contributors, document writers and translators list
  • CMakeLists.txt - Main CMAKE build tool script
  • copyright.h - A very short copy of the GNU General Public License to be included in new source files
  • Doxyfile - Doxygen config file for KiCad
  • INSTALL.txt - The release (binary) installation instructions
  • uncrustify.cfg - Uncrustify config file for uncrustify sources formatting tool
  • _clang-format - clang config file for clang-format sources formatting tool

Subdirectories

  • 3d-viewer - Sourcecode of the 3D viewer
  • bitmap2component - Sourcecode of the bitmap to PCB artwork converter
  • cmake - Modules for the CMAKE build tool
  • common - Sourcecode of the common library
  • cvpcb - Sourcecode of the CvPCB tool
  • demos - Some demo examples
  • doxygen - Configuration for generating pretty doxygen manual of the codebase
  • eeschema - Sourcecode of the schematic editor
  • gerbview - Sourcecode of the gerber viewer
  • include - Interfaces to the common library
  • kicad - Sourcecode of the project manager
  • libs - Sourcecode of KiCad utilities (geometry and others)
  • pagelayout_editor - Sourcecode of the pagelayout editor
  • patches - Collection of patches for external dependencies
  • pcbnew - Sourcecode of the printed circuit board editor
  • plugins - Sourcecode for the 3D viewer plugins
  • qa - Unit testing framework for KiCad
  • resources - Packaging resources such as bitmaps and operating system specific files
  • scripting - Python integration for KiCad
  • thirdparty - Sourcecode of external libraries used in KiCad but not written by the KiCad team
  • tools - Helpers for developing, testing and building
  • translation - Translation data files (managed through Weblate for most languages)
  • utils - Small utils for KiCad, e.g. IDF, STEP, and OGL tools and converters

housings_qfp.pretty's People

Contributors

carlpoirier avatar dasfrank avatar evanshultz avatar hvraven avatar jeromebeguin avatar jkriege2 avatar matthias-c avatar michal777 avatar poeschlr avatar pointhi avatar rdeterre avatar schrodingersgat avatar twam avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

housings_qfp.pretty's Issues

"Duplicate" footprints for naming/identification clarity

In this repo we have LQFP-44_10x10mm_Pitch0.8mm. It's a fine footprint to which any component would be happy be soldered.

However, at http://www.analog.com/media/en/technical-documentation/data-sheets/AD7722.pdf apparently the same footprint uses MQFP instead of LQFP. Same package size, same pin spacing, same pin count, etc.

In this case, do we want to have two duplicate footprints so that the user can identify the package to be used in CvPcb by the manufacturer name? Or use to the LQFP footprint even though it's not what ADI calls this package, so that we don't bloat the KiCad libraries? Having multiple footprints adds a bit of overhead, but with scripting and other automation isn't not much. But I'm unsure if there's any benefit to doing it.

LQFP footprint pins have varying sizes

I was starting a new project with STM32L0 uC which comes in various packages (LQFP64 and LQFP48 both with 0.5mm pitch and LQFP32 with 0.8mm pitch). ST's documentation suggests that the pad size for 0.5mm pitch should be (0.3 x 1.2)mm and for LQFP32 it should be (0.5x1.2)mm.

Unfortunately the pad sizes in this library didn't match sizes suggested by ST and are pretty inconsistent:

  • LQFP with 0.4mm pitch
    • LQFP-64 - (1.2x0.24)mm
    • LQFP-128 - (1.0x0.2)mm
    • LQFP-176 - (1.0x0.23)mm
    • LQFP-216 - (1.12x0.24)mm
  • LQFP with 0.5mm pitch (STM32L0 datasheets suggests (1.2x0.3)mm pads for LQFP-48 and -64)
    • LQFP-32 - (1.2x0.28)mm
    • LQFP-48 - (1.3x0.25)mm
    • LQFP-64 - (1.0x0.25)mm
    • LQFP-80 - (1.5x0.28)mm
    • LQFP-100 - (1.5x0.28)mm
    • LQFP-128 - (1.5x0.28)mm
    • LQFP-144 - (1.55x0.3)mm
    • LQFP-160 - (1.1x0.285)mm
    • LQFP-176 - (1.12x0.3)mm
    • LQFP-208 - (1.5x0.4)mm
  • LQFP with 0.65mm pitch
    • LQFP-36 - (1.0x0.43)mm
    • LQFP-52-1EP - (1.18x0.4)mm
    • LQFP-52 - (1.0x0.25)mm
  • LQFP with 0.8mm pitch (STM32L0 datasheet suggests (1.2x0.5)mm pads for LQFP-32)
    • LQFP-32 - (1.2x0.6)mm
    • LQFP-44 - (1.6x0.56)mm
    • LQFP-64 - (1.5x0.6)mm

I'm volunteering to clean up the footprints with 0.5mm and 0.8mm pitches if someone says that the values coming from ST docs are correct.

LQFP-64_10x10mm: Pin 1 Marker not visible

The PIN one marker of (Housings_QFP:LQFP-64_10x10mm_Pitch0.5mm) is not visible. It's removed by the manufacturer as it's too close to the pads. We should move the Pin1 marker line to the top.

(When I find time I'll provide a patch.)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.