-As a check, let’s change the link script to nokeep.ld in Makefile +As a check, let's change the link script to nokeep.ld in Makefile and generate an executable .elf from the empty source code file empty.c: @@ -92,7 +92,7 @@ rm empty.o The linker gives a warning and fallback on a default address as entry point.
-So let’s create boot.c with an idle loop as Reset_Handler: +So let's create boot.c with an idle loop as Reset_Handler:
void Reset_Handler( void) {
for( ;;) ;
diff --git a/docs/13_flash.html b/docs/13_flash.html
index e9602ea..398de65 100644
--- a/docs/13_flash.html
+++ b/docs/13_flash.html
@@ -2,11 +2,11 @@
- 1.3 Flash – Boot – Debug
+ 1.3 Flash - Boot - Debug
-1.3 Flash – Boot – Debug
+1.3 Flash - Boot - Debug
Now that I have an executable bootstrap, I need to flash an actual board
with it to check if it works as expected. On a member of the STM32F030
@@ -48,7 +48,7 @@ Referenced as
STM32CubeProg
on STMicroelectronics website, the STM32 Cube Programmer comes with USB
-drivers and a firmware upgrade utility for the ST-Link. It’s a java
+drivers and a firmware upgrade utility for the ST-Link. It's a java
based application with available distribution for Win32, Win64, Mac and Linux.
There are regular updates to support the latest chipsets. I am currently
using version v2.17.0.
diff --git a/docs/15_blink.html b/docs/15_blink.html
index 55311e2..4db42a4 100644
--- a/docs/15_blink.html
+++ b/docs/15_blink.html
@@ -88,7 +88,7 @@ through the frames gives me a better estimation.
Checkpoint
-This is just a small increment on my previous step, but that’s iterative
+This is just a small increment on my previous step, but that's iterative
development in a nutshell. Also I didn't come with a reasonable value
for the delay counter at first, it's easy to underestimate how fast
micro-controllers are.
diff --git a/docs/16_ledtick.html b/docs/16_ledtick.html
index a2d57a5..bdccd3c 100644
--- a/docs/16_ledtick.html
+++ b/docs/16_ledtick.html
@@ -8,12 +8,12 @@
1.6 The Tick
-
+
In previous iteration, I made the user LED blink using an active delay
loop. I have two issues with this implementation:
-
-
- It’s hard to control the delay timing accurately +
- It's hard to control the delay timing accurately
- Active loops are not cool
- Introduce the SysTick core peripheral to the compiler, using pre-processor macroes to give the location of SysTick registers. As this -is a core peripheral, it’s in a different address space than the +is a core peripheral, it's in a different address space than the peripherals I have seen so far.
- Start the Reset_Handler by initializing and enabling the System
@@ -126,7 +126,7 @@ void SysTick_Handler( void) {
}
-I didn’t initialize the GPIO B before enabling the SysTick as I have a
+I didn't initialize the GPIO B before enabling the SysTick as I have a
whole second before the first interrupt will tick in.
Build is straightforward. diff --git a/docs/17_cstartup.html b/docs/17_cstartup.html index 66fd5b8..d18c6a1 100644 --- a/docs/17_cstartup.html +++ b/docs/17_cstartup.html @@ -205,8 +205,8 @@ If I look further in the cstartup.map generated by the linker.
-
iis located in .bss at 0x20000008 - -
cis not listed as it doesn’t have global scope, but I can -guess it’s located at 0x20000000. + -
cis not listed as it doesn't have global scope, but I can +guess it's located at 0x20000000. - Initial values for the .data section are located at 0x0800007c.
Once f030f4.hex is loaded into the board, the behavior is the same
as ledtick.hex. The new file structure and data initialization
-didn’t introduce any bugs changes, just code overhead.
+didn't introduce any bugs changes, just code overhead.
Checkpoint
diff --git a/docs/21_uart.html b/docs/21_uart.html index 15852c2..521a177 100644 --- a/docs/21_uart.html +++ b/docs/21_uart.html @@ -15,13 +15,13 @@ to validate that I have working hardware and software tools.Board Connectivity
Even if the peripheral is capable of doing synchronous communication -(that’s the S in USART), asynchronous communication (that’s the A) which +(that's the S in USART), asynchronous communication (that’s the A) which only needs 3 wires (GND, TX, RX, (no clock)) is usually what is needed in non specialized cases.Boards sold online often have dedicated pre-soldered pins for UART connectivity similar to what I have seen before for the SWD interface. -The VCC-GND board I used previously doesn’t have such dedicated pins but the +The VCC-GND board I used previously doesn't have such dedicated pins but the functionality is wired on the pins PA9 (TX) and PA10 (RX).
I will use a board with dedicated pins (GND, TX, RX, VCC 3.3V). Board
diff --git a/docs/22_board.html b/docs/22_board.html
index edab313..0efee05 100644
--- a/docs/22_board.html
+++ b/docs/22_board.html
@@ -58,7 +58,7 @@ refer directly to GPIO( LED_IOP)[ MODER].
I use conditional compilation based on LED_ON. If
LED_ON is high, I need an extra step during initialization
compare to LED_ON low. On the other hand, if LED_ON
-is undefined, the code would be removed for a board that doesn’t have a user
+is undefined, the code would be removed for a board that doesn't have a user
LED.
diff --git a/docs/23_hello.html b/docs/23_hello.html index b516ffe..8ddd7df 100644 --- a/docs/23_hello.html +++ b/docs/23_hello.html @@ -8,7 +8,7 @@2.3 Hello There!
-Looking for a “you had me at hello” moment? Let’s see how serial +Looking for a “you had me at hello” moment? Let's see how serial transmission works for you.Implementation
@@ -55,11 +55,11 @@ To check if it is ready for transmission you must check the state of the TX Empty (TXE) bit in the Interrupt & Status Register (ISR).I write a basic
kputc()function that does busy waiting if the -TDR is not empty and insures that LF are mapped to CR LF. The ‘k’ in -kputc refer to ‘kernel’, as kputc is a low level function that will be used +TDR is not empty and insures that LF are mapped to CR LF. The 'k' in +kputc refer to 'kernel', as kputc is a low level function that will be used mostly for debugging. With the busy wait and the recursive code this -implementation is definitively not optimal, but it’s functional and -that’s what matter most at this stage. +implementation is definitively not optimal, but it's functional and +that's what matter most at this stage.void kputc( unsigned char c) { @@ -131,8 +131,8 @@ as usual but I can see the RX LED on the USB to UART adapter flash briefly when I release the reset button.-Build on Linux doesn’t show any warnings. +Build on Linux doesn't show any warnings.On Windows PC, if I use PuTTY or Arduino IDE to open COM4 at 9600 -baud, every time I press and release the reset button I can see ‘hello, -world’ displayed on a new line in the terminal window. +baud, every time I press and release the reset button I can see 'hello, world' +displayed on a new line in the terminal window.
On Linux, when I plug in the USB to UART adapter, it enumerates as /dev/ttyUSB0, so it is compatible with the USB driver for serial @@ -144,7 +144,7 @@ writing. Once added to dialout, I can open /dev/ttyUSB0 at 9600 baud in Arduino IDE, each time I press and release the board RESET button, I can see -‘hello, world’ displayed on a new line in the Serial Monitor window. +'hello, world' displayed on a new line in the Serial Monitor window.
Checkpoint
diff --git a/docs/24_stm32flash.html b/docs/24_stm32flash.html index 306d6a8..b071a23 100644 --- a/docs/24_stm32flash.html +++ b/docs/24_stm32flash.html @@ -33,7 +33,7 @@ Receiving objects: 100% (1357/1357), 1.04 MiB | 74.00 KiB/s, done. Resolving deltas: 100% (912/912), done.$ cd stm32flash-code @@ -130,7 +130,7 @@ case COM4 instead of /dev/ttyUSB0. There is several other Windows applications available on ST.com for flashing STM32 chipsets: STM32 ST-Link Utility, STM32 Flash Loader Demonstrator, ST Visual Programmer STM32. They have been marked as NRND -(Not Recommended for New Design), which means they won’t support latest +(Not Recommended for New Design), which means they won't support latest chipsets as they are replaced by STM32 Cube Programmer.Next, I will write an application which make diff --git a/docs/26_uptime.html b/docs/26_uptime.html index c50ee50..3d95256 100644 --- a/docs/26_uptime.html +++ b/docs/26_uptime.html @@ -8,7 +8,7 @@
2.6 uptime
-It’s time to throw away the prototype and write a production version of +It's time to throw away the prototype and write a production version ofuptime. There is several things I want to straighten up in uptime.1.c:
-
@@ -50,13 +50,13 @@ Next, I make a revision of uplow.1.c by making a copy into
I include system.h which is the interface that uplow.2.c
implements. I will have several implementations of the same interface,
so system.h is not just the interface published by uplow.2.c,
-it’s uplow.2.c which is an implementation of system.h.
+it's uplow.2.c which is an implementation of system.h.
#include "system.h" /* implements system.h */-I extract the code for puts() as it is a library function that doesn’t +I extract the code for puts() as it is a library function that doesn't really belong to the system.
I add the implementation of kputs() and yield(). @@ -90,7 +90,7 @@ version by adding characters at the beginning of a string.
kputu() takes one additional divider parameter, so it can be
used to print unsigned integer in various format like octal, decimal and
-hexadecimal. Current implementation will work for base 8 to 16, it won’t
+hexadecimal. Current implementation will work for base 8 to 16, it won't
work for binary or base 36.
kputi() outputs signed integer.
@@ -256,7 +256,7 @@ The linker found a reference to putchar() at line 41 of
printf( "\n") ;
-I haven’t used putchar() in my code and line 41 is a
+I haven't used putchar() in my code and line 41 is a
printf( "\n") that can be optimized to a
putchar( '\n'). This must be some high level C optimization of gcc.
@@ -324,7 +324,7 @@ I flash the board and start execution, the output works as expected.
It will take a while to see the days and weeks counts appear, so I will
-need to power the board independently from it’s serial interface. For
+need to power the board independently from its serial interface. For
test purpose I fast forward the execution by using a bigger value for
the increment of uptime in SysTick_handler().
@@ -332,11 +332,11 @@ the increment of uptime in SysTick_handler().
Rereading the code while writing this web page, I found a typo in the
week calculation. After that I retested with a bigger time increment to
-make sure days and weeks values are correct. It’s also clear that the
+make sure days and weeks values are correct. It's also clear that the
test coverage for the printf format interpreter is not sufficient as I have
coded more than is necessary to implement uptime.
-I didn’t expect gcc to optimize calls to high level C functions,
+I didn't expect gcc to optimize calls to high level C functions,
replacing some printf() by putchar(), thus forcing me
to write additional code. So far I am not concerned by execution speed, so this
type of optimization is a bit counter productive.
diff --git a/docs/27_library.html b/docs/27_library.html
index 67b216d..22f718b 100644
--- a/docs/27_library.html
+++ b/docs/27_library.html
@@ -9,7 +9,7 @@
2.7: C Library
So far I have used three Standard C library functions for output: -printf(), putchar() and puts(). It’s
+printf(), putchar() and puts(). It's
time to bundle them as a library. This will give me more flexibility as I will
not have to give a full list of the modules to link, the linker will handle
the missing dependencies by looking into the libraries.
@@ -38,7 +38,7 @@ int puts( const char *s) {
I need to tell GNU make how to manage and use the library, which
means updating Makefile with the following informations:
-What’s the name, the content and the rule to maintain the library: +What's the name, the content and the rule to maintain the library:
AR = $(BINPFX)ar
@@ -63,7 +63,7 @@ $(PROJECT).elf: $(OBJS) lib$(LIBSTEM).a
$(OBJDUMP) -hS $@ > $(PROJECT).lst
-Library modules are implicitly part of the composition, so it’s not
+Library modules are implicitly part of the composition, so it's not
necessary to list them anymore.
diff --git a/docs/28_clocks.html b/docs/28_clocks.html index f5adc29..7b16e65 100644 --- a/docs/28_clocks.html +++ b/docs/28_clocks.html @@ -9,7 +9,7 @@2.8 Baud Rate and Clocks
“The time has come,” the walrus said, “to talk of many things: Of baud - rates – and clocks – and quartz.”@@ -20,7 +20,7 @@ so how fast is that?
+ rates - and clocks - and quartz.”
-- Les huit scaroles --A bit of theory
-Let’s interpret asynchronous serial transmission, 9600 baud, 8 bits, no +Let's interpret asynchronous serial transmission, 9600 baud, 8 bits, no parity, 1 stop bit.
- Serial transmission means transmission on one wire, with each bit sent @@ -40,17 +40,17 @@ the change in the wire state.
Baud rate accuracy
It sounds like a pretty robust transmission scheme, sampling at 16 times -the transmission clock isn’t call oversampling for nothing. Am I +the transmission clock isn't call oversampling for nothing. Am I overdoing something here or just compensating for something I missed?-The thing is, I didn’t program USART1 to transmit at 9600 baud. As my +The thing is, I didn't program USART1 to transmit at 9600 baud. As my default clock is 8MHz, I had to write in USART1 baud rate register a value close to 8000000/9600 or 2500/3, 833 is close enough but my actual transmission speed is closer to 9604, slightly faster than 9600 baud. @@ -62,7 +62,7 @@ want to work at higher baud rate.
Clocks
-Looking at the clock tree in the datasheet can be intimidating, it’s +Looking at the clock tree in the datasheet can be intimidating, it's definitively about several clocks.
@@ -115,7 +115,7 @@ I will use 24 MHz.
Quartz
I can also activate the quartz if there is one soldered on the board. -It’s usually the case but specially for STM32F030F4 which has only 20 +It's usually the case but specially for STM32F030F4 which has only 20 pins, a quartz less design that free up two GPIO pins can be a day saver. Quartz value from 4 to 32 MHz are supported and most design use 8 MHz. diff --git a/docs/29_interrupt.html b/docs/29_interrupt.html index 26e42c9..c56ddae 100644 --- a/docs/29_interrupt.html +++ b/docs/29_interrupt.html @@ -8,7 +8,7 @@2.9 Interrupt Driven Transmission
-It’s time to revise the implementation ofkputc(), remove the
+It's time to revise the implementation of kputc(), remove the
recursive call to handle CR LF transmission and avoid the busy wait
loop. USART1 can trigger an interrupt when the Transmit Data Register
(TDR) is empty which is all I need to implement interrupt driven
@@ -128,7 +128,7 @@ Configuration Register of USART1:
#define USART_CR1_TXEIE (1 << 7) /* 7: TDR Empty Interrupt Enable */I use a Round Robin buffer to synchronize
kputc() and
-USART1_Handler() making sure they don’t write to the same location.
+USART1_Handler() making sure they don't write to the same location.
static unsigned char txbuf[ 8] ; // best if size is a power of 2 for cortex-M0
@@ -141,11 +141,11 @@ static volatile unsigned char txbufout ;
USART1_Handler() only read from it.
txbufin is the index of the position where
-kputc() will insert a character, it’s written by
+kputc() will insert a character, it's written by
kputc() and read by USART1_Handler().
txbufout is the index of the position where
-USART1_Handler() will fetch a character, it’s written by
+USART1_Handler() will fetch a character, it's written by
USART1_Handler() and read by kputc(). The value of
txbufout will change under interrupt, so it is marked as
volatile to make sure the compiler will not optimize the code in a
@@ -260,7 +260,7 @@ to hold lastc (1 byte). The new version uses 12 bytes to hold the round robin
buffer (8 bytes), its in and out indexes (2 bytes) and lastc (1 byte).
% size to
-bit masking & (size – 1) as the size 8 is a power of 2.
+bit masking & (size - 1) as the size 8 is a power of 2.
Flashing a device with the new executable, uptime works as the previous
version.
diff --git a/docs/31_dht11.html b/docs/31_dht11.html
index 87dbae7..82dfd27 100644
--- a/docs/31_dht11.html
+++ b/docs/31_dht11.html
@@ -11,7 +11,7 @@
The DHT11 is a low cost humidity and temperature sensor from Aosong
which is easy to buy online. It is not popular as it has a non standard
communication protocol and its precision is ±5% for humidity and ±2°C
-for temperature so it’s often overlooked for more expensive solution.
+for temperature so it's often overlooked for more expensive solution.
Hardware consideration
@@ -142,11 +142,11 @@ iolvl_t gpioa_read( int pin) { /* Read level of GPIOA pin */ } -I didn’t use the GPIO Input Data Register (IDR) until now, so I add it +I didn't use the GPIO Input Data Register (IDR) until now, so I add it to the registers description.
gpioa_output() implementation is minimal. I know I am switching
-only between input and output mode, so I don’t need to mask the bit field
+only between input and output mode, so I don't need to mask the bit field
first.
I use the System Tick to implement usleep().
@@ -165,7 +165,7 @@ The System Tick generates an interrupt every second but I can read the
Current Value Register (CVR) to pause for smaller time period.
As I will read the sensor just after a new second count, I know that the -CVR value is close to maximum and I don’t need to care for a roll +CVR value is close to maximum and I don't need to care for a roll over.
SysTick input clock is HCLK/8, this implementation will work for @@ -331,7 +331,7 @@ can measure 80µs in retries unit. This is all I need to calibrate the timing measurement.
I can do this calibration every time the DHT11 starts transmission, this -way I don’t need to update some constant if I change the frequency of my +way I don't need to update some constant if I change the frequency of my system clock.
@@ -418,7 +418,7 @@ two seconds.The calibration data are saved in the last 96 bytes of the System -Memory, starting at address 0x1FFFF7A0. So it’s simple to dump the +Memory, starting at address 0x1FFFF7A0. So it's simple to dump the content of that zone and compare the values for multiple chips.
-The humidity value seems off the mark. So I need to investigate what’s +The humidity value seems off the mark. So I need to investigate what's the issue.
Checkpoint
diff --git a/docs/32_errata.html b/docs/32_errata.html index e39ec18..8be8eb5 100644 --- a/docs/32_errata.html +++ b/docs/32_errata.html @@ -9,7 +9,7 @@3.2 DHT11 Errata I only did basic testing so far, checking that the values read were -displayed properly. But the humidity values didn’t seem correct, so I +displayed properly. But the humidity values didn't seem correct, so I need to do some extra verifications. There are many possible causes and they can combine, bugs like humans are social animals, when you find one, look for its mates. @@ -55,7 +55,7 @@ the previous version v1.3 branded AOSONG which seems identical except a revision page.
I also have an English Aosong DHT11 datasheet that seems outdated. -Aosong doesn’t seem to allow redistribution of their datasheet so most +Aosong doesn't seem to allow redistribution of their datasheet so most online vendor have made their own based on that English version.
The English datasheet states the temperature range as 0~50℃, the @@ -80,7 +80,7 @@ around 25~26%RH. As I have changed both interval and setup time, I need confirm that it is the interval time that matters.
With intervals of 5 and 6 seconds, the reading jumps above 37%RH. So -it’s clearly a problem with the interval. +it's clearly a problem with the interval.
I want to make a round number of samples per minute, so I need retest to check if 10 and 12 seconds work the same as 15, but before I do fine @@ -89,7 +89,7 @@ particular DHT11.
Product quality
-It’s clear that the DHT11 I am testing is not behaving according to old +It's clear that the DHT11 I am testing is not behaving according to old or new specifications for the sampling interval.Defects happen! No production line output is 100% perfect, so I may just @@ -205,14 +205,14 @@ And retest after the following modification.
Stability
-During my test I didn’t noticed big surges in measurements but the time +During my test I didn't noticed big surges in measurements but the time to get to actual value is quite long. The interval between readings affects the measurement and initially it takes a long time for the readings to converge to actual temperature or humidity.Conclusions
-I didn’t find any English version of the latest version of the +I didn't find any English version of the latest version of the datasheet.I found some difference between the Chinese datasheet and the behavior diff --git a/docs/33_ds18b20.html b/docs/33_ds18b20.html index 3e9ec92..b883e8a 100644 --- a/docs/33_ds18b20.html +++ b/docs/33_ds18b20.html @@ -24,7 +24,7 @@ resistor between vcc and io data.
It is possible to power the chip using data io and gnd only (no vcc) in -Parasitic Power Mode if a two wire only interface is needed. I won’t use +Parasitic Power Mode if a two wire only interface is needed. I won't use this feature for now.
Communication protocol
diff --git a/docs/34_adcvnt.html b/docs/34_adcvnt.html index f28b374..a352666 100644 --- a/docs/34_adcvnt.html +++ b/docs/34_adcvnt.html @@ -81,7 +81,7 @@ The ADC characteristics in the STM32F030 datasheet states that the maximum ADC sampling clock is 14MHz. It is possible to select either an internal 14 MHz clock (HSI14) or PCLK divided by 2 or 4. I want to check how the clock affects the readings (HSI14, 28/2, 24/2, 48/4). At first I -couldn’t manage to make PCLK/4 work until I found the note on ADC +couldn't manage to make PCLK/4 work until I found the note on ADC calibration work around in the errata ES0219 2.5.3 @@ -117,7 +117,7 @@ The raw data readings are relative to the analog operative voltage VDDA. Vmeasured = VDDA * VRAW / 4095This is why I measure both voltage and temperature. Ideally, VDDA should -be 3.3V, in practice it’s highly dependent of the power supply. +be 3.3V, in practice it's highly dependent of the power supply.
Every chip is calibrated in factory during production, ADC conversion is done at 3.3V and 30℃ and the resulting values are stored in system diff --git a/docs/35_calibrate.html b/docs/35_calibrate.html index 174a40c..03c9b39 100644 --- a/docs/35_calibrate.html +++ b/docs/35_calibrate.html @@ -17,13 +17,13 @@ reading at 3.3V (±10mV) and 30℃ (±5℃).
There is only one point calibration documented and its reference -temperature is known with a precision of ±5℃. That’s not enough to +temperature is known with a precision of ±5℃. That's not enough to calculate temperature but it shows that the sensor was tested in production.
Notice that the calibration value name is TS_CAL1, some other STM32 chipset families do have a second temperature factory calibration point -TS_CAL2. Also some don’t have any factory calibration stored at all. +TS_CAL2. Also some don't have any factory calibration stored at all. So you have to refer to the datasheet that matches the chip you are targeting when you port your code to a new chipset.
@@ -37,7 +37,7 @@ typical average slope of 4.3 mV/℃ and was calibrated in factory at exactly 3.3V and 30℃, then you could use the following formula to calculate the temperature.
-T = 30 + (TS_CAL1 * 3.3 – TS_RAW * VDDA) / 4095 / 0.0043 +T = 30 + (TS_CAL1 * 3.3 - TS_RAW * VDDA) / 4095 / 0.0043
with
@@ -45,7 +45,7 @@ with
that gives
-T = 30 + 3.3 * (TS_CAL1 – TS_RAW * V_CAL / V_RAW) / 4095 / 0.0043 +T = 30 + 3.3 * (TS_CAL1 - TS_RAW * V_CAL / V_RAW) / 4095 / 0.0043
If I express the average slope in raw ADC units per ℃ instead of mV/℃
@@ -53,7 +53,7 @@ If I express the average slope in raw ADC units per ℃ instead of mV/℃
the final formula is
-T = 30 + (TS_CAL1 – TS_RAW * V_CAL / V_RAW) * 1000 / 5336 +T = 30 + (TS_CAL1 - TS_RAW * V_CAL / V_RAW) * 1000 / 5336
which matches the sample code for temperature computation given in the reference manual (RM0360 A.7.16). @@ -76,7 +76,7 @@ If I use the raw ADC readings from my last run
VDDA = 3.3 * 1526 / 1538 = 3.274V
-t = 30 + (1721 – 1718 * 1526 / 1538) * 1000 / 5336 = 33.07℃ +t = 30 + (1721 - 1718 * 1526 / 1538) * 1000 / 5336 = 33.07℃
I confirm the voltage with a voltmeter (measured 3.282V versus 3.274V computed). The computed internal temperature value is roughly 5℃ higher @@ -94,7 +94,7 @@ Memory (3KB) and the option bytes. | RAM Memory | 0x20000000 | 4KB |
@@ -136,7 +136,7 @@ temperature += 30; Factoring in the actual measured voltage, this gives-t = 30 + (1721 – 1718 * 1526 / 1538) * 80 / (1721 – 1297) = 33.09℃ +t = 30 + (1721 - 1718 * 1526 / 1538) * 80 / (1721 - 1297) = 33.09℃-T = 30 + (TS_CAL1 – TS_RAW * V_CAL / V_RAW) * 80 / (TS_CAL1 – TS_CAL2) +T = 30 + (TS_CAL1 - TS_RAW * V_CAL / V_RAW) * 80 / (TS_CAL1 - TS_CAL2)
If I use the raw ADC readings from my last run @@ -145,7 +145,7 @@ TSCAL2_SLOPE = (1721 - 1297) / 80 = 5.3 ADC step/℃ = 3.3 * 5.3 / 4095 = 4.271 mV/℃
Which is only 0.02℃ higher than the previous result based on the more generic formula. Because the temperature measured is close to the diff --git a/docs/36_update.html b/docs/36_update.html index cb4e19b..aaa5d25 100644 --- a/docs/36_update.html +++ b/docs/36_update.html @@ -61,7 +61,7 @@ f030f4.elf from startup.txeie.o adc.o adcmain.o 2644 0 16 2660 a64 f030f4.elf
-As I don’t want to turn off size optimization and I am not willing to
+As I don't want to turn off size optimization and I am not willing to
always pay the full 180 bytes for a production ready memset()
when it is called only once at startup to clear a few bytes, I ended up adding
my own version of memset() to my local library.
diff --git a/docs/37_inram.html b/docs/37_inram.html
index ca24992..d865d9d 100644
--- a/docs/37_inram.html
+++ b/docs/37_inram.html
@@ -17,7 +17,7 @@ the code in flash memory.
stm32flash -g 0 COM6-With my current code, this works fine as far as I don’t use interrupt +With my current code, this works fine as far as I don't use interrupt subroutine. ledon and blink both work, but ledtick will reset once the
SysTick_Handler() interrupt routine is triggered
for the first time. This is due to the fact that the system memory is still
@@ -87,7 +87,7 @@ the resulting f030f4.map file.
stm32flash -w blink.bin -S 0x20000800 COM6 @@ -95,7 +95,7 @@ stm32flash -g 0x20000800 COM6This work just fine but of course the executable of ledon or -blink doesn’t use interrupt routines. +blink doesn't use interrupt routines.
ISR Vector in RAM
diff --git a/docs/39_resistor.html b/docs/39_resistor.html index 934798b..6ea7f8a 100644 --- a/docs/39_resistor.html +++ b/docs/39_resistor.html @@ -8,7 +8,7 @@3.9 Reading a Resistor Value
-I used the ADC previously to read the internal sensors, so it’s simple +I used the ADC previously to read the internal sensors, so it's simple to move on to external ones. Once you can read the value of a resistor, there is a wide choice of analog applications: thermistors, photocells, potentiometers, sliders, joysticks … @@ -35,11 +35,11 @@ in the range [0 … 4095], I can express the two voltages in terms of ADC valuesThe voltage divider relationship now becomes
VDDA * ADCraw / 4095 = VDDA * Rref / (Rref + Rmeasured)
which can be further simplified as
- ADCraw * Rmeasured = Rref * (4095 – ADCraw)
+ ADCraw * Rmeasured = Rref * (4095 - ADCraw)
The resistor value is then given by
- Rmeasured = Rref * (4095 – ADCraw) / ADCraw
+ Rmeasured = Rref * (4095 - ADCraw) / ADCraw
or
- Rmeasured = Rref * (4095 / ADCraw – 1)
+ Rmeasured = Rref * (4095 / ADCraw - 1)
Devil in the whatnots
Some of the things to pay attention to while coding @@ -121,6 +121,10 @@ I add the composition in MakefileBuilding up on the previous ADC reading of internal sensors, sampling of an external resistor pair connected to one of the IO pin is straightforward. +
++Next, I will show the temperature readings on a +display.
© 2020-2025 Renaud Fivet diff --git a/docs/AA_factory.html b/docs/AA_factory.html index 2c9e4f9..4843311 100644 --- a/docs/AA_factory.html +++ b/docs/AA_factory.html @@ -39,21 +39,21 @@ $ stm32flash -r - -S 0x1FFFF7a0:96 COM6 2>/dev/null | hexdump -C
| BootID | X | Y | Wafer | Lot | TS_CAL1 | VREFINT_CAL | TS_CAL2 | Flash | TBD | |--------|-------|-----|-------|-----------|---------|-------------|---------|-------|---------| -| x10 | x800A | x41 | x08 | ‘QMY687 ‘ | x6E6 | x5F1 | x53E | 16 | hZE? | -| x10 | x800C | x18 | x01 | ‘QRR259 ‘ | x6E3 | x5F2 | x532 | 16 | h\E? | -| x10 | x8011 | x49 | x0E | ‘W3U795 ‘ | x6D1 | x5F0 | x523 | 16 | hbF? | -| x10 | x8014 | x20 | x13 | ‘W3R171 ‘ | x6CE | x5F5 | x527 | 16 | hd<? | -| x10 | x8015 | x21 | x13 | ‘W4A195 ‘ | x6DA | x5EE | x52A | 16 | h^D? | -| x10 | x1C | x3A | x12 | ‘W4A820 ‘ | x6B9 | x5F6 | x511 | 16 | hR;? | -| x10 | x09 | x4D | x0B | ‘W4C593 ‘ | x6E6 | x5F4 | x53C | 16 | haG? | -| x10 | x1D | x41 | x12 | ‘W4R342 ‘ | x6E4 | x5F1 | x535 | 16 | hZJ? | -| x10 | x10 | x17 | x05 | ‘WAA390 ‘ | x6E9 | x5F8 | x523 | 16 | hY=? | -| x10 | xDDC1 |xDDC1| x0D | ‘ ‘ | x703 | x5E9 | x535 | 32 | hNb\xFF | -| x10 | xDDC1 |xDDC1| x0F | ‘ ‘ | x70B | x5EF | x537 | 32 | hHX\xFF | -| x10 | xDDC1 |xDDC1| x10 | ‘ ‘ | x6FE | x5E9 | x539 | 32 | hZa\xFF | -| x21 | x4D | x47 | x0C | ‘QMT476 ‘ | x6D8 | x5F3 | x52D | 64 | hlR\xBF | -| x21 | x36 | x47 | x0A | ‘QRW813 ‘ | x6DF | x5F3 | x539 | 64 | hhF\xFF | -| x21 | x41 | x1E | x12 | ‘SNG712 ‘ | x6EB | x5F0 | x526 | 64 | hjS\xFF | +| x10 | x800A | x41 | x08 | 'QMY687 ' | x6E6 | x5F1 | x53E | 16 | hZE? | +| x10 | x800C | x18 | x01 | 'QRR259 ' | x6E3 | x5F2 | x532 | 16 | h\E? | +| x10 | x8011 | x49 | x0E | 'W3U795 ' | x6D1 | x5F0 | x523 | 16 | hbF? | +| x10 | x8014 | x20 | x13 | 'W3R171 ' | x6CE | x5F5 | x527 | 16 | hd<? | +| x10 | x8015 | x21 | x13 | 'W4A195 ' | x6DA | x5EE | x52A | 16 | h^D? | +| x10 | x1C | x3A | x12 | 'W4A820 ' | x6B9 | x5F6 | x511 | 16 | hR;? | +| x10 | x09 | x4D | x0B | 'W4C593 ' | x6E6 | x5F4 | x53C | 16 | haG? | +| x10 | x1D | x41 | x12 | 'W4R342 ' | x6E4 | x5F1 | x535 | 16 | hZJ? | +| x10 | x10 | x17 | x05 | 'WAA390 ' | x6E9 | x5F8 | x523 | 16 | hY=? | +| x10 | xDDC1 |xDDC1| x0D | ' ' | x703 | x5E9 | x535 | 32 | hNb\xFF | +| x10 | xDDC1 |xDDC1| x0F | ' ' | x70B | x5EF | x537 | 32 | hHX\xFF | +| x10 | xDDC1 |xDDC1| x10 | ' ' | x6FE | x5E9 | x539 | 32 | hZa\xFF | +| x21 | x4D | x47 | x0C | 'QMT476 ' | x6D8 | x5F3 | x52D | 64 | hlR\xBF | +| x21 | x36 | x47 | x0A | 'QRW813 ' | x6DF | x5F3 | x539 | 64 | hhF\xFF | +| x21 | x41 | x1E | x12 | 'SNG712 ' | x6EB | x5F0 | x526 | 64 | hjS\xFF |
© 2020-2025 Renaud Fivet diff --git a/docs/index.html b/docs/index.html index 3b6149e..1566ad6 100644 --- a/docs/index.html +++ b/docs/index.html @@ -13,7 +13,7 @@ Getting started with a micro-controller usually means picking up a board, an IDE, some RTOS or a set of libraries. Depending of your level of experience, your budget and the solutions you select, the learning curve may be a steep one and what you will learn could be very limited if you end up cornered in a -sandbox with no understanding of what’s going on under the hood. +sandbox with no understanding of what's going on under the hood.
Commercial solutions and mature open source projects are a must if you want to develop products with some level of quality. Unfortunately their complexity is @@ -24,7 +24,7 @@ not addressing what you need to learn. Starting from scratch, on the other hand, is not something often documented and when it is, it is usually after the fact. So if you want to learn how to do it you need to catch the opportunity to watch someone going through the steps and -explaining what’s going on. +explaining what's going on.
I will try to capture here my own “STM32 bring up” journey using a step by step approach, writing down the problems faced and decisions taken while evolving @@ -62,7 +62,7 @@ for further evolution.
Part II: Let's talk!
-It’s time to move to a more talkative interface so that the board not +It's time to move to a more talkative interface so that the board not only winks but also speaks. Again I will go through several steps to get to a working interrupt driven asynchronous serial communication.-
@@ -117,8 +117,12 @@ during startup.
- Read a Resistor Value.
Appendices
+Part IV: What You See Is What You Get!
+-
+
- Display temperature readings on a quad 7 segment LED display. +
Appendices
- Factory-programmed values.