Modify the required jdk version in file stm32cubemx.sh from exec archlinux-java-run --min 17 -- -jar /opt/stm32cubemx/STM32CubeMX "$@" to exec archlinux-java-run --min 17 --max 20 -- -jar /opt/stm32cubemx/STM32CubeMX "$@"
Then build and install the STM32CubeMX
1
makepkg --noconfirm --skipinteg -si
Since STM32CubeMX is not compatible with jdk22 (which is the default jdk that arch is currently using), you need to install jdk17 through yay -S jdk17-openjdk
Then you can start STM32CubeMX by running stm32cubemx, and hopefully, everything is fine.
Compiler
Use arm-none-eabi-gcc
1 2
yay -S arm-none-eabi-gcc yay -S arm-none-eabi-newlib
Debugger
Use OpenOCD to burn and debug STM32 through STLink v2 (the blue USB device provided by us).
1
yay -S openocd
Setup Your STM32 Project
Open your STM32CubeMX, follow the instruction of Lab1.pdf to configure your project.
NOTE: In Project Manage -> Project -> Project Settings -> Toolchain / IDE, use Makefile/CMake.
Generate the code and go to the project directory (with Makefile/CMakeLists.txt in the directory).
Then you need to generate the compile_commands.json for clangd to recognize the project.
Makefile
1
bear -- make
CMake
1
cmake -S ./ -B ./build
Build Project
Makefile
1
make
Then target binary file is ./build/<Project Name>.bin
CMake
1
cmake --build ./build
Then target binary file is ./build/<Project Name>.elf
Open On-Chip Debugger 0.12.0 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 Info : clock speed 1000 kHz Info : STLINK V2J37S7 (API v2) VID:PID 0483:3748 Info : Target voltage: 3.222587 Info : [stm32f1x.cpu] Cortex-M3 r1p1 processor detected Info : [stm32f1x.cpu] target has 6 breakpoints, 4 watchpoints Info : starting gdb server for stm32f1x.cpu on 3333 Info : Listening on port 3333 for gdb connections [stm32f1x.cpu] halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x08000dc8 msp: 0x20005000 ** Programming Started ** Info : device id = 0x20036410 Info : flash size = 64 KiB ** Programming Finished ** ** Resetting Target ** shutdown command invoked
NOTE: In different Distro, the cfg file for OpenOCD may locate in different directories. You need to find it by yourselves.
By the way, if you use CMake
Note: When uploading binary file to STM32, it’s recommended to use .bin file instead of .elf file. Please use the following script to convert the .elf to .bin and upload.
To use segger ozone, you need a different linker called jlink (originally we use st-link v2). You need to buy this linker first (maybe on Taobao or Amazon).
Program File: select the binary file you have built (.elf is recommended).
Debug:
set some breakpoints and watch some variables of your interest. Press the green “power” icon on the upper left corner to start (upload the program and start the debugging process) Press the blue “play” icon besides “power” to continue.
A shell built-in command is contained in the shell itself (implemented by shell author) and runs on the same shell without creating a new process, e.g. cd, pwd, exit, alias.
By contrast: For a regular(linux) command, it is run from a binary file (found in $PATH or specified file) by forking the existing process in a subshell, e.g. ls, cat, rm.
How to implement
1. Judge whether is build-in command
Assume we have already got the parsed arguments
char * parsedArgs[MAXPARSE].
For example, a input char * input = "cd .." can be parsed as char * parsedArgs[MAXPARSE] = {"cd", ".."}
Then, we just need to judge whether parsedArgs[0] is contained in our build-in command set {"exit", "cd", "pwd" ...} (by using strcmp)
2. Implementation
In this project (as of milestone 2) , we need to implement exit, pwd, cd.
exit
In Bash, exit is a built-in command used to terminate the current shell session (same in our mumsh).
Each running shell is a process, so we can use the exit() in stdlib.h to terminate the shell process, achieving the goal of exiting the shell.
Running a crude (or minimal?) shell and have no idea where you are? Just type pwd and it will print the name of the current/working directory.
In C, we can implement the similar functionality using the getcwd() in unistd.h.
if success, getcwd() will return the pointer to the result, else ( e.g. no enough space) return NULL
1 2 3 4
voidexec_pwd(){ char buf[1024]; // memory space need for storage printf("%s\n", getcwd(buf,sizeof(buf))); }
However, the working directory is not guaranteed to be shorter than 1024, so we may need to dynamically allocate the buffer to suit the length.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
int size = 100; char *buffer = malloc(size);
while (getcwd(buffer, size) == NULL) { if (errno == ERANGE) { // buffer too small size *= 2; buffer = realloc(buffer, size); } else { // other error ... free(buffer); return1; } }
printf("%s\n", buffer);
free(buffer);
cd
cd is used for changing working directory.
In C, we can implement the similar functionality using the chdir() in unistd.h.
if success, chdir() will return 0, else ( e.g. no such directory) return -1
1 2 3
voidexec_cd(char * path){ chdir(path); }
Very straight forward, but if we want to implement more advanced features of the cd command such as changing to the home directory or the previous directory, we would need to handle these cases manually.
For example, you could check if the argument is ~ or -, and then call chdir() with the appropriate path
SSH (Secure Shell) is a network security protocol that provides secure access and file transfer through encryption and authentication mechanisms. It encrypts and verifies network data to provide secure login and other secure network services.
SSH Keys
SSH uses a combination of public and private keys to secure communication. The public key is used to encrypt data, while the private key is used to decrypt data. This ensures that even if data is intercepted during transmission, attackers cannot decrypt it, ensuring data security.
SSH Agent
An SSH agent is a program that stores private keys and can help you avoid having to enter your passphrase every time you use SSH. When you add a private key to an SSH agent, you only need to enter the passphrase the first time you use the key. After that, the SSH agent will automatically provide the private key for you.
Generating a New SSH Key Pair
You can use the ssh-keygen tool to generate a new SSH key pair. Here’s an example of how to use ssh-keygen to generate an RSA key pair:
-t rsa specifies the type of key to create. In this case, we’re creating an RSA key.
-b 4096 specifies the number of bits in the key. In this case, we’re creating a 4096-bit key.
-C "your_email@example.com" adds a comment to the key. This can be any text you like, but it’s common to use your email address.
After running this command, ssh-keygen will prompt you for a location to save the key pair and for a passphrase to secure the private key. You can accept the default location by pressing Enter, or you can specify a different location if you prefer. If you don’t want to use a passphrase, you can leave it blank by pressing Enter.
Adding a Key to the SSH Agent on Ubuntu
On Ubuntu, you can add a key to the ssh-agent by following these steps:
Open the terminal.
Make sure ssh-agent is running. You can start it by running the eval "$(ssh-agent -s)" command.
Run the ssh-add ~/.ssh/id_rsa command to add your first key (the one you commonly use) to the ssh-agent. If your key file is not in the default location (i.e., ~/.ssh/id_rsa), replace the path in the command with the actual path of your key file.
If your key has a passphrase, you will be prompted to enter it. Enter the passphrase and press Enter.
After completing these steps, you have successfully added your first key to the ssh-agent. Now when you use SSH to connect to a remote server, the ssh-agent will automatically provide your private key.
Viewing Keys in the SSH Agent on Ubuntu
On Ubuntu, you can view the keys added to the ssh-agent by running the ssh-add -l command. This command lists the fingerprints of all keys in the ssh-agent.
Note: Throughout the user manual these defaults are used as placeholders, e.g. “~/.config” is understood to mean “$XDG_CONFIG_HOME or ~/.config”.
LOG FILE $NVIM_LOG_FILEE5430 Besides ‘debug’ and ‘verbose’, Nvim keeps a general log file for internal debugging, plugins and RPC clients. :echo $NVIM_LOG_FILE By default, the file is located at stdpath(“log”)/log unless that path is inaccessible or if $NVIM_LOG_FILE was set before |startup|.
Posted Updated a few seconds read (About 85 words)
