Back-End

Overall Fritzing flow on the back-end (first version at least)

For the first version of Fritzing, we are planning to build the back-end on simple automation of the facilities provided by Eagle.  A general flow from the Fritzing front-end schematic and breadboard editor on through to manufacturing and documentation files may look something like the following.  As much as possible, these tasks will be performed in the background, without requiring any user input or action. 

1. User completes breadboard or schematic design in Fritzing application
2. Fritzing-format schematic is imported into Eagle's schematic editor. 
3. Eagle-format schematic is used to generate auto-placement information for components and a PCB is created
4. User reviews and modifies the placement of components on the PCB
5. Board is automatically routed
6. User can review routing and modify (or route by hand if desired)
7. Electrical rule check and design rule check are performed
8. Manufacturing files are generated
9. Manufacturing files are packaged and prepared for submission to manufacturer
10. Documentation files are exported in Fritzing project format 

A few notes on the above process:

• We generate an Eagle-format schematic (rather than moving directly from Fritzing schematic to Eagle PCB) for a few reasons; the user is able to open their files in Eagle with full Eagle functionality (ERC, schematic/PCB synchronization, etc.) when they graduate from Fritzing, and, finally, it's just easier-implementation-wise for the first few versions
  
• The closed, binary nature of Eagle's schematic files means that we can't generate them directly from Fritzing files.  Instead, we can parse the Fritzing files and generate an Eagle-format script which can then be automatically run in Eagle's schematic editor to recreate the schematic as drawn.  It's less complicated than it sounds.  Really.
  
• The main things we'll need to export from Fritzing to do this are; partlist, netlist, and component placement information (coordinates and rotation)
• Since we're trying to automate, automate, automate, and make it easier for users with no experience, these steps mostly happen in the background.  The only point which absolutely requires user intervention (after they complete their design in Fritzing) is (4) where they really should check to make sure the components are reasonably placed and not overlapping each other, hanging off the board, etc.  Once they have checked the board, the user may have to hit "continue".  It may be nice to have the user check the routing but only strictly necessary if the auto-router can't complete in which case the user may have to manually reroute segments or change the component layout and run the auto-router again.  This needs user testing.  A lot of it.
  

Code-Base Candidates

The major candidates for the back-end are gEDA, KiCAD, and EAGLE (see evaluations in the market overview). They all offer a solid and substantial base for our efforts. Our decision will now be based on

• the ease of getting started
• the ease of implementing our own GUI on top
• the support of their communities

This is currently being evaluated.

Portability/Abstraction

Per suggestions from workshop participants, we will start with a quick and dirty first release that implements a minimum of the core Fritzing functions.  The first few releases will also follow this model and, to avoid problems as Fritzing matures, we will be adding a layer of abstraction between the front and back-ends ("Fritzing Abstraction Layer" was suggested and it has a nice sound to it). 

As Dave Mellis pointed out, development should be "seamful" and by having this abstraction layer, we can replace chunks of back-end code as they mature to meet Fritzing's overall needs.

discrete back-end development tasks for first rev.

1. Means to generate Eagle *.sch file from Fritzing breadboard design front-end:
• May implement as a ULP which reads the breadboard design format and just creates a messy schematic (Eagle schematic editor doesn't have an "import" module
2. Eagle script(s) and ULP(s) within Eagle to do auto-placement of components and auto-routing
• For first rev. maybe just put everything inside an Arduino shield board outline with header pads

1. PCB design viewer (gerbview? - is it cross-platform? otherwise Eagle)
   

1. Shell script(s), Eagle script(s), and ULP(s) to automate generation and packaging of CAM files with additional manufacture instructions
2. An Eagle part library which maps to the breadboard part library
   

 Component Library

Which basic components should we support with the first version of Fritzing?  Comments are very welcome.

1. Resistors - one or two of the most popular lead spacings (case size not all that important if we design for carbon's size)
   
2. Ceramic capacitors - two or three of the most popular lead spacings (case size only slightly important - just leave space)
   
3. Electrolytic (Aluminum) capacitors - two or three of the most popular lead spacing/case size combos (typical small 1uF, typical medium 10uF, typical large 100uF?)
4.