Using an STM32WB55 Bluetooth board, I followed this guide to enable logging directly in STM32CubeIDE via the SWV ITM Data Console view, which works very well. Had to define my own _write function to override where printf sends its output.
However when I enable the STM32_WPAN middleware (which contains Bluetooth functionality that I absolutely want to take advantage of), it includes its own _write function, resulting in a duplicate declaration.
Is there any way to reconfigure the middleware to exclude its own debug config or tell it to use the same SWO based debugging that I'm currently using? Or do I have to manually overwrite the function?
Related
I'm using STM32f103 and in my program, I need to save some bytes in the internal flash memory. But as far as I know, I have to erase a whole page to write in it, which will take time.
This delay causes my display to blink.
Can anybody help me to save my data without consuming so much time?
Here is a list that may help:
1- MCU: STM32f103
2- IDE: Keil vision
3- using HAL driver provided by STM32CubeMx
4- sample data for saving in Flash: {0x53, 0xa0, 0x01, 0x54}
In the link below, you can find the code that I'm using.
FLASH_PAGE for Keil
The code you provide doesn't seem to be implemented well. It basically does 2 things each time you initiate a write operation:
Erase the page (this is the part that takes time)
Start form the given pointer, write until it hits a zero.
This is a very ineffective way of using the flash.
Probably the simplest and the most well-known way is to use the method described in ST's AN2594, although it has some limitations.
Still, at some point a page erase will be necessary regardless the method you use and there is no way to avoid some delay, unless your uC supports dual flash banks (STM32F103 don't have this feature). You need to plan the timing of flash writes and display refresh accordingly. If you need periodic writes to the flash, there is probably some high level error in your design.
To solve this problem, I used another library that STM itself presented. I had to include "eeprom.h" into your project and then add "eeprom.c" to it. You can easily find these files on the Internet.
For a project I'm thinking of using this relatively new IC from TI - the ADS7138. The issue (I believe, though I may be wrong) is that there is no driver for this chip in the kernel. Does anyone have any suggestions for a work around to talking to this driver? Is there another driver I could use or am I stuck writing a custom driver specific for this IC?
I've worked on a board bring-up project with the same IC. I couldn't find a driver for it so I wrote one myself. I hope it works for you as well:
ADS7138 Driver
Till you find a compatible kernel driver or develop one yourself, you can quickly experiment with the ADC from user space using the i2c-tools. You can use either the command line tools or use the API to write your own app, but be cautious if you use the command line tools like i2cget(8), first read the man pages and pay attention to the warning section.
To use the API, open(2) the i2c device, set the slave address with ioctl(2), then use smbus APIs like i2c_smbus_write_word_data(), i2c_smbus_read_word_data() etc. You may take a look at the tools code like i2cget.c itself to see how the API is used. Following is a simple code to read a register from an I²C chip connected to /dev/i2c-0.
int fd = open("/dev/i2c-0", O_RDWR);
ioctl(fd, I2C_SLAVE, slave_address);
__s32 res = i2c_smbus_read_word_data(fd, register_address);
close(fd);
See kernel documentation or the web about i2c/smbus and instantiating i2c devices for more details.
Default argument completer for string argument is just a path.
However, if required argument is not supplied, user is presented with the prompt to enter argument value, but tab completion is not working in that case.
Is it possible to enable it for the prompt as well?
Is it possible to enable [file system tab-completion] for the prompt as well?
That depends entirely on the host application!
In the default host applications: No!
The prompt implementation in the default host applications (powershell.exe/pwsh.exe) are kept extremely simple for easy interoperability with legacy command line applications.
When the host application prompts for missing arguments, it's really last-resort exception avoidance - the caller failed to supply mandatory parameter arguments for the code they asked to invoke, and the command processor intervenes by asking the host application "Please, interrupt everything and try to give me some input, otherwise I can't proceed" - and the simplest way of implementing this intervention in a way that's compatible with the I/O characteristics of most command line tools is to just block until an input string is provided via stdin.
In a custom host application: Sure!
If you're interested in developing your own host application to sit atop PowerShell's language engine, you can use whatever UI flow you want, as long as your host applications UI implements Prompt() as a synchronous method that returns a dictionary of parameterName<->argument bindings.
There's even an official sample application showing a rudimentary PSHostUserInterface implementation with custom Prompt() and PromptForChoice() to get you started!
I am using stm32f4 on discovery board with freertos running on it.
Just started working with stm32 controller and trying to make data transfer using UART. Printf based on HAL_UART_Transmit works perfectly, but receiving data isn't working.
According to numerous tutorials it should be very simple. I create a project in Stm32CubeMX, add all necessary stuff (freertos, USART3, NVIC), enable USART3 global interrupt and generate the code.
I'm trying to add HAL_UART_Receive_IT(&huart3, &rx_char, 1); or something similar in a task and it doesn't do anything. I suppose it flies through it very fast and doesn't wait for characters to be sent from the terminal.
What do I miss here?
My question is quite simple.
I encountered this sys_vm86old syscall (when reverse engineering) and I am trying to understand what it does.
I found two sources that could give me something but I'm still not sure that I fully understand; these sources are
The Source Code and this page which gives me this paragraph (but it's more readable directly on the link):
config GRKERNSEC_VM86
bool "Restrict VM86 mode"
depends on X86_32
help:
If you say Y here, only processes with CAP_SYS_RAWIO will be able to
make use of a special execution mode on 32bit x86 processors called
Virtual 8086 (VM86) mode. XFree86 may need vm86 mode for certain
video cards and will still work with this option enabled. The purpose
of the option is to prevent exploitation of emulation errors in
virtualization of vm86 mode like the one discovered in VMWare in 2009.
Nearly all users should be able to enable this option.
From what I understood, it would ensure that the calling process has cap_sys_rawio enabled. But this doesn't help me a lot...
Can anybody tell me ?
Thank you
The syscall is used to execute code in VM86 mode. This mode allows you to run old "real mode" 32bit code (like present in some BIOS) inside a protected mode OS.
See for example the Wikipedia article on it: https://en.wikipedia.org/wiki/Virtual_8086_mode
The setting you found means you need CAP_SYS_RAWIO to invoke the syscall.
I think X11 especially is using it to call BIOS methods for switching the video mode. There are two syscalls, the one with old suffix offers less operations but is retained for binary (ABI) compatibility.