File: import.html

package info (click to toggle)
pcb-rnd 3.1.7b-2
  • links: PTS, VCS
  • area: main
  • in suites: forky, sid
  • size: 33,108 kB
  • sloc: ansic: 213,400; yacc: 6,241; sh: 4,698; awk: 3,016; makefile: 2,254; lex: 1,166; python: 519; xml: 261; lisp: 154; tcl: 67; perl: 34; javascript: 6; ruby: 5
file content (64 lines) | stat: -rw-r--r-- 2,574 bytes parent folder | download | duplicates (5)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
<html>
<body>
<h1> pcb-rnd hacking - how importers work </h1>

<h2> Introduction </h2>
This document describes the common aspects of import code, be it an
import_ plugin or the load part of an io_plugin, importing a footprint,
loading a board or a netlist.

<h2> Data structures </h2>

The board is stored in pcb_board_t *. Some import code, like the one
that loads a design (an io plugin's ->parse_pcb function), gets the
target in an argument. (Other, non-import code usually operate on
the global variable that represents the current board:
<i>pcb_board_t *PCB.</i>).
<p>
In either case, pcb_board_t's most important field is <i>pcb_data_t *data</i>,
which holds lists and vectors to store <b>all objects on the board</b>. When
the target is a buffer (e.g. io plugin's ->parse_element function), it's
a <i>pcb_buffer_t *buf</i> which also have a <i>pcb_data_t *data</i> containing
the same data a board could. 
<p>
A pcb_data_t struct in turn has three sets of important fields:
<ul>
	<li> lists for layer-independent objects (e.g. rat lines, padstacks, subcircuits)
	<li> number of layers in use (LayerN) and an array of layers (see later)
	<li> rtree structures - these are used for looking up objects for locations
</ul>
Each layer is a pcb_layer_t structure. A layer has the following fields:
<ul>
	<li> lists for lines, texts, arcs, polygons
	<li> some generic layer attributes (colors, flags, key-value pairs)
	<li> an rtree struct for each object type.
</ul>
<p>
Any code that needs to create objects should use the functions in obj_*.h.
The functions that operate layer-independently usually get a destination as
<i>pcb_data_t</i>, so they can operate both on boards and buffers. A typical
example is <i>pcb_pstk_t *pcb_pstk_new(pcb_data_t *data, ...)</i> that returns
NULL or the pointer to the new via that is already added to the corresponding list
of data and in the rtree.
<p>
Layer object creation is done referencing the layer as <i>pcb_layer_t *</i>. A
typical example is <i>pcb_line_t *pcb_line_new(pcb_layer_t *layer...)</i>
which returns NULL on error or a pointer to the new line object created (inserted
in the layer's line list, added to the rtree).
<p>
Code should <b>avoid</b> manipulating the lists and rtree structures directly.
<table border=1>
<tr><td><img src="data1.png">
<br>
Figure 1. simplified map of object related data structures
<br>
<small>diamond: variable; rectangle: struct; round: struct field; green: drawing primitive</small>
</table>


<h2> Extra steps around creating a new board </h2>
TODO: postproc, post*, other setup