>Home

Raspberry Pi XPT2046 / ADS7846 touch screen and Ubuntu classic

Published 4/25/2019

I have an HDMI 800x480 touch screen for the raspberry pi labelled "5inch HDMI LCD V2", which specifies that it has an XPT2046 Touch Controller. I was having difficulties getting the touch controller to work together with Ubuntu 'classic'.

Most tutorials to get the device to work simply specify that all you have to do is add the following to `/boot/config.txt`:

dtparam=i2c_arm=on dtparam=spi=on dtoverlay=ads7846,penirq=25,speed=10000,penirq_pull=2,xohms=150

Unfortunately there are a few differences with how the ubuntu image is set up in comparison to Raspbian. The first is that the config file is located in `/boot/firmware/config.txt`. The second is that rather than using the raspbian boot image for loading the linux kernel, the Ubuntu image uses `u-boot.bin`. By default this setup doesn't load any of the device tree overlay files, and so it just ignores the `dtoverlay` configuration parameter. I'm sure it is possible to get this to work, but for me the workaround was to revert to the raspberry pi bootloader following https://wiki.ubuntu.com/ARM/RaspberryPi#Change_the_bootloader.

In practice this means changing the first few lines of the config, changing the kernel parameter and adding the initramfs line, while commenting out device_tree:

kernel=vmlinuz initramfs initrd.img followkernel # device_tree_address=0x02000000

In addition to this, it is also necessary to copy the overlays to the boot folder, as well as the chipset device tree file (note this file and the kernel path may be different, just choose the latest kernel path and the correct bcm file):

cp -r /lib/firmware/4.15.0-1034-raspi2/device-tree/overlays/ /boot/firmware/ cp /lib/firmware/4.15.0-1034-raspi2/device-tree/bcm2709-rpi-2-b.dtb /boot/firmware/

After that the device should show up in `/dev/input/event0`.

You will probably still need to create the file `/usr/share/X11/xorg.conf.d/99-ads7846.conf`:

Section "InputClass" Identifier "calibration" MatchProduct "ADS7846 Touchscreen" Option "Calibration" "3853 170 288 3796" Option "SwapAxes" "1" EndSection

Simulating a PID control

Published 10/3/2017

One thing that I have always wanted to do but never found the time for is simulating a PID controller with a heat source. In the following I describe how I do this in a small Excel spreadsheet.

The first nuisance related to this problem is that in order to simulate a PID controller, we need an enviroment to simulate.

In our case we assume we have a medium which is divided into 5 compartments labeled T_n, where n is a number between 1 and 5. T₁ is heated by a heat source, and the heat propagates through each of the compartments till it reaches compartment T_5, which contains our sensor. Each heat compartment dissipates some heat along the way. This setup provides us with a non-linear, time delayed and exponential setup. A figure is shown below.

We first define a constant for the room temperature, which we call T_env and we set it to 20 degrees Celcius. Then we define T loss, which is the amount of degrees per minute per degrees Celcius which are lost.

This allows us to define the loss using the following equation:

This allows us to define the equation of each compartment in the next timestep. The new temperature for compartments 2 to 5 are simply the average of compartment n and compartment n-1 (this could be weighted however) minus the losses due to heat dissipation. For the first compartment, we set it to the old temperature minus heat losses and add the heat depending on the duty cycle d and assuming that the heating element becomes less effective as the heat rises.

Finally we can define our PID duty equation, which has a target temperature of 70 degrees celcius, and makes use of the proportional integral and differential constants (K_p, K_d and K_i).

Given these equations, it is possible to pick some values, which allow for a fairly optimal graph. In this case the following values were chosen:

The effects of the different parts of a PID can be seen in the three figures below, the first being proportiona only, the second being proportional + differential and the last being all three:

The excel spreadsheet is available for download from here.

Debugging the STM32F103 with an ST LINK/V2 and OpenOCD

Published 10/3/2017

Debugging is a very useful tool when working with Microcontrollers. I decided to order an ST-Link/V2, which is available for a few Euros (I paid roughly 6 EUR for mine). This device supports the SWD protocol for STM32 chips, which allows the chip to be programmed and debugged from 4 pins.

The first step is to connect the 4 pins. In the following picture, red is the target device voltage, grey is GND, green is IO and blue is CLK. Note that the device still needs external power, which I supply via the micro USB cable (not shown).

OpenOCD is an open source on chip debugger which can be downloaded from http://openocd.org/. It takes a client server approach, and the first step is to start the daemon which connects to the target device. This can be done using the following command, where -s tells openocd where to search for scripts and we tell it to use the stlink-v2 config as well as the stm32f1x config.

.\openocd.exe -s ..\scripts\ -f interface\stlink-v2.cfg -f target\stm32f1x.cfg

Once the OpenOCD daemon is started, we need to use telnet to connect to the device. For this we can connect to the local machine on port 4444, and can directly start issuing commands to the device.

telnet localhost 4444

With OpenOCD connected we can start using various commands. The first thing we can do is reset the device and tell it to break on the first command. This can be done by calling "reset halt" as follows:

> reset halt
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x00000152 msp: 0x20005000

As can be seen, our program counter (pc) is at 0x152, so if we want to see the assembler at that point, we can ask OpenOCD to disassemble it for us, using the arm disassemble command, giving it the address as well as the number of instructions to disassemble.

> arm disassemble 0x152 20
0x00000152 0xe92d4ff0 PUSH.W {r4, r5, r6, r7, r8, r9, r10, r11, r14}
0x00000156 0xb083      SUB     SP, #0xc
0x00000158 0xf2400004 MOVW    r0, #4 ; 0x004
0x0000015c 0xf2400108 MOVW    r1, #8 ; 0x008
0x00000160 0xf2c20000 MOVT    r0, #8192       ; 0x2000
0x00000164 0xf2c20100 MOVT    r1, #8192       ; 0x2000
0x00000168 0x1a09      SUBS    r1, r1, r0
0x0000016a 0x2901      CMP     r1, #0x01
0x0000016c 0xbfa8      IT      GE
0x0000016e 0xf000fb1c BL      0x000007aa
0x00000172 0xf2400000 MOVW    r0, #0 ; 000
0x00000176 0xf2400104 MOVW    r1, #4 ; 0x004
0x0000017a 0xf2c20000 MOVT    r0, #8192       ; 0x2000
0x0000017e 0xf2c20100 MOVT    r1, #8192       ; 0x2000
0x00000182 0x1a0a      SUBS    r2, r1, r0
0x00000184 0x2a01      CMP     r2, #0x01
0x00000186 0xdb05      BLT     0x00000194
0x00000188 0xf24071f8 MOVW    r1, #2040       ; 0x7f8
0x0000018c 0xf2c00100 MOVT    r1, #0 ; 0000
0x00000190 0xf000fb00 BL      0x00000794

We can also use the debugger to dump raw memory, using the mdb command, we tell it where and how much memory to dump:

> mdb 0x0 64
0x00000000: 00 50 00 20 53 01 00 00 51 01 00 00 51 01 00 00 51 01 00 00 51 01 00 00 51 01 00 00 00 00 00 00
0x00000020: 51 01 00 00 51 01 00 00 00 00 00 00 51 01 00 00 51 01 00 00 51 01 00 00 51 01 00 00 51 01 00 00

Setting breakpoints can be done using the bp commands, and they can be removed using the rbp command, as in the following examples:

> bp 0x7aa 2
breakpoint set at 0x000007aa
> rbp 0x7aa

Otherwise there is the resume command, to continue execution in halted state, as well as the step command, to only execute a single opcode.

Another nice command is the reg command, which dumps all registers:

> reg
===== arm v7m registers
(0) r0 (/32): 0x20000004
(1) r1 (/32): 0x00000004
(2) r2 (/32): 0xD4F014C0
(3) r3 (/32): 0x04A82F37
(4) r4 (/32): 0x20000004
(5) r5 (/32): 0xFFCFFEDD
(6) r6 (/32): 0x0C06C5A6
(7) r7 (/32): 0x390A2280
(8) r8 (/32): 0x9A9F8FD8
(9) r9 (/32): 0xFFDF5B9D
(10) r10 (/32): 0xD4368C54
(11) r11 (/32): 0x680C1352
(12) r12 (/32): 0x7DBEF177
(13) sp (/32): 0x20005000
(14) lr (/32): 0xFFFFFFFF
(15) pc (/32): 0x00000152
(16) xPSR (/32): 0x01000000
(17) msp (/32): 0x20005000
(18) psp (/32): 0xC4E16220
(19) primask (/1): 0x00
(20) basepri (/8): 0x00
(21) faultmask (/1): 0x00
(22) control (/2): 0x00
===== Cortex-M DWT register
(23) dwt_ctrl (/32)
(24) dwt_cyccnt (/32)
(25) dwt_0_comp (/32)
(26) dwt_0_mask (/4)
(27) dwt_0_function (/32)
(28) dwt_1_comp (/32)
(29) dwt_1_mask (/4)
(30) dwt_1_function (/32)
(31) dwt_2_comp (/32)
(32) dwt_2_mask (/4)
(33) dwt_2_function (/32)
(34) dwt_3_comp (/32)
(35) dwt_3_mask (/4)
(36) dwt_3_function (/32)

The problem I was facing in http://localhost:8089/Home/6-rust-stm-handling-static-variables with my rust code crashing, seems to be that the code produces the following code for the memory initialization routine:

> arm disassemble 0x7aa 20
0x000007aa 0xb510      PUSH    {r4, r14}
0x000007ac 0x4604      MOV     r4, r0
0x000007ae 0x2901      CMP     r1, #0x01
0x000007b0 0xbfa4      ITE     GE
0x000007b2 0x4620      MOV     r0, r4
0x000007b4 0xf7fffff9 BL      0x000007aa

This code essentially ends up in an infinite loop, because the r1 register is never changed. Each time it loops it jumps to 0x7aa, which contains a push command causing the stack pointer to decrease. This continues untill the microcontroller overwrites memory which it is not allowed to write, causing it to land in a fault interrupt. I'm still not entirely sure why the compiler produces this code however.

This can be confirmed by running and then halting the microcontroller:

> resume
> halt
target halted due to debug-request, current mode: Handler HardFault
xPSR: 0x21000003 pc: 0x00000150 msp: 0x1fffffe0

Rust STM32 Handling Static Variables

Published 9/11/2017

I've just pushed an example showing how to use code that contains statically initialized variables.

The general problem with static variables can be described as follows. Lets say we define a static variable INT_DATA and assign it some value as follows:

pub static mut INT_DATA : u32 = 5;

When we upload our Flash to the microcontroller now however, we are only overwriting the Flash partition. This means that the value 5 for our static variable needs to be stored in Flash. This would work fine, until somewhere in our application we have code which alters this variable such as:

unsafe { INT_DATA = 9 };

This is problematic because the variable is in Flash, where memory cannot be modified!

The solution to this problem is to store all variables with values that need to be initialized in our Flash, and to then copy them to RAM when the application is loaded. By default all variables with non zero values are stored in the .data section, while all zeroed static variables are stored in the .bss section, which must be set to zero during startup.

We start by specifying this in more detail in the linker script. A nice but cryptic resource on what is required is the following page: http://www.math.utah.edu/docs/info/ld_3.html#SEC18.

We use the following updated linker script. We now define a section .etext which we use to get the location after everything else in the Flash memory (I did this because the example using SIZEOF didn't seem to quite work with our setup, but it might be possible). Using it we define the section .data, specifying AT to be the location of .etext, which makes the physical memory address of our data in the ROM be the location of .etext. Finally we also place .bss in RAM, without giving it an address in physical memory.

Within the linker script we also export all the addresses as symbol, so that we can use them within our code. The code _etext = . ; specifies that the current location should be stored under the _etext symbol, which we can use later in code. In this case _etext is the physical memory location of the variables requiring initialization, while _data and _edata mark the virtual addresses. The variables _bstart and _bend are the virtual addresses of the memory that needs to be cleared on startup.

MEMORY
{
FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 64K
RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 20K
}

SECTIONS
{
/* Set stack top to end of RAM */
__StackTop = ORIGIN(RAM) + LENGTH(RAM);

/* first entry should be the stack pointer and then the interrupt table */
.ivtable :
{
LONG(__StackTop);
KEEP(*(.ivtable));
} > FLASH

/* after that the program data is copied */
.text :
{
*(.text*)
*(.rodata*)
} > FLASH

.etext :
{
_etext = . ;
} > FLASH

/* The data has a virtual address in RAM, but is copied just after the program data */
.data : AT ( ADDR(.etext) )
{
_data = . ;
*(.data*)
_edata = . ;
} > RAM

/* The data that receives a virtual address in RAM, but needs to be initialized to zero */
.bss : {
_bstart = . ;
*(.bss*) *(COMMON)
_bend = . ;
} > RAM
}

Now we need a way to be able to get these addresses within our code. This can be done be defining external variables as follows. To get the address of _etext we can then use the code addr_of!(_etext) using the macro we define below.

extern {
    pub static _etext : u8;
    pub static _data : u8;
    pub static _edata : u8;
    pub static _bstart : u8;
    pub static _bend : u8;
}

#[macro_export]
macro_rules! addr_of {
    ($id:expr) => (
        (&$id as *const u8) as *mut u8
    )
}

We now need to define both memclr and memcpy functions, which we will need to initialize the memory. This is fairly straightforward and we use the following:

#[no_mangle]
pub unsafe extern fn __aeabi_memcpy(dest: *mut u8, src: *mut u8, n: isize) -> *mut u8 {
    let mut i = 0;
    while i < n {
        *dest.offset(i) = *src.offset(i);
        i += 1;
    }
    return dest;
}

#[no_mangle]
pub unsafe extern fn __aeabi_memclr(dest: *mut u8, n: isize) -> *mut u8 {
    let mut i = 0;
    while i < n {
        *dest.offset(i) = 0u8;
        i += 1;
    }
    return dest;
}

Finally we can define an init_mem function, which we need to call from our main function. This simply clears the .bss section using the memclr function, and it then uses memcpy to copy our data from flash to RAM:

pub unsafe fn init_mem() {
    // zero .bss section
    __aeabi_memclr(addr_of!(_bstart), addr_of!(_bend) as isize - addr_of!(_bstart) as isize);
    // copy .data section
    __aeabi_memcpy(addr_of!(_data), addr_of!(_etext), addr_of!(_edata) as isize - addr_of!(_data) as isize);
}

This allows the following program to produce the correct output:

pub static mut INT_DATA: u32 = 5; // static value
pub static mut INT_BSS: u32 = 0; // default value

pub fn main() {
unsafe { stm32::mem::init_mem() };

    // setup system
    init_clock();
    enable_led();
    enable_uart();

println("STM32 Memory Test App");
println(" - by Rudi Horn");

    unsafe {
        print("int_data: "); print_int(INT_DATA); println("");
        print("int_bss: "); print_int(INT_BSS); println("");

INT_DATA = 9; INT_BSS = 99;

        print("int_data: "); print_int(INT_DATA); println("");
        print("int_bss: "); print_int(INT_BSS); println("");
    }

loop {
}
}

Output:

STM32 Memory Test App
- by Rudi Horn
int_data: 5
int_bss: 0
int_data: 9
int_bss: 99

For the full source code see https://github.com/rudihorn/rust-stm32f103-examples/tree/master/stm32-mem.

Small note: This example does not compile with --release for some reason. Unfortunately I don't have a debugger (yet) and so it is a bit difficult to find out what the exact cause is, but it seems to be the memclr function and may be related to the actual function call to memclr. If anyone has any ideas let me know!

Rust on STM32 now on Github

Published 9/6/2017

I have decided to publish my stm32 library on github. https://github.com/rudihorn/rust-stm32f103

Along with it there is another project with an example: https://github.com/rudihorn/rust-stm32f103-examples

Compiling Rust for Cortex M3

Published 9/4/2017

I was trying to get Rust to work on ARM based on the instructions found at http://www.acrawford.com/2017/03/09/rust-on-the-cortex-m3.html. Another good resource to look at is http://wiki.osdev.org/Raspberry_Pi_Bare_Bones_Rust. The goal is to be able to use rust on the mini STM32F103C8T6 development boards, which are cheap but make use of a powerful microcontroller. Here is another short summary of what is required.

Setup:

The first step is to install rust and set up nightly build (the nightly will apparently probably still be necessary till the end of 2017). Furthermore xargo is needed, which can be installed from the rust cargo repository.

curl https://sh.rustup.rs -sSf | sh
rustup update nightly
rustup default nightly
rustup component add rust-src
cargo intsall xargo

Install the gcc ARM linker:

apt-get install gcc-arm-none-eab

Now create a new project:

cargo init --bin myproject

The Cargo.toml file:

[package]
name = "arm-test"
version = "0.1.0"

[dependencies]

[profile.dev]
lto = true

[profile.release]
lto = true

Make the directory ".cargo" and then create the file .cargo/config:

[build]
target = "thumbv7m-none-eabi"

[target.thumbv7m-none-eabi]
rustflags = [
"-C", "link-arg=-nostartfiles",
"-C", "link-arg=-Tlayout.ld",
]

We start by editing the file src/main.rs.

For our example we will need to refer to some registers. To do this we define two structs, PortRegisters and RCCRegisters, which refer to a set of consecutive registers that start at a location. We can make use of type aliases to tell the compiler that our registers have the type u32. Having a struct is useful, because if you look at the datasheet the same format of registers repeats itself. We can then just define two pointers for PORT_C and RCC which tell the compiler there is a struct of registers at the given address.

type Register = u32; // Port Registers
struct PortRegisters {
// 0x00: Control register lower
crl : Register,

// 0x04: Control register higher
crh: Register,

// 0x08: Input data register
idr: Register,

// 0x0c: Output data register
odr: Register,

// 0x10: Bit set / reset register
bsrr: Register,
}

// Reset and Clock Control
struct RCCRegisters {
// 0x00: Clock control register
cr: Register,

// 0x04: Clock configuration register
cfgr: Register,

// 0x08: Clock interrupt register
cir: Register,

// 0x0C: peripheral reset register
apb2_rstr: Register,

// 0x10: peripheral reset register
apb1_rstr: Register,

// 0x14: peripheral clock enable register
ahb_enr: Register,

// 0x18: peripheral clock enable register
apb2_enr: Register,

}

const RCC: *mut RCCRegisters = 0x40021000 as *mut RCCRegisters;
const PORT_C: *mut PortRegisters = 0x40011000 as *mut PortRegisters;

Next we define the main function, which does three things. First it enables the clock for the PORT C peripheral. This is done by writing to the APB2 ENR register of RCC. After that it sets the pin C13 to an output, and sets the output value for the entire PORTC to 0 (keep in mind the other pins are floating). We mark this function as naked, because there is no stack yet.

#[naked]
fn main() {
unsafe {
// enable clock for PORTC
(*RCC).apb2_enr = (1 << 4);
// set port C13 to output
(*PORT_C).crh= 0x44344444;
// set output data registor to 0
(*PORT_C).odr = 0;
}

loop {}
}

We can then define the interrupts function. We want all other interrupts to simply stop the microcontroller in a loop.

#[naked]
fn interrupts() {
loop {}
}

If we look at the default / sample application which was downloaded off the newly bought STM device, we can see that the binary of the file starts with the value 0x20000400, which is the default stack pointer location. After that it contains the address 0x80000145, which defines the memory address referring to the first instruction in flash. The further 32 bit words contain the entry points for interrupts. Note that the flash is mapped into memory twice, once at 0x08000000 and again at 0x00000000. This is why our code works, even though as you may see the memory addresses for the entry point differ between our sample and the app we generate. This file is normally located at 0x0800000 in memory.

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000 00 04 00 20 45 01 00 08 E7 02 00 08 DF 02 00 08 ... E...ç...ß... 00000010 E3 02 00 08 8D 01 00 08 5D 04 00 08 00 00 00 00 ã.......]....... 00000020 00 00 00 00 00 00 00 00 00 00 00 00 0D 03 00 08 ................ 00000030 91 01 00 08 00 00 00 00 E9 02 00 08 F9 03 00 08 ‘.......é...ù... 00000040 5F 01 00 08 5F 01 00 08 5F 01 00 08 5F 01 00 08 _..._..._..._... 00000050 5F 01 00 08 5F 01 00 08 5F 01 00 08 5F 01 00 08 _..._..._..._... 00000060 5F 01 00 08 5F 01 00 08 5F 01 00 08 5F 01 00 08 _..._..._..._... 00000070 5F 01 00 08 5F 01 00 08 5F 01 00 08 5F 01 00 08 _..._..._..._... 00000080 5F 01 00 08 5F 01 00 08 5F 01 00 08 5F 01 00 08 _..._..._..._... 00000090 5F 01 00 08 5F 01 00 08 5F 01 00 08 5F 01 00 08 _..._..._..._... 000000A0 5F 01 00 08 5F 01 00 08 5F 01 00 08 5F 01 00 08 _..._..._..._... 000000B0 5F 01 00 08 5F 01 00 08 5F 01 00 08 5F 01 00 08 _..._..._..._... 000000C0 5F 01 00 08 5F 01 00 08 5F 01 00 08 5F 01 00 08 _..._..._..._... 000000D0 5F 01 00 08 5F 01 00 08 5F 01 00 08 5F 01 00 08 _..._..._..._... 000000E0 5F 01 00 08 5F 01 00 08 5F 01 00 08 5F 01 00 08 _..._..._..._... 000000F0 5F 01 00 08 5F 01 00 08 5F 01 00 08 5F 01 00 08 _..._..._..._... 00000100 5F 01 00 08 5F 01 00 08 5F 01 00 08 5F 01 00 08 _..._..._..._... 00000110 5F 01 00 08 5F 01 00 08 5F 01 00 08 5F 01 00 08 _..._..._..._... 00000120 5F 01 00 08 5F 01 00 08 5F 01 00 08 5F 01 00 08 _..._..._..._... 00000130 DF F8 0C D0 00 F0 18 F8 00 48 00 47 81 04 00 08 ßø.Ð.ð.ø.H.G.... 00000140 00 04 00 20 06 48 80 47 06 48 00 47 FE E7 FE E7 ... .H€G.H.Gþçþç 00000150 FE E7 FE E7 FE E7 FE E7 FE E7 FE E7 FE E7 FE E7 þçþçþçþçþçþçþçþç 00000160 FD 03 00 08 31 01 00 08 06 4C 07 4D 06 E0 E0 68 ý...1....L.M.ààh 00000170 40 F0 01 03 94 E8 07 00 98 47 10 34 AC 42 F6 D3 @ð..”è..˜G.4¬BöÓ 00000180 FF F7 DA FF BC 04 00 08 CC 04 00 08 00 BF FE E7 ÿ÷Úÿ¼...Ì....¿þç

We can define this in rust using a structure which contains our interrupt vector table. We then define a static instance of this struct, and define the entrypoint to be the function main, while all of the other interrupts are set to a dummy interrupt which just loops. Note that the #[link_section] directive defines the section which we refer to later in the linker script. Also note the #[used] directive, this is very important for compiling for release, as otherwise everything is optimized away!

type IVFunction = fn ();

struct IVTable {
main: IVFunction,
nmi_handler: IVFunction,
hard_fault: IVFunction,
bus_fault: IVFunction,
usage_fault: IVFunction,
}

#[link_section = ".ivtable"] #[used]
static IVTABLE: IVTable = IVTable {
main: main,
nmi_handler: interrupts,
hard_fault: interrupts,
bus_fault: interrupts,
usage_fault: interrupts
};

At the beginnig of the rust file we need to remove the std library, declare that there isn't a main function and the features for assembler, language items, start and naked functions. Then we need to declare two dummy functions for panics and "eh_personality".

#![no_std]
#![no_main]
#![feature(asm, lang_items, start, naked_functions)]

#[lang = "panic_fmt"]
pub extern fn rust_begin_unwind(_: ::core::fmt::Arguments, _: &'static str, _: u32) -> ! {
loop {}
}

#[lang = "eh_personality"]
pub extern fn rust_eh_unwind_resume() {
}

The compiler requires a linker script to know how to build the binary. We first declare the memory layout of our device and then we declare a a text section, which should first contain a long word with the stack address, which we calculate as the top of the RAM address and then it should contain the ivtable. We then skip forward to address 0xD8, and include the rest of the ".text" section there (our main program execution code, including the main method).

MEMORY
{
FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 64K
RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 20K
}

SECTIONS
{
/* Set stack top to end of RAM */
__StackTop = ORIGIN(RAM) + LENGTH(RAM);

.text :
{
LONG(__StackTop);
KEEP(*(.ivtable));

. = 0xD8;

*(.text*)
} > FLASH
}

We can then build our application using the following commands:

xargo build
arm-none-eabi-objcopy -O binary target/thumbv7m-none-eabi/debug/<myproj> <myproj>.bin

If you wan't you can dissasemble it using the following command, which I recommend doing if you run into any bugs. The assembly output can be seen at http://files.rudi-horn.de/website/2017/09/arm-test-dump.txt.

arm-none-eabi-objdump -d target/thumbv7m-none-eabi/debug/<myproj>

I then flashed the .bin file to the microcontroller using the flash tool available at http://www.st.com/en/development-tools/flasher-stm32.html.

For the full source code: http://files.rudi-horn.de/website/2017/09/arm-test.tar.gz

Bottle Cleaner Prototype

Published 7/15/2017

Bottle cleaning can be a tedious and time consuming task to perform. As such I have been trying to experiment with creating something to clean bottles, similar to projects using the FastRack bottle drying tray (e.g. https://www.youtube.com/watch?v=_iJcG6HbSsE).

The prototype consists out of 20mm outer diameter PVC conduit pipe with 5mm outer diameter copper pipe glued in 80mm intervals 3.5" intervals (estimated to be the distance of FastRack, without actually having a FastRack to measure from). The copper pipe is slightly squeezed together at the ends in order to increase pressure within the system.

The centrifugal submersible pump used can be bought off Aliexpress and is roughly sufficient for 4 bottles at a time (but cheap enough if more are needed): https://www.aliexpress.com/item/New-10L-min-12V-DC-Mini-Brushless-Motor-Submersible-Water-Pump-3-3M-Amphibious/32731443626.html

The bottle holder is a quick 3D printed mockup (took roughly 7 hours to print, so not really suitable for the entire device but good for testing):

Update: I ended up ordering a Fastrack, and the 3x4 bottle tray seems to have a hole distance of 80mm (surprisingly metric ☺).

Welcome to my new Site!

Published 7/14/2017

Welcome to my new webpage!

My homepage is finally dynamically editable without having to change the project itself, meaning I am hoping to contribute much more actively in the future. This is also because the website supports blog style entries, meaning less significant projects can just be posted as blog entries.

For more information about me check out my about page or any of the other projects posted on this website.