Pcb Arrival
The board arrived some time over the weekend.
Now comes the task of populating it!
After having made small bugs with other boards, I have found that for a new board the best policy it to slowly populate the first one not in the order in which it is easiest to solder it but to prove each “section” of the design.
eg. Solder up the power sections first, then get the micro to work. Then as each subsequent section gets populated, you can check it did not upset the running of others.
However this is only possible as I am hand soldering a relatively simple board and that the different “sections” do not really interact with each other but rather each section connects to the micro with it able to operate with only a section of the other areas working.
New PCB
Intro
I really like electronics and as I used to be a engineer, but now a software developer, it’s a nice excuse to use skills that I really enjoy and value but rarely get to use any more.
My friend Alex and some of his friends from work, collaborated on a number of RobotWars robots. For the latest one I helped out with some general engineering and some electrical engineering.
Doug, one of Alex’s friends/colleagues, and myself created a number of control boards for the robot Point Blank.
The Board
The board takes simple input from a remote control radio like you would find on any other hobbyist quad-copter or remote control car. It then turns it into instructions for the values that actuate the pneumatic weapon on the robot.
This is my 3rd or 4th iteration of the weapon board and the second one that I have had printed from my own design.
This is the most complex board I have designed and it has the most components that I will have soldered in one go. In preparation I created a mini PCB that contained the most difficult to solder parts, so I hope I should be able to solder the components well.
- The main sections of the board are:
- radio ports
- low power output, 8 ports
- micro controler
- analog in, 4 ports
- USB/Power management
- high current outputs, 4 ports.
There are many aspects of the board I am not yet satisfied with but I have put in quite a lot of effort over a long time to improve these. I have created test circuits for most of the systems, however I think more progress will be made from having the board printed than fettling the design.
Circular Dependencies
Intro
There bad!
Don’t do them
But others may have
Why?
- Common mesons to have Circular Dependencies:
- Examples in freedesk top
- Libs like [harfbuzz](https://gitlab.com/freedesktop-sdk/freedesktop-sdk/blob/18.08/elements/desktop/harfbuzz.bst) that rely on [freetype-stage1](https://gitlab.com/freedesktop-sdk/freedesktop-sdk/blob/18.08/elements/desktop/freetype-stage1.bst) but the full [freetype](https://gitlab.com/freedesktop-sdk/freedesktop-sdk/blob/18.08/elements/desktop/freetype.bst) also rellies on harfbuzz.
- bootstapping, building a compiler that is written in its own language:
- [Vala complier](https://wiki.gnome.org/Projects/Vala) was first written in C then it was re written in Vala, its own language, so it needs the Vala compiler to make the Vala compiler
Circular Dependancies in Build System
Many build systems just make one thing at a eg auto tools, it is your responsibility to build and install the different pieces of software in the write order
But thinks like baserock and buildstream that deal with many projects need to deal with this them selves
The way that some projects that use these tools have developed is stages, these stages seem like seperate pices of software to the build tool but in reality create the same artifacts that can
Example
This example will cover the simple case of a library (libA) that depends on a libary (libB) that depends on the orignal library (libA).
The buildstream elements will be:
- mylib-stage1.bst will build the lib mylib. This will be the basic version that dose not have full capablity.
- secondlib.bst will build the lib secondlib. This will need the basic version of mylib and so will depend on mylib-stage1.bst
- mylib.bst will build the full version of mylib and so will depend on secondlib.bst
The second version of mylib.bst will have the same artifacts as mylib-stage1.bst so any bst element that depends on both must make sure that it they are loaded in the right order so that mylib.bst over writes mylib-stage1.bst’s artifacts.
mylib-stage1.bst
This lib’s only purpose is to provide a starting point for secondlib.bst
kind: cmake
description: |2
Lets make circels
sources:
- kind: git
url: ../circular-git
track: master
ref: 22a73f55dacf46e41c5edbd07b3b1acca8f8b934
depends:
- base.bst
variables:
conf-root: cmksrc/mylib
user@host:~/circular-bst$ bst shell demo-simple.bst -- mainDemo
[--:--:--][][] START Loading elements
[00:00:00][][] SUCCESS Loading elements
[--:--:--][][] START Resolving elements
[00:00:00][][] SUCCESS Resolving elements
[--:--:--][][] START Resolving cached state
[00:00:00][][] SUCCESS Resolving cached state
[--:--:--][23ddd3b8][ main:demo-simple.bst ] START Staging dependencies
[00:00:00][23ddd3b8][ main:demo-simple.bst ] SUCCESS Staging dependencies
[--:--:--][23ddd3b8][ main:demo-simple.bst ] START Integrating sandbox
[00:00:00][23ddd3b8][ main:demo-simple.bst ] SUCCESS Integrating sandbox
[--:--:--][23ddd3b8][ main:demo-simple.bst ] STATUS Running command
mainDemo
sqrt(100)=10
secondlib.bst
This is the final version of secondlib but it is compiled against mylib-stage1.bst but it will work with mylib.bst once it exists.
kind: cmake
description: |2
Lets make circels
sources:
- kind: git
url: ../circular-git
track: master
ref: 22a73f55dacf46e41c5edbd07b3b1acca8f8b934
depends:
- base.bst
- mylib-stage1.bst
variables:
conf-root: cmksrc/secondlib
user@host:~/circular-bst$ bst shell demo-simple-second.bst -- mainDemo
[--:--:--][][] START Loading elements
[00:00:00][][] SUCCESS Loading elements
[--:--:--][][] START Resolving elements
[00:00:00][][] SUCCESS Resolving elements
[--:--:--][][] START Resolving cached state
[00:00:00][][] SUCCESS Resolving cached state
[--:--:--][147a2990][ main:demo-simple-second.bst ] START Staging dependencies
[00:00:00][147a2990][ main:demo-simple-second.bst ] SUCCESS Staging dependencies
[--:--:--][147a2990][ main:demo-simple-second.bst ] START Integrating sandbox
[00:00:00][147a2990][ main:demo-simple-second.bst ] SUCCESS Integrating sandbox
[--:--:--][147a2990][ main:demo-simple-second.bst ] STATUS Running command
mainDemo
sqrt(100)=10
mylib.bst
kind: cmake
description: |2
Lets make circels
sources:
- kind: git
url: ../circular-git
track: master
ref: 22a73f55dacf46e41c5edbd07b3b1acca8f8b934
depends:
- base.bst
- secondlib.bst
variables:
conf-root: cmksrc/mylib
cmake-local: -DDEMO_CIR=TRUE
The only difference between mylib.bst and mylib-stage1.bst are the Dependancies and the build options.
Building the code in the mylib source that depends on secondlib is enabled by calling cmake the the DEMO_CIR buildflag to true.
user@host:~/circular-bst$ bst shell demo.bst -- mainDemo
[--:--:--][][] START Loading elements
[00:00:00][][] SUCCESS Loading elements
[--:--:--][][] START Resolving elements
[00:00:00][][] SUCCESS Resolving elements
[--:--:--][][] START Resolving cached state
[00:00:00][][] SUCCESS Resolving cached state
[--:--:--][399725c2][ main:demo.bst ] START Staging dependencies
[--:--:--][399725c2][ main:demo.bst ] WARNING [overlaps]: Non-whitelisted overlaps detected
Staged files overwrite existing files in staging area:
/usr/include/mylib.h: mylib.bst is not permitted to overlap other elements, order mylib.bst above mylib-stage1.bst
/usr/lib/debug/usr/lib/libmylib.so: mylib.bst is not permitted to overlap other elements, order mylib.bst above mylib-stage1.bst
/usr/lib/libmylib.so: mylib.bst is not permitted to overlap other elements, order mylib.bst above mylib-stage1.bst
[00:00:00][399725c2][ main:demo.bst ] SUCCESS Staging dependencies
[--:--:--][399725c2][ main:demo.bst ] START Integrating sandbox
[00:00:00][399725c2][ main:demo.bst ] SUCCESS Integrating sandbox
[--:--:--][399725c2][ main:demo.bst ] STATUS Running command
mainDemo
sqrt(100)=10
sqrt(100)=14
sqrt(100)=20