All the other projects I have made so far have been digital and microcontroller based, with the one exception to this being the Nutclough amplifier, which was assembled from a kit. The big difference in this project is that unlike the other ones which I have built from scratch it is an analogue RF circuit.
We already had some TA7642 AM receiver ICs in the workshop and some PP3 battery clips to hand, so I wanted to use both of these components in my circuit. Since I had never built any analogue circuits before I wanted to keep this fairly simple so would use an external test audio amplifier for testing.
After doing a bit of research it became apparent that a very important part of the radio is a tuned circuit, which can be tuned to a particular frequency in order to select the radio station desired. This can be made from an inductor and a variable capacitor connected in series or parallel.
I began looking for examples of circuits for the TA7642 and the majority used either a 1.5v or 3v supply. I occasionally found ones which used a 9v battery, however most of these seemed to incorporate built in amplifiers. After a bit more searching I finally found one which did not.
This circuit consists of:
– 1 x 9v battery – 1 x 10k resistor – 1 x 1k resistor – 1 x 100k resistor – 2 x 1n4148 diode – 1 x .01uf capacitor – 1 x .1uf capacitor – 1 x 470uf+ capacitor – 1 x 1uf+ capacitor – 1 x TA7642 IC – 1 x ferrite coil antenna – 1 x variable capacitor – 1 x test amplifier – 1 x switch
I decided not to include a switch, as I could just remove the battery, so I removed the switch from the schematic. The ferrite coil antenna which I had had both a long wave and a medium wave coil on separate formers on the ferrite rod, each coil consisted of a longer coil and a shorter coil too. So there were four coils in total.
I began connecting the components as above in the schematic, using a breadboard. When I powered up the circuit I could hear a muffled radio station, but when I adjusted the capacitor nothing changed and it should have done.
I checked the layout against the schematic again and then powered up the circuit to find the same result. I then checked the values of all the resistors and capacitors for errors, here I found I had accidentally used a 100 ohm resistor instead of 100k. I replaced this and powered up the circuit once more hoping this would resolve the problem, but again it didn’t.
When I initially began looking at tuned circuits many of them only used a single coil of one length. So I then wound my own ferrite antenna using enamel wire and I attempted wiring my circuit with this.
The circuit didn’t work with this coil, so I tried again using the original medium wave coil, but this time not using the shorter winding. Instead by connecting the longer winding and variable capacitor in parallel and directly in circuit.
When the circuit was powered up this time it surprisingly worked! Varying the capacitance tuned the circuit and the radio was now quite clear to listen to.
I’m still unsure as to why the radio circuit didn’t work the first time and I will look into this further to try understand what went wrong.
Another fun project as I learn more about electronics!
In this post we comprehensively learn a step wise process of making small DIY PCBs at home through minimum effort and maximum precision.
DIY Step-wise Procedures
It basically involves the following crucial steps:
Cutting copper clad laminate into proper size.
Punching indentations for drilling holes for the component leads, as per the schematic.
Drawing pads around the indentations with etch resist paint, and linking the pads through tracks using etch resist paint.
Immersing the painted board in ferric chloride solution, until the chemical eats away the exposed copper, leaving the painted layout sections intact.
Drying the board and scrubbing out the etch resist paint from the tracks and the pads.
Drilling holes on the indentations.
Polishing the finished board with fine emery paper.
Using the ready PCB for assembly and soldering the parts.
Now let’s discuss the above steps in details. The first step in PCB production would be to acquire the essential resources and items. We are going to focus on all those things that are fundamental.
Materials Needed for Making PCB
To start the process we will first gather all the vital ingredients or materials required for the PCB making. The following fundamental things will be needed for the production
Copper Clad Laminate
Ferric Chloride Solution
Etch Resist Chemical or paint.
Painting brush or Pen
Container for etching the PCB
Drill Machine and Drill Bit.
Etchant Remover
Scouring pad, Kitchen Paper
Copper Clad Laminate
The most basic item will be the copper clad for making the printed circuit board alone, and you will find a variety of these.
The base (insulating) stuff is generally either fibreglass or SRBP (sheet resin bonded paper), and the latter is usually the more affordable option.
However, fibreglass has become the widely used both with commercial and recreational consumers as it is equipped with a couple of positive aspects.
The first is basically that it is tougher and for that reason less susceptible to bending and breaking than SRBP. The improved durability is additionally very helpful for boards that bear weighty parts for example transformers.
An additional benefit is that fibreglass is translucent and thus typically allows us to view the copper paths through the top (component) area of the board which is often worthwhile when examining and fault-finding.
Having said that, the standard of SRBP boards is more than satisfactory for many requirements. Marketing campaigns usually make reference to board as 1mm, 1.6mm, etc., and this is actually refering to the thickness of the base material.
Board Thickness
Naturally the thicker (about 1.6 to 2mm) boards tend to be more robust compared to slimmer (about 1mm) models, however the heavier quality boards are only crucial for large PCBs, or where weighty parts will likely be installed on the board.
For the majority of applications the thickness of the board is actually of little consequence.
Occasionally copper laminate board will likely be chosen as one ounce quality, or possibly two ounce quality, which appertains to the weight of the copper on one square foot of board.
Most circuits deal with just quite low currents, and regular one ounce board is just about all that’s needed. In reality one ounce board is frequently satisfactory even for circuits involving formidable currents.
The Etch Resist Paint
The etch resist is subsequently taken off to expose the copper tracks and pads.
Whichever paint that is able to keep the etchant away from the copper layout during the etching process can be employed as the resist.
I personally prefer using nail enamels or nail polish, any cheap brand can be used and will work great as an etch resist.
Properties of Etch Resist
Professionally, probably the most widely used resists are waterproof paints and inks. Water soluble varieties are definitely not fit for purpose simply because these an get dissolved and washed off in the etching solution.
A paint or ink that dries quickly is more advantageous because it eliminates the need to wait for a long time before the board could be etched.
Even the more basic printed circuit patterns appear to have a large quantity of thin copper tracks within a relatively compact area of board nowadays, and a paint brush competent at creating extremely fine lines becomes necessary.
Drawing the Track Layout
A simple solution would be to utilize an worn-out fibre-tip pen in paint brush manner, which can help develop outstanding final results although it might not look like quite a exquisite means to fix the issue. An easier way of implementing the resist is to use one of the commercially available etch resist pens which can be easily bought from any electronic part dealer.
Any kind of pen that uses a spirit based ink and a sharp point should be workable with this application. In case you are uncertain regarding the appropriateness of a pen you can easily pull out a few traces over a discarded copper laminate board then etch the board to verify if the ink maintains the etchant away correctly.
An additional type of resist are the rub-down etch resistant transfers which are available from several component merchants and which often can provide truly outstanding and specialized outcomes as demonstrated in the following example.
Actually you may find that there are lots of chemicals that can be applied as the etchant, but the majority of these are hazardous for some reason or another and are not likely suited to home designed boards.
The Etchant
The etchant is a chemical which reacts with the exposed copper area of the copper laminate and breaks it down from the board. It is used for taking off the copper regions on the board which are not painted by the etch resist and the areas which do not contribute to the track layouts and pads.
The etchant typically employed for home developed boards is ferric chloride, and while this is less hazardous compared to the majority of the choices, it is nevertheless a chemical that needs to be implemented with caution.
This should hence always be rinsed off quickly with running tap water in case you spill any on your skin. Make sure you don’t store ferric chloride in metallic containers, since this chemical is reactive to metals and make the metal porous and cause leakages.
As ferric chloride is toxic (and in in the course of many uses progressively gets transformed into copper chloride which is likewise extremely poisonous) it must obviously be stored far from foodstuff and utensils etc.
Types of Ferric Chloride
Ferric chloride can be obtained in a range of different forms. Probably the most handy type to have is a ready to use solution of the chemical. Many component suppliers market it in such liquid form; typically in 250ml containers and in a concentrated form.
You must dilute it a bit prior to use, as per the given guideline on the bottle. It may not require a great deal of dilution, and a 250ml bottle normally allows only 500ml or a litre after diluting it with water.
Some companies may provide the ferric chloride as crystals, also known as “Ferric Chloride Rock” sometimes. This label is very suitable since in this form it certainly looks like pieces of yellow rock rather then tiny nice crystals, which is pretty much rock solid.
In this type ferric chloride is normally available in 500gm packages, which is enough to generate one litre of etching solution.
You can as well get this in bigger packages, but since 500gm is enough to etch a seriously great number of regular size boards and may easily survive even an diligent constructor a very long time it is most likely not rewarding getting bigger than 500gm pack altogether.
How to Create Ferric Chloride Solution
In crystaline condition ferric chloride is not going to dissolve easily in particular, however when it is stirred steadily it may sooner or later break down completely, and with constant mixing it may melt fairly quickly.
Last but not least, ferric chloride can be acquired in anhydrous form, which basically signifies it’s genuine ferric chloride with virtually no water material. It will possess a slight degree of water in its crystalline form as an aside.
What actually causes this type of ferric chloride so hard to work with is the heating effect that is generated when it is mixed with water. Even if you begin with cooled water it can quickly become quite hot to a level at which the container turns very warm to touch, posing a danger of melting for plastic containers.
One more concern is that of having the chemical to dissolve adequately and create a decent etching formulation. For whatever reason you may find yourself ending up with a large quantity of chemical that will never break down, and also solution which appears like ferric chloride but has very little if any etching potential.
That is why cool water (ideally refrigerated or with ice) must be employed. It is additionally possible that there might be a tiny amount of chemical that won’t melt, which can either be strained from the liquid, or as it does not appear to impede etching it could simply be left in the solution.
Drill Bit Size
The next important ingredient for manufacturing PCB at home is the drill bit, which is required for drilling holes on the PCB for the component leads.
The typical diameter for component lead holes is 1mm, though a number of components like preset resistors, big electrolytic capacitors, etc. demand a bit bigger diameter. A hole diameter of about 1.4mm is appropriate for these kinds of components.
Typically, it is recommended to use a diameter of under 1mm for semiconductors and a number of other components that have thinner leads. 0.7mm or 0.8mm appear to be acceptable diameter for these components.
In case you have access to high quality drill bits they must be pretty tough.
However drill bits of around 0.7mm to 1.4mm in diameter may be quite weak and should be handled relatively carefully.
If they are maintained with downwards straight vertical pressure it may be fine, but if the orientation is not maintained at right angles to the board a proper hole won’t be created which is quite possible that the drill bit will break in two.
You have to for that reason take realistic care while drilling holes using such drill bits, and preferably the machine should be used with a adjustable stand as shown below.
We have so far discussed the key things which are necessary while making a printed circuit board, and there may be some other probabilities and ends which might be essential.
These are typically basic domestic objects though, and these will be unveiled as we advance with the etching course of action. You will find many different methods for manufacturing a printed circuit board.
Despite the fact that all of them are fundamentally the identical and the major dissimilarities are just the sequence through which the different measures along the way are performed.
We are going to hence begin by taking into consideration one approach of manufacturing a board, after which a couple of alternate techniques will be explained.
Getting Started with PCB Making
The very first step would be to check with the book or magazine where the printed circuit is presented in order to get the right dimensions of the board.
You might generally have a circuit schematic, a component overlay diagram, and the printed circuit track pattern reproduced in actual size, as given in the following 3 figures respectively.
The size of the printed circuit should be available in the text or the schematic, however in many instances it will be required to consider the proportions through the real size copper track pattern.
Mark the boundary of the finalized board on the copper side of the laminate board, then pull an additional set of lines approximately 2mm or so on the outer side of the previous marking.
By cautiously cutting between these outlines you should be able to generate a section of board with decent precision and straight edges with minimum issues.
The sides of the board could be smoothed using a small flat file, and with fibre glass board that eliminates the abrasive ends which can be undesirable.
Be aware that the markings should be done on the copper side of the board and sawn from the same side to prevent peeling of the copper while cutting the board. Therefore, make sure to cut, or drill the board always from the copper side, and not from the laminate side
The next step would be to draw the positions of the holes for the components, and wherever suitable, the fitting holes for the board mounting.
The quick method to get this done is to clamp the schematic drawing over the board on the copper track, by accurately aligning the drawing and the board edges.
Then, with a bradawl or similar pointed tool carefully and accurately marking through the schematic onto the board by punching small indentations in the copper.
It is not necessarily essential to mark the board by punching with a pointed tool, and an alternate way is to simply align and stick the drawing to the board using cello tape, and then drill down through the drawing which now itself acts like drilling markers.
Painting the Tracks with Etch Resist
After the board is trimmed to size and all holes drilled, the next task is to paint the board with the etch resist. This basically involves cleansing the board as extensively as you can.
Special cleaning blocks can be obtained from the market and these apparently perform quite nicely. Copper laminate boards may generally show some oxide and corrosion on top of the copper surface, and it is very important to remove this or else this may prevent the board from getting properly etched.
Hence, it is recommended to make use of a reasonably powerful cleaning agent which will perfectly eliminate all oxide, dirt and corrosion from the copper surface.
After the board has been comprehensively washed and the copper layer appears glistening throughout, rinse the board beneath warm water to get rid of any remnants of the cleanser or oily ingredient. At this point make sure not to touch the copper surface, which might otherwise cause greasy finger marks and slow down the etching process.
Next, take the etch resist paint to pull copper pads round the holes drilled for the components leads.
After the pads are drawn with etch resist, it’s time to paint the copper tracks so that they link up the pads as per the circuit design. Always make sure to keep your hands away from the copper surface while doing this. Begin from the board one edge and proceed systematically towards the other edge, instead of doing it randomly (which might likely result in mistakes)
For Complex PCB Designs
Several contemporary printed circuit designs can be extremely sophisticated and challenging to replicate.
While designing a board of this kind it is recommended work with a printed circuit resist pen (or a appropriate alternative) with an even finer nib. In places that may have many narrow, tightly packed parallel tracks, you must take the help of a ruler to allow fine straight lines to be sketched.
If you see the tracks or pads merging with each other, wait for the resist to dry up and then make use of a compass point or other sharp pointed to scratch away the excess overlapping resist.
As soon as the resist has dried out and the PCB is inspected, the next task is to submerge the board in the etchant solution until eventually all the exposed copper has been taken off.
How PCB Etching Happens
Essentially what goes on in the course of etching is that the copper takes the place of the iron in the ferric chloride to form copper chloride, while the iron gets precipitated.
In the beginning etching process happens pretty fast and could take only a few minutes, but as the ferric chloride progressively gets transformed into copper chloride the etching action steadily becomes sluggish, and after several boards are etched it can be observed that the etching time is rather prolonged, or not getting accomplished at all.
In that case the etchant will need to replaced with new batch of ferric chloride solution. As you will notice that Ferric chloride has a red-yellow color while copper chloride is blue in color, so when you find the etching solution slowly getting towards more greenish, will indicate that the chemical is nearing the finish of its working life.
While etching the board at home in a small dish make sure the copper side of the board is facing up and the process is carried out in a non-metallic dish having adequate size.
You may want to add a decent cover on top and periodically remove the cover to check the outcome until etching is over. A main problem with this method is that an iron and copper chloride layer tends to develop on top of the board which may significantly prolong the etching time. This may be countered by carefully rocking the dish from time to time to displace off this layer so that the etching speeds up.
Using Special Containers for Etching
You may actually find it rather easy to set up a container in order to enable the PCB close to a vertical position with the copper side of the board facing downwards.
In this situation etching process happens really fast since iron precipitate is unable to develop a layer and tends to fall downwards away from the board. This ensures that the etching is not hampered. Still , periodic agitation of the board and etchant can help to knock off any small suppressing coating that may develop, enabling even faster etching.
Figure above shows a few easy options for accomplishing this. In Figure (a) a curved dish is employed which ensures that the board is maintained in place through the four corners, and does not come in contact with the dish at any other points.
The technique demonstrated in (b) a good choice for bigger PCBs which may necessitate a rather huge dish to enable the procedure. The container has to be pretty sizeable, anything similar to a classic instant coffee jar would work.
A great deal of etchant will probably be required so as to practically fill up the jar. This might look a bit pricey at first, however the etchant will certainly last proportionately more time compared to a smaller quantity.
Alternatively, a lesser amount of etchant can be diluted with higher amount of water, but this could considerably decelerate etching and is not advisable.
For substantially large boards the only functional method of etching the board could be to employ a big flat dish (like a photographic dish) with the copper side facing upwards. Frequent agitation may be accustomed to speed up the etching time.
Etching will be seen happening faster on areas of where there are smaller regions of open copper, and will take a lot longer on areas of the board where there are relatively wider areas of open copper. Etching also takes place more quickly round the perimeters of the board.
A method which usually works more effectively and is typically far easier in practice is displayed above. Here a pair of wooden or plastic rods are put down the entire length of the dish, on opposite sides. These are relatively longer than the dish to allow them to rest on top. The board is then hung from the rods supported on a couple of wire pieces, one at each end of the board.
Just a single wire is demonstrated in Figure for better understanding. If copper wire is used make sure it is a super Enameled copper wire having a thickness of 18 SWG. The wires are attached to the rods simply by turning the ends round the diameter of the rod once or twice.
After Etching is Over
When etching appears to be complete, you must thoroughly examine the board to make sure that there are no pockets of open copper left, and look for parts of the board where the copper tracks and pads are closely drawn (for example groupings of IC pads).
After you have confirmed that etching is totally accomplished, keep the board vertically over the etching solution for some moments to allow the dripping etchant elope the board, and then wipe the board using a piece of tissue paper or rag.
As an aside, this is a wise decision to maintain a piece of kitchen paper nearby throughout the etching process to ensure that remnants of etching solution could be wiped from the tweezers or gloves whenever needed. The board must be then carefully washed in water to launder away any final leftover traces of etching solution.
Removing the Resist
Finally at the end, the resist sticking on the copper has to be eliminated, that might otherwise seriously impede the soldering process on the copper pads. You can acquire any standard resist remover, and this may be in the form of a light spirit that will break down the majority of paints and inks.
It may be also feasible to obtain printed circuit polishing blocks that happen to be likewise well suited for scrubbing of the resist. One more technique is to try using a scouring pad or powder, and this is basically among the most straightforward activities of printed circuit production which should certainly not present any kind of challenges.
To enable the final assembly of the components on the ready PCB with perfect soldering and absolutely no “dry” joints, the copper tracks and pads must be polished to a glossy finishing before the soldering of the components can be actually commenced.
Over to You
As explained above, apparently making PCB at home looks pretty simple, and it is just a matter of a few hours to create outstanding professional grade PCBs using ready made DIY materials from the market. That said, the process may require some caution and precision for achieving the desired results, so that the intended circuit project is accomplished successfully.
If you have any doubts regarding the topic, please let us now through the comments below, we’ll be most happy to help!
RISC-V is gaining traction and some development boards have already popped up. One of them is the widely available Sipeed Longan Nano. Written information is a bit sparse at the moment. Let’s try to fix this with a quick writeup on wiring and programming the board. If you just want to see what the board can do here is a video instead.
Nuclei SDK
For programming a GD32V series SoC best choice at the moment is the Nuclei SDK. It seems to be well maintained, exceptionally well structured and is quite easy to learn. Developing is done with your favourite text editor.
The SDK supports three different real time operating systems: FreeRTOS, UCOSII and RT-Thread. Since Longan Nano has only 32kB SRAM you might want to stay baremetal instead.
Nuclei SDK does support Longan Nano out of the box. Basic hello world and the Makefile would look like this.
You would compile and upload it with the following commands.
$ make SOC=gd32vf103 BOARD=gd32vf103c_longan_nano all
$ make SOC=gd32vf103 BOARD=gd32vf103c_longan_nano upload
The SDK will take care of basic things such use redirecting STDOUT to USART. This is where the Sipeed USB-JTAG/TTL RISC-V Debugger really pays off. In addition to the JTAG interface it also acts as an USB to TTL converter.
$ screen /dev/ttyUSB1 115200
Nuclei SDK Build Time: Nov 14 2020, 23:17:41
Download Mode: FLASHXIP
CPU Frequency 108540000 Hz
Hello world
Uploading with the Sipeed RISC-V debugger
To make both JTAG and serial interface work you need to connect all pins except NC (duh!) between the debugger and Longan Nano. If nitpicking second ground is also optional. Longan Nano RST is pin number 7 on the left side of the USB socket.
Debugger
Longan Nano
GND
GND
RXD
T0
TXD
R0
NC
GND
GND (optional)
TDI
JTDI
RST
RST
TMS
JTMS
TDO
JTDO
TCK
JTCK
When flashing you also need to connect the USB-C socket to provide power. When using Nuclei SDK you can flash the firmware with make.
$ make SOC=gd32vf103 BOARD=gd32vf103c_longan_nano upload
Uploading with the J-Link debugger
Debugger
Longan Nano
VREF
3v3
GND
GND
TDI
JTDI
RST
RST
TMS
JTMS
TDO
JTDO
TCK
JTCK
You can also use SEGGER J-Link Commander to upload the firmware. The command line utility requires the firmare to be in hex format.
To upload a new firmware manually, first halt the CPU and load the firmware.hex from above. Reset the core and peripherals. Set the program counter to 0x08000000 and finally enable the CPU and exit the command line utility.
If the new firmware does no run automatically you might need to powercycle the board.
While manually poking the internals might be fun it gets bothersome in the long run. You can also put the above commands to an external file and pass it to JLinkExe to do all of the above automatically.
$ cat upload.jlink
halt
loadfile firmware.hex
r
setPC 0x08000000
go
q
If you don’t have an external debugger it is also possible to upload via USB. At the time of writing you need to use latest dfu-util built from source.
$ git clone git://git.code.sf.net/p/dfu-util/dfu-util
$ cd dfu-util
$ ./autogen.sh
$ ./configure --prefix=/opt/dfu-util
$ make -j8 install
Then add /opt/dfu-util/bin to your $PATH and you should be able to flash the firmware via USB.
$ make SOC=gd32vf103 BOARD=gd32vf103c_longan_nano bin
$ dfu-util -d 28e9:0189 -a 0 --dfuse-address 0x08000000:leave -D firmware.bin
Before running dfu-util you need to put the board to download mode. Do this by holding down the BOOT and RESET buttons and then release the BOOT button to enter download mode.
Hello World on Screen
For graphics programming you could use HAGL. As the name implies HAGL is a hardware agnostic graphics library. To make it work with Longan Nano you also need a HAGL GD32V HAL
Writing directly to display is fine for unanimated content. However above code will have a horrible flicker. Problem can be fixed by enabling double buffering in hte Makefile.
COMMON_FLAGS += -DHAGL_HAL_USE_DOUBLE_BUFFER
With double buffering enabled we also need to flush the contents from back buffer to display ie. front buffer. Here I also add some delay to slow down the animation.
This is very naive approach and you need to manually adjust the delay to avoid tearing. It would be better to implement an fps limiter and flush the contents, for example 30 times per second.
A much higher level of randomness can be obtained by observing some aspect of the real physical world, and capturing a noisy signal (“noise” == “random” in physics … sort of).
With an ADC, this is easy to do: leave one ADC input pin floating, and measure its analog voltage. The least-significant bit will be the noisiest, always fluctuating due to electrical noise, e.g. the omni-present thermal brownian motion. If we repeat this 32 times and keep only the lower bit, we should get nicely random results:
ADC<0> adc;
PinA<0> floatingPin;
uint32_t randomNumber () {
uint32_t r = 0;
for (int i = 0; i < 32; ++i)
r = (r << 1) | (adc.read(floatingPin) & 1);
return r;
}
NeuG is an implementatio of True Random Number Generator, based on the sampling noise of ADCs (A/D converters).
It runs on STM32F103, and it outputs random bits at the rate of more than 80 kB/sec (kB = 1000-byte). The interface is USB, and it behaves as a device of communication device class. In GNU/Linux, it runs as /dev/ttyACM0. Note that tty discipline settings should be “raw”.
It is a true RNG, with SHA-256 conditioning component.
NeuG 1.0.3
Signal sources
/|<---+--- [ Analog input Vref ]
16 | |<-+-|--- [ Analog input Temperature Sensor ]
+---/-[ADC1] <==| | | |
| | |<-+ |
+-+ | \|<---+
| |<---+ |
+----| | MUX CTL >--+
| | |<---+
| +-+ | /|
| | 16 | |<------- [ Analog input 0 ] (pull up to Vdd)
| +---/-[ADC2] <==| |
| | |<------- [ Analog input 1 ] (pull up to Vdd)
| \|
| |
| MUX CTL >--+
|
+------------------+ <============ (*1)
|
/ 32
|
| Put 4 times to output 32-bit
V
[ CRC-32 filter ]
|
| Put 35 times to output 1120-bit
+---------------------------------+ <====== (*2)
|
/ 32
|
V
[ Entropy Buffer ]
|
+--------------+ |
| | |
| Conditioning | 1120 |
| Component |<------------/------------+
| |
+-----| Hash_df |
| | by |
| | SHA-256 |
| | | 128
| | |<--/--+
| +--------------+ |
| |
+---------------------------+
|
/ 256
|
v
Random Number Output <========== (*3)
STM32F103 has two built-in A/D converters. NeuG uses A/D converters’ outputs as entropy sources. It is considered noise of quantization error, plus noise from power supply, etc.
We chose four analog input sources of: built-in voltage reference, temperature sensor and two analog inputs which are pull-up to Vdd.
Note that those signal sources are arbitrary and doesn’t matter. It is sampling itself, which gives us the entropy.
By a single sampling of two channels, we get 32-bit (not all 32-bit is valid, as a A/D converter resolution is 12-bit only). We take four sampling of combinations: (Vref, IN0), (Temp, IN1), (Vref, IN1), and (Temp, IN0). Those 32-bit * 4 is fed into CRC32 filter.
We use STM32F103’s CRC32 calculation unit as a kind of filter. We put output of A/D converters into CRC32 calculation unit, four times, to get 4-byte output. This is done because computation of SHA-256 is expensive if the sequence is too long.
Output of CRC32 filter is collected 35 times, and it becomes 1120-bit (32 * 35). This is the noise source bits.
We put this 1120-bit and half of previous output (128-bit) to conditioning component.
Conditioning Component is implemented by Hash_df function which is composed by SHA-256. Since the noise source is not “white”, signal is whiten by this Conditioning Component.
A Little History of NeuG
NeuG 1.0.3
Upgrade of Chopstx and Fraucheky.
NeuG 1.0.2
Upgrade of Chopstx. Firmware upgrade process change.
NeuG 1.0.1
Upgrade of Chopstx and Fraucheky. Optimization change.
NeuG 1.0
Chopstx’s bug fix for interrupt handling, introducing Fraucheky, the GNU GPL container.
NeuG 0.11
Use its own thread library, Chopstx. Improve the speed by tweaking health tests.
NeuG 0.06
Use its own USB stack (same as newer Gnuk).
NeuG 0.05
Improve speed of SHA256 hash function. As a whole, the speed of random number generation increases 2%.
NeuG 0.04
Improve speed when NeuG device is connected to full-speed hub. If it’s not full-size frame (== 64-byte), full-speed host submits a frame to device once per 1ms frame.
Run health tests for CRC-32 filtered output mode, too. It results slower generation speed for the mode though.
NeuG 0.03
In September 2012, Seth Schoen kindly informed me about the draft of NIST SP 800-90B.
It requires a device to have certified “conditioning component” to be full entropy source.
Thus, my journey to seek good “conditioning component” finished at this point. I decided to use hash_df function by SHA-256 for “conditioning component”.
I concentrate other points than conditioning component, such as use of ADC2, to get more performance.
NeuG 0.02
I was not satisfied about the performance of NeuG 0.01 and was not sure the quality of its output (although I tested the output of NeuG 0.01 by Dieharder 3.31 and NIST STS 2.1.1 extensively).
I played a bit with NeuG after release of Gnuk 1.0, and replaced NeuG’s component from CRC16 buffer to the WELL RNG structure in NeuG 0.02, as it looked better.
NeuG 0.01 and Gnuk 1.0
Then, I implemented NeuG 0.01 which uses CRC16 buffer to whiten noise source.
Gnuk (as of version 1.0) uses the routine of NeuG 0.01.
Initial Idea of NeuG
While developing Gnuk, I need good random number generator. Gnuk needs good random number generator for data encryption key to encrypt private keys (of RSA).
Early days, Gnuk didn’t have random number generator, and it required random bits to be stored into its flash ROM. It required its user to put output of /dev/random into there.
FRITZING IS STILL FREE! (HOW TO BUILD FROM SOURCE)
Want the latest version of Fritzing for free? This tutorial will teach you how to build the latest version of Fritzing from source code, which is still freely available from Github.
So what is building Fritzing from source anyway? Fritzing used to be a free to download community driven project but at some stage they introduced an enforced donation for downloading the appliction.
However the source code still remains available to download at no cost, so we can use some freely available tools to turn the source code into a working application. Fritzing can still be free!
Setting up the tools for building Fritzing can be a little bit challenging but we will walk through it step-by-step. Once you have completed the first build, you will be able to quickly build new versions in the future so it is worth spending the time.
In order to build Fritzing you are going to need the latest version of Qt Creator. You can download it for free using the online installer.
Windows users choose MinGW or msvcXX OpenGL and the latest version of Visual Studio. The latter is recommended in the official build guide.
Mac users choose clang 64-bit
Windows users will also need Visual Studio for building Fritzing.
Download source code and dependencies
Whilst you download Qt Creator we can prepare the other required files. Go ahead and create a fresh directory called fritzing in a memorable location on your hard drive. I will be using Mac terminal, Windows users should use their native file structure (e.g. c:/fritzing)
mkdir ~/fritzing
cd ~/fritzing
Download Fritzing source
Now we need to download the Fritzing source code from Github. You can either download the .zip file from the Fritzing Github or use the command line with the git command if you have it installed.
Download the Fritzing app and extract it to your newly created Fritzing folder. Alternatively use the git command from within the fritzing folder.
Download the Fritzing parts library and extract it to your newly created fritzing folder. Alternatively use the git command from within the fritzing folder.
Mac users will probably want to download the .tar.gz version and Windows users will probably want to download the .zip version. However either will be ok so long as you have the tools to extract them.
Install cmake
Mac
If you don’t already have Homebrew installed, go ahead and open terminal and enter the following command.
Go ahead and download version 0.28.x of libgit2 from the Github releases page. Extract it into your fritzing directory and change the folder name to libgit2.
We will need to build libgit2 using cmake so go ahead and enter the following commands, substituting your chosen path for the fritzing folder.
cd ~/fritzing/libgit2
mkdir build
cd build
cmake -DBUILD_SHARED_LIBS=OFF ..
cmake --build .
Running Fritzing
Now that we have downloaded all of the dependencies, you should have a folder containing the following.
fritzing-app directory
fritzing-parts directory
libgit2 directory
boost_x_x_x directory
Setup Qt Creator
Once you have installed Qt Creator, go ahead and open fritzing-app/phoenix.pro located in the fritzing-app directory.
Open Fritzing in Qt Creator
This file will open in Qt Creator studio. If everything is configured correctly you should see some messages that state that libgit2 and boost have been found. Go ahead and click projects from the left-hand menu.
Add the first run command line argument
Next click run from the left-hand menu. We need to enter the following command line arguments, replacing the path for the path that you have chosen to locate the folders.
Once you have entered the command line argument go ahead and click the run button at the bottom of the left-hand menu. It will take a moment to build and then the Fritzing app should load for the first time. Awesome!
Add the subsequent command line argument
Once you are on the main Fritzing screen, go ahead and close the app. Then change the command line argument to the following.
Qt Creator is now configured so you can go ahead and save the project. You can continue to use Fritzing via Qt Creator, however it is also possible to build an app.
Building Fritzing
Now we are ready to build a binary for Fritzing. This will give us a nice executable application that will run without the need for Qt Creator.
Build for Windows
Windows users will need to install Visual Studio in order to build Fritzing.
First we need to locate the file release_fritzing.bat stored in the fritzing-app/tools folder. Go ahead and open it your favorite text editor, Notepad will suffice if you don’t have a code editor.
You may or may not need to change the QTBIN directory for 64-bit builds. This directory should contain the qmake.exe file. If you edit the file path go ahead and save the file.
Next we need to open up a Visual Studio command prompt. This can be found on the Start menu under All Programs > Microsoft Visual Studio > Visual Studio Tools > Developer Command Prompt.
Simply drag and drop the release_fritzing.bat on to the command prompt and allow the compilation to occur, it may take a while. On completion you will have your very own completely free and fully functioning Fritzing program named fritzing.<version>.pc.zip and located in the releases folder. Awesome!
Build for Mac
Go ahead and open fritzing-app/phoenix.pro with your favorite text editor. Locate the line CONFIG += x86_64 and make sure the x86 ppc is commented out (it should have a # symbol before it like in the screenshot). If you need to amend it go ahead and save it afterwards.
Next we need to check the path in the deploy_fritzing_mac.sh file located in fritzing-app/tools. Go ahead and open it in your favorite text editor and check that the QTBIN path contains the qmake file. Change the path if necessary and save the file.
Now simply run the script to build Fritzing. You can do this from the terminal with the following command, using the path that you chose.
Once the script has finished building Fritzing, you should find the Fritzing app located in /fritzing/deploy-app. Awesome!
Conclusion
It takes a little work to setup the necessary tools for building Fritzing, however once you have successfully been able to build the app you will have your very own Fritzing binary, free to use forever!
If you ran into problems then it might be worth donating to the project as it is only a small amount that they ask for, and download the pre-compiled version.
Now that you have Fritzing installed, why not go check out some of my other awesome Arduino, ESP device or Raspberry Pi tutorials!
I was recommended to use black magic probe (BMP) to flash / debug STM32 chips by friends from base48 hackersapce, so I searched the internet and found that there are several articles describing this procedure, such as:
Looks simple: get sources, compile, flash, but it was not so easy and straightforward as it seemed, here are some of the problems I experienced:
as a BMP I was using a clone of STM32F103C8T6: a CS32F103C8T6; I was unable to flash it with ST-LINK
when I make ST-LINK able to flash it I found that BMP compiled is >64kB and these chips refuses to flash more than 64kB (real STM32F103C8T6 are reported to be 128kB even datasheet says 64kB) – tried with ST-LINK and also tried to flash DFU first and then use it to flash the rest – both failed as 64kB reached
I wanted to use swlink pins already soldered on the bluepill board, so you dont need to solder anything to be able to use BMP as a debugger, but all articles were talking about different pins (PA5, PB14 instead of PA13, PA14)
my STM becomes locked showing 0kB of flash, I was unable to erase it or flash it – unlock via openOCD fixed this
articles above reccomends you to flash dfu bootloader first (blackmagic_dfu.bin), then connect bluepill via USB and flash the rest (blackmagic.bin) using dfu-util – this was not possible as dfu-util detected that firmware is bigger than reported flash size and refused to start flashing – see Announced versus available Flash size on F103
This article assumes that you have build tools for STM32 already installed, also as git, st-link utility (st-flash), etc…
CS32F103C8T6 clone
The problem why ST-LINK refuses to flash is the fact that this clone is reporting different coreid (0x2ba01477 instead of 0x1ba01477), you can fix this by change of STM32VL_CORE_ID constant in ST-LINK sources (include/stm32.h) and recompile, but even if you supply –flash=0x20000 parametter to force 128kB flash it starts flashing but fail at about 60-70% – it seems that this chip have 64kB of flash only.
Also I had problems to run Arduino LiquidCrystal_PCF8574 library example on this chip – the LCD was never properly initialized, it flashed on reset of bluepill (so there was some communication happening), but never showed any text – I suspect timing problems.
Fortunatelly I have only 2 such boards using this CS chip and about 10 others with STM chip (bought from different chinesse seller, not sure they are 100% genuie but at least works), so I decided to stop wasting time trying to use this CS clone as it is reported as unreliable and I took different bluepill with STM chip.
If you modified the ST-LINK sources to be able to flash CS chip don’t forget to revert changes and recompile, otherwise it will refuse to flash “real” STM chips.
How to unlock chip showing 0 flash size
In case you bluepill wiil become locked and refuse to erase / flash, try these steps to unlock it:
install openocd (sudo apt install openocd)
move the BOOT0 jumper to position “1”
connect locked bluepill to ST-LINK (3V3 to 3V3, SWIO to SWIO, SWCLK to SWCLK, GND to GND)
Open On-Chip Debugger 0.9.0 (2018-01-24-01:05)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
none separate
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : clock speed 950 kHz
Info : STLINK v2 JTAG v17 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.279947
Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0xa1000000 pc: 0x1ffff3b6 msp: 0x200000c4
Info : device id = 0x20036410
Info : flash size = 64kbytes
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000003a msp: 0x200000c4
stm32x unlocked.
INFO: a reset or power cycle is required for the new settings to take effect.
shutdown command invoked
disconnect power for a short time or press reset button on the bluepill
don’t forget to move the BOOT0 jumper back to “0” position
Black magic probe for bluepill
connect the bluepill to the ST-LINK (3V3 to 3V3, SWIO to SWIO, SWCLK to SWCLK, GND to GND)
connect ST-LINK to the PC
execute following sequence – please note the “PROBE_HOST=swlink” which is not a typo – as amost all articles recommend you to use “PROBE_HOST=stlink” (with “t”), but the “swlink” option cause that the SWIO / SWCLK pins are mapped to the default SWIO / SWCLK pins which are already soldered on the blupill board by default – so you don’t need to solder pins to be able to use debugger, and this also makes life easier as these pins are already labeled as SWIO / SWCLK (also swlink is recommended option for bluepill in blackmagic wiki, dunno why all others ignore this)
$ git clone https://github.com/blacksphere/blackmagic.git
... progress of git ...
$ cd blackmagic
$ make PROBE_HOST=swlink
... progress of make ...
$ ll | grep blackmagic
-rwxrwxr-x 1 buger buger 1030380 dub 5 10:04 blackmagic*
-rwxrwxr-x 1 buger buger 73244 dub 5 10:04 blackmagic.bin*
-rwxrwxr-x 1 buger buger 345604 dub 5 10:04 blackmagic_dfu*
-rwxrwxr-x 1 buger buger 7348 dub 5 10:04 blackmagic_dfu.bin*
-rw-rw-r-- 1 buger buger 20727 dub 5 10:04 blackmagic_dfu.hex
$ st-flash erase
st-flash 1.5.1-22-g4ff515e-dirty
2019-04-05T10:11:45 INFO usb.c: -- exit_dfu_mode
2019-04-05T10:11:45 INFO common.c: Loading device parameters....
2019-04-05T10:11:45 INFO common.c: Device connected is: F1 Medium-density device, id 0x20036410
2019-04-05T10:11:45 INFO common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x10000 bytes (64 KiB) in pages of 1024 bytes
Mass erasing
$ st-flash write blackmagic_dfu.bin 0x8000000
st-flash 1.5.1-22-g4ff515e-dirty
2019-04-05T10:16:09 INFO common.c: Loading device parameters....
2019-04-05T10:16:09 INFO common.c: Device connected is: F1 Medium-density device, id 0x20036410
2019-04-05T10:16:09 INFO common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x10000 bytes (64 KiB) in pages of 1024 bytes
2019-04-05T10:16:09 INFO common.c: Attempting to write 7348 (0x1cb4) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08001c00 erased
2019-04-05T10:16:10 INFO common.c: Finished erasing 8 pages of 1024 (0x400) bytes
2019-04-05T10:16:10 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL core id
2019-04-05T10:16:10 INFO flash_loader.c: Successfully loaded flash loader in sram
8/8 pages written
2019-04-05T10:16:10 INFO common.c: Starting verification of write complete
2019-04-05T10:16:10 INFO common.c: Flash written and verified! jolly good!
$ st-flash --flash=0x20000 write blackmagic.bin 0x8002000
st-flash 1.5.1-22-g4ff515e-dirty
2019-04-05T10:33:21 INFO common.c: Loading device parameters....
2019-04-05T10:33:21 INFO common.c: Device connected is: F1 Medium-density device, id 0x20036410
2019-04-05T10:33:21 INFO common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x10000 bytes (64 KiB) in pages of 1024 bytes
Forcing flash size: --flash=0x00020000
2019-04-05T10:33:21 INFO common.c: Attempting to write 73244 (0x11e1c) bytes to stm32 address: 134225920 (0x8002000)
Flash page at addr: 0x08013c00 erased
2019-04-05T10:33:23 INFO common.c: Finished erasing 72 pages of 1024 (0x400) bytes
2019-04-05T10:33:23 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL core id
2019-04-05T10:33:23 INFO flash_loader.c: Successfully loaded flash loader in sram
72/72 pages written
2019-04-05T10:33:27 INFO common.c: Starting verification of write complete
2019-04-05T10:33:29 INFO common.c: Flash written and verified! jolly good!
Try to switch BOOT0 jumper to “1” in case that ST-LINK refuse to communicate with the bluepill.
Test it!
make sure both BOOT jumpers are in 0 position
disconnect ST-LINK
conenct bluepill to the PC using uUSB cable
use lsusb command to check that USB device “ID 1d50:6018 OpenMoko, Inc” is present
check that two serial ports are created /dev/ttyACM0 (for debugging) and /dev/ttyACM1 (for serial)
now you have your own BMP!
Try to flash blink from Arduino to another bluepill
connect second bluepill to your BMP (5V to 5V, SWIO to SWIO, SWCLK to SWCLK, GND to GND)
install / open Arduino and make sure that “Generic STM32F103C series” board is selected
open blink exmple (“File” -> “Examples” -> “Basics” -> “Blink”)
menu “Tools” -> “Upload method” -> “BMP”
menu “Tools” -> “Port” -> “/dev/ttyACM0”
upload the sketch, output in arduino should look like
Sketch uses 17044 bytes (26%) of program storage space. Maximum is 65536 bytes.
Global variables use 2576 bytes (12%) of dynamic memory, leaving 17904 bytes for local variables. Maximum is 20480 bytes.
Target voltage: ABSENT!
Available Targets:
No. Att Driver
1 STM32F1 medium density
blink should be running = LED blinking
Flash oved gdb and run the code
connect second bluepill to your BMP (5V to 5V, SWIO to SWIO, SWCLK to SWCLK, GND to GND)
compile miniblink example from libopencm3 and run gdb
$ git clone https://github.com/libopencm3/libopencm3-miniblink
Cloning into 'libopencm3-miniblink'...
remote: Enumerating objects: 154, done.
remote: Total 154 (delta 0), reused 0 (delta 0), pack-reused 154
Receiving objects: 100% (154/154), 26.15 KiB | 0 bytes/s, done.
Resolving deltas: 100% (89/89), done.
Checking connectivity... done.
$ cd libopencm3-miniblink/
$ make
... progress of make ...
$ cd bin/stm32
$ ll | grep bluepill
-rwxrwxr-x 1 buger buger 1040 dub 5 11:31 bluepill.bin*
-rwxrwxr-x 1 buger buger 213272 dub 5 11:31 bluepill.elf*
-rw-rw-r-- 1 buger buger 2976 dub 5 11:31 bluepill.hex
$ arm-none-eabi-gdb -ex "target extended-remote /dev/ttyACM0"
GNU gdb (7.10-1ubuntu3+9) 7.10
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-linux-gnu --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
Remote debugging using /dev/ttyACM0
(gdb)
in gdb try to scan for the connected target:
(gdb) monitor swdp_scan
Target voltage: ABSENT!
Available Targets:
No. Att Driver
1 STM32F1 medium density
attach the target
(gdb) attach 1
Attaching to Remote target
0x08000176 in ?? ()
load the debug binary
(gdb) file bluepill.elf
A program is being debugged already.
Are you sure you want to change the file? (y or n) y
Reading symbols from bluepill.elf...done.
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/jdrozd/temp/bmpa/libopencm3-miniblink/bin/stm32/bluepill.elf
use CTRL+C to stop the program
^C
Program received signal SIGINT, Interrupt.
main () at template_stm32.c:19
19 __asm__("nop");
... led stops blinking now ...
continue the program
(gdb) continue
Continuing.
... led continues to blink again ...
use help command, “Useful GDB commands” from blackmagic wiki and google to find out more gdb commands
use quit command to quit gdb
Test the BMP serial
connect second bluepill to your BMP (5V to 5V, SWIO to SWIO, SWCLK to SWCLK, GND to GND)
connect also PB6 of BMP to PA10 of the second bluepill (TX-RX)
connact also PB7 of BMP to PA9 of the second bluepill (RX-TX)
we will use libopencm3-examples, lets prepare them
$ git clone https://github.com/libopencm3/libopencm3-examples.git
... progress of git ...
$ cd libopencm3-examples/
$ git submodule init
Submodule 'libopencm3' (https://github.com/libopencm3/libopencm3.git) registered for path 'libopencm3'
$ git submodule update
Cloning into 'libopencm3'...
remote: Enumerating objects: 1, done.
remote: Counting objects: 100% (1/1), done.
remote: Total 25049 (delta 0), reused 0 (delta 0), pack-reused 25048
Receiving objects: 100% (25049/25049), 5.49 MiB | 2.11 MiB/s, done.
Resolving deltas: 100% (16441/16441), done.
Checking connectivity... done.
Submodule path 'libopencm3': checked out 'ff9664389bfb560145aa3b36ad8368900c57c3d8'
$ make
... progress of make, very long ...
$ cd examples/stm32/f1/stm32-h103/usart_printf/
open file usart_printf.c in text editor
search for “usart_set_baudrate(USART1, 230400);” and replace 230400 with 9600
replace all “GPIO12” with “GPIO13”
save the file and close text editor
$ make clean
$ make
... progress of make, very quick ...
$ arm-none-eabi-gdb -ex "target extended-remote /dev/ttyACM0"
GNU gdb (7.10-1ubuntu3+9) 7.10
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-linux-gnu --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
Remote debugging using /dev/ttyACM0
0x08000588 in ?? ()
(gdb) file usart_printf.elf
A program is being debugged already.
Are you sure you want to change the file? (y or n) y
Reading symbols from usart_printf.elf...done.
(gdb) attach 1
A program is being debugged already. Kill it? (y or n) y
Attaching to program: /home/jdrozd/projects/stm32f103/libopencm3-examples/examples/stm32/f1/stm32-h103/usart_printf/usart_printf.elf, Remote target
0x080005c6 in reset_handler () at ../../cm3/vector.c:67
67 for (src = &_data_loadaddr, dest = &_data;
(gdb) load
Loading section .text, size 0x5de8 lma 0x8000000
Loading section .ARM.exidx, size 0x8 lma 0x8005de8
Loading section .data, size 0x8ac lma 0x8005df0
Start address 0x80005c0, load size 26268
Transfer rate: 17 KB/sec, 905 bytes/write.
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/jdrozd/projects/stm32f103/libopencm3-examples/examples/stm32/f1/stm32-h103/usart_printf/usart_printf.elf
now the LED on the target should blink quicky
open new terminal (keep the terminal with gdb opened in background)
execute command “screen /dev/ttyACM1 9600” in the new terminal, you should see incomming “Hello world!” messages with some increasing numbers, like thoose:
the LED should stop blinking and “Hello world” messagess should stop also
type “continue” and press enter in gdb terminal – LED blinks and messages should start again, notice that numbers in the messages are NOT counting from 0 again but continues from where the program was interrupted
Used SW / HW / Links:
Ubuntu Mate 16.04
ST-LINKv2 – chinesse clone from aliexpress
bluepill modules (aka STM32F103C8 Minimum System Development Board) also from aliexpress
Rust embedded software tooling is always an interesting alternative to MCU vendor specific IDE software, such as those provided by TI, Microchip, STM32, Nordic, etc.
With the advent of probe-rs and subsequently probe-run software, Rust for embedded coding can take a different path from openocd + gdb, and it is getting more convenient.
There are already lots of cortex-m quick-start guides, especially of STM32F103 “Blue Pill”. Unfortunately, Rust library such as stm32f1xx_hal is changing fast. For example, the Timer now is initiated differently from the past.
Here is my latest try get it up and running:
get hardware: STM32F103C8T6 module + ST-link (v2) debugger
setup software: follow this link or stm32f1xx_hal (link) and use cargo install probe-run (link) instead of cargo install cargo-flash
We flash test_program.bin onto the ARM Cortex M3 using OpenOcd.
Connect to the openocd server using telnet in another command window
$ telnet localhost 4444
Halt execution of target in case it is running
reset halt
Erase content on flash
stm32f1x mass_erase 0
Flash test_program.bin
flash write_bank 0 test_program.bin 0
Run program but halt directly so that we can control the execution via the debugger (gdb)
reset halt
Debugging
Run gdb using our test program and connect to the openocd server on port 3333. We use the GDB TUI (Text User Interface) as described in Use GDB on an ARM assembly program.
《黑天鹅》的作者塔勒布，写的另外一本书的中文书名是《非对称风险》，英文名是Skin in The Game，根据这本书的内容，我觉得中文书名应该改为《躬身入局》。当你在一个游戏中用自己的皮肤来测量温度时，才会有切肤之痛或爽肤之快，置身游戏之外，不承担任何损益的人，无法获得真正的知识和经验。回顾我来多伦多10年多的投资历程，各类损失和遗憾不胜枚举，但这些学费交的太值了，让我的皮肤/skin充分领略了投资这个游戏/game的冷暖,试错成本就是投资损失，能力边界就是通过试错拓展出来的，但试错需要勇气和行动，需要躬身入局。网上有一段话，应该是一位躬身入局的人写的“不要羡慕那些比你好的人，别人只是每一分钟都在做你不敢做的事，吃了你不想吃的苦，说了你不好意思说的话，认识了你没有勇气认识的人，坚持了你放弃的事情。”把这段实践者的总结送给大家共勉：不要做个只会抖机灵、动嘴巴的“精明人”；自崩“精明人”的人设，做个敢于行动、尝试和犯错，相信实践出真知的“笨蛋”吧。
过去10年，银行的父母不断要求银行收紧房贷政策，银行也自发地改变了一些贷款政策。例如，已往，小业主，公司成立3年以内，个人收入低的情况下，首付35%，可以通过Stated Income program，获得房贷，目前，这个项目被所有银行都取消了，因为所谓的stated income 其实就是未来收入，或假收入，无法证实。以往，给新移民和非居民的贷款政策过于宽松，现在银行坚决杜绝了给出示海外收入买投资房的机会，只能购买自住房，而且海外收入的验证方式也越来越严格和严肃，基本上排出了利用新移民政策投资房地产的可能性，新移民政策只适用于自住房贷款。总之，银行对未报税的收入容忍度越来越低。不过，各家银行在最近两年对高净值资产客户的贷款审批可以出现了优惠性倾斜，高净值申请人可以加按已有房产，也可以贷款买投资房。
$ gem install jekyll bundler
gem install jekyll bundler
ERROR: While executing gem ... (Gem::FilePermissionError)
You don't have write permissions for the /Library/Ruby/Gems/2.6.0 directory.
$ gem install jekyll bundler --user-install
WARNING: You don't have /Users/wayongliu/.gem/ruby/2.6.0/bin in your PATH,
gem executables will not run.
Building native extensions. This could take a while...
ERROR: Error installing jekyll:
ERROR: Failed to build gem native extension.
…
$ set PATH "`ruby -e 'puts Gem.user_dir'`/bin:$PATH"
或者添加如下命令到 shell 配置文件中：
set -gx PATH ~/.gem/ruby/2.6.0/bin $PATH
重装 Ruby
如果仍然不行，可以尝试使用 brew 重装 Ruby，抛弃 mac 自带的版本。安装过程输出的信息会有如下提示：
By default, binaries installed by gem will be placed into:
/usr/local/lib/ruby/gems/2.7.0/bin
You may want to add this to your PATH.
ruby is keg-only, which means it was not symlinked into /usr/local,
because macOS already provides this software and installing another version in
parallel can cause all kinds of trouble.
If you need to have ruby first in your PATH run:
echo 'set -g fish_user_paths "/usr/local/opt/ruby/bin" $fish_user_paths' >> ~/.config/fish/config.fish
For compilers to find ruby you may need to set:
set -gx LDFLAGS "-L/usr/local/opt/ruby/lib"
set -gx CPPFLAGS "-I/usr/local/opt/ruby/include"
For pkg-config to find ruby you may need to set:
set -gx PKG_CONFIG_PATH "/usr/local/opt/ruby/lib/pkgconfig"
