I want to Initialize and send a single int using UART in blue_pill (STM32F10C8). Manual ask to set GPIO mode on ALTRN_PULL_PUSH in blue_pill. But Low level HALL library dosn't have such a option. Here is my code for initializing the UART:
void uart2_init()
{
LL_APB1_GRP1_EnableClock(LL_APB2_GRP1_PERIPH_GPIOA);
LL_APB1_GRP1_EnableClock(LL_APB2_GRP1_PERIPH_USART1);
LL_GPIO_SetPinMode(GPIOA, LL_GPIO_PIN_9, LL_GPIO_MODE_ALTERNATE); // ***this line should be corrected***
LL_GPIO_SetPinSpeed(GPIOA, LL_GPIO_PIN_9, LL_GPIO_MODE_OUTPUT_50MHz);
LL_USART_SetTransferDirection(USART1, LL_USART_DIRECTION_TX);
LL_USART_ConfigCharacter(USART1, LL_USART_DATAWIDTH_8B, LL_USART_PARITY_NONE, LL_USART_STOPBITS_1);
LL_USART_SetBaudRate (USART1, 8000000, 9600);
LL_USART_Enable(USART1);
}
I need to set pin mode to "LL_GPIO_MODE_ALTERNATE_PUSH_PULL" but the library dosn't provide
it. Can anyone correct me?
I think you should use LL_GPIO_SetPinOutputType(GPIO_TypeDef *GPIOx, uint32_t PinMask, uint32_t OutputType) function.
Which allows You to set output type of pin as :
LL_GPIO_OUTPUT_PUSHPULL
LL_GPIO_OUTPUT_OPENDRAIN
I am highly recommend You to search this kind of information in - UM1850, where You can find a lot of information, for e.g. there is a information about above function on page 807.
Related
I will start a project which needs a QSPI protocol. The component I will use is a 16-bit ADC which supports QSPI with all combinations of clock phase and polarity. Unfortunately, I couldn't find a source on the internet that points to QSPI on STM32, which works with other components rather than Flash memories. Now, my question: Can I use STM32's QSPI protocol to communicate with other devices that support QSPI? Or is it just configured to be used for memories?
The ADC component I want to use is: ADS9224R (16-bit, 3MSPS)
Here is the image of the datasheet that illustrates this device supports the full QSPI protocol.
Many thanks
page 33 of the datasheet
The STM32 QSPI can work in several modes. The Memory Mapped mode is specifically designed for memories. The Indirect mode however can be used for any peripheral. In this mode you can specify the format of the commands that are exchanged: presence of an instruction, of an adress, of data, etc...
See register QUADSPI_CCR.
QUADSPI supports indirect mode, where for each data transaction you manually specify command, number of bytes in address part, number of data bytes, number of lines used for each part of the communication and so on. Don't know whether HAL supports all of that, it would probably be more efficient to work directly with QUADSPI registers - there are simply too many levers and controls you need to set up, and if the library is missing something, things may not work as you want, and QUADSPI is pretty unpleasant to debug. Luckily, after initial setup, you probably won't need to change very much in its settings.
In fact, some time ago, when I was learning QUADSPI, I wrote my own indirect read/write for QUADSPI flash. Purely a demo program for myself. With a bit of tweaking it shouldn't be hard to adapt it. From my personal experience, QUADSPI is a little hard at first, I spent a pair of weeks debugging it with logic analyzer until I got it to work. Or maybe it was due to my general inexperience.
Below you can find one of my functions, which can be used after initial setup of QUADSPI. Other communication functions are around the same length. You only need to set some settings in a few registers. Be careful with the order of your register manipulations - there is no "start communication" flag/bit/command. Communication starts automatically when you set some parameters in specific registers. This is explicitly stated in the reference manual, QUADSPI section, which was the only documentation I used to write my code. There is surprisingly limited information on QUADSPI available on the Internet, even less with registers.
Here is a piece from my basic example code on registers:
void QSPI_readMemoryBytesQuad(uint32_t address, uint32_t length, uint8_t destination[]) {
while (QUADSPI->SR & QUADSPI_SR_BUSY); //Make sure no operation is going on
QUADSPI->FCR = QUADSPI_FCR_CTOF | QUADSPI_FCR_CSMF | QUADSPI_FCR_CTCF | QUADSPI_FCR_CTEF; // clear all flags
QUADSPI->DLR = length - 1U; //Set number of bytes to read
QUADSPI->CR = (QUADSPI->CR & ~(QUADSPI_CR_FTHRES)) | (0x00 << QUADSPI_CR_FTHRES_Pos); //Set FIFO threshold to 1
/*
* Set communication configuration register
* Functional mode: Indirect read
* Data mode: 4 Lines
* Instruction mode: 4 Lines
* Address mode: 4 Lines
* Address size: 24 Bits
* Dummy cycles: 6 Cycles
* Instruction: Quad Output Fast Read
*
* Set 24-bit Address
*
*/
QUADSPI->CCR =
(QSPI_FMODE_INDIRECT_READ << QUADSPI_CCR_FMODE_Pos) |
(QIO_QUAD << QUADSPI_CCR_DMODE_Pos) |
(QIO_QUAD << QUADSPI_CCR_IMODE_Pos) |
(QIO_QUAD << QUADSPI_CCR_ADMODE_Pos) |
(QSPI_ADSIZE_24 << QUADSPI_CCR_ADSIZE_Pos) |
(0x06 << QUADSPI_CCR_DCYC_Pos) |
(MT25QL128ABA1EW9_COMMAND_QUAD_OUTPUT_FAST_READ << QUADSPI_CCR_INSTRUCTION_Pos);
QUADSPI->AR = (0xFFFFFF) & address;
/* ---------- Communication Starts Automatically ----------*/
while (QUADSPI->SR & QUADSPI_SR_BUSY) {
if (QUADSPI->SR & QUADSPI_SR_FTF) {
*destination = *((uint8_t*) &(QUADSPI->DR)); //Read a byte from data register, byte access
destination++;
}
}
QUADSPI->FCR = QUADSPI_FCR_CTOF | QUADSPI_FCR_CSMF | QUADSPI_FCR_CTCF | QUADSPI_FCR_CTEF; //Clear flags
}
It is a little crude, but it may be a good starting point for you, and it's well-tested and definitely works. You can find all my functions here (GitHub). Combine it with reading the QUADSPI section of the reference manual, and you should start to get a grasp of how to make it work.
Your job will be to determine what kind of commands and in what format you need to send to your QSPI slave device. That information is available in the device's datasheet. Make sure you send command and address and every other part on the correct number of QUADSPI lines. For example, sometimes you need to have command on 1 line and data on all 4, all in the same transaction. Make sure you set dummy cycles, if they are required for some operation. Pay special attention at how you read data that you receive via QUADSPI. You can read it in 32-bit words at once (if incoming data is a whole number of 32-bit words). In my case - in the function provided here - I read it by individual bytes, hence such a scary looking *destination = *((uint8_t*) &(QUADSPI->DR));, where I take an address of the data register, cast it to pointer to uint8_t and dereference it. Otherwise, if you read DR just as QUADSPI->DR, your MCU reads 32-bit word for every byte that arrives, and QUADSPI goes crazy and hangs and shows various errors and triggers FIFO threshold flags and stuff. Just be mindful of how you read that register.
Movesense allows to set up waking up from a heartbeat via /Component/MAX3000x/WakeUp. But I couldn't find what uint8 values are available and what they mean. I've found only 1 used in some examples to "prepare AFE to wake-up mode."
Are there any other valid values? If so, what do they mean?
0 = disabled
1 = wake on studs (ULP_LON in datasheet) enabled
No other values are available
Full disclaimer: I work for the Movesense team
For those looking for other ways to wake up the sensor, you can also use the LSM6DS3 to trigger wake-up on movement. Put it to sleep with the following code:
#include "component_lsm6ds3/resources.h"
...
// Prepare wake-up mode
WB_RES::WakeUpState wakeupState;
/* Example sensitivity levels (pick one or adjust yourself) */
wakeupState.level = 1; // Triggers when simply picked up
wakeupState.level = 50; // Triggers with forceful movement
wakeupState.state = 1; // Value for Movement
asyncPut(WB_RES::LOCAL::COMPONENT_LSM6DS3_WAKEUP(),
AsyncRequestOptions::ForceAsync, wakeupState);
// Make PUT request to enter power off mode
asyncPut(WB_RES::LOCAL::SYSTEM_MODE(), AsyncRequestOptions::ForceAsync,
WB_RES::SystemModeValues::FULLPOWEROFF);`
This example can be found in the documentation for movement_wakeup and the example project by the same name.
I am working with STM32H743, and I want to use Pin no. 89 as DAC output. Is there any register setting where I can change PA4 to PG4(89).
I tried replacing PA4 to PG4 in a working example code, but the output still comes on PA4.
I don't know which STM32F7 you are using exactly so I could not lock at the Reference Manual, but I guess it is the same as on STM32F4 devices:
The answer is quite simple:
NO, you could not reroute the DAC pins.
(A look ad a randomly chosen F7 datasheet also shows only one pin for the DACs)
I simply guess it is not possible to route the output signal through a multiplexer without generating to much interference.
According to the H753 datasheet (can't find a specific one for H743), there are two DAC channels, PA4 is DAC1_OUT1 and PA5 is DAC1_OUT2. It does not appear to be changeable.
I want to read/write from external flash (Winbond W25Q16BV) with STM32 micro (stm32F030F4). but running process halt on 'HAL_SPI_Init()' function.
I checked the debug process, and found HAL_SPI_STATE_BUSY.
but i don't know why?
I am using STM32CubeMX to generate main project and Keil IDE to write and debug.
SPI_HandleTypeDef hspi1;
void SystemClock_Config(void);
static void MX_GPIO_Init(void);
static void MX_SPI1_Init(void);
uint8_t spiData[2];
int main(void)
{
HAL_Init();
SystemClock_Config();
MX_GPIO_Init();
MX_SPI1_Init();
MX_FATFS_Init();
SPI_HandleTypeDef my_hspi;
HAL_SPI_Init(&my_hspi);
HAL_FLASH_Unlock();
HAL_GPIO_WritePin(GPIOA,GPIO_PIN_1,GPIO_PIN_SET); // CS to HIGH
HAL_Delay(10);
//Read data
HAL_GPIO_WritePin(GPIOA,GPIO_PIN_1,GPIO_PIN_RESET); // CS to low
spiData[0]=0x05;
//transmit register address
HAL_SPI_Transmit(&my_hspi,spiData,1,10);
//read
HAL_SPI_Receive(&my_hspi,&spiData[1],1,10);
...
Here is our schematic:
Unfortunately, I did not find a good example/instruction of how to use external SPI libraries. Any help in this problem is highly appreciated.
I am not able to comment on the software, but according to your comment you want to enable the reading and writing of the flash.
The Write Protect (/WP) pin can be used to prevent the Status Register from being written.
The /WP pin is active low (GND). (Write disable)
The /WP pin is inactive high (VCC). (Write enable)
Its design only allows reading data.
If you want to read and write data, /WP must be connected to Vcc.
You have not set any parameters for the my_hspi struct so your HAL driver doesn't know what he has to do.
Look at the definition of the struct. There are a lot of comments what the different struct elements are used for. For initialization the my_hspi.init part will be most interesting.
Also you have to the the my_hspi.Instance to the desired SPI Channel.
You can generate an example configuration using the free STM32 Cube Mx Software.
Question:
I'm trying to find a way to retrieve the dev object for an mdio_bus that has been added to the device tree. I'm sure I'm going to be rapidly applying my palm to my forehead when I get past this, but for the life of me, I can't find the answer anywhere. I've seen how to find objects on the bus itself using bus_find_device_by_name(), but I can't seem to find how to get the bus itself.
Background:
We are providing network access to our host using a Micrel KSZ8863 Ethernet switch attached to the MACB on an at919g20. Rather than using the fixed PHY option, I've spoofed MDIO address 0 to be a "fake" PHY representing the fixed MII link to the switch. I'm writing a driver for the switch to receive its interrupts and monitor the outward facing PHYs and control the link state of the "fake" PHY to the host. In order to configure the switch beyond basic MIIM configuration, you need to use SMI on the MDIO bus to access the full array of registers in the switch. Through further tweaking of the mii_read/write functions in the MACB, adding a header to the reg address, I believe I can use the MACB's MDIO/MII controller to do the right thing for SMI requests. Because the bus no longer gets addressed by PHY:REG, I need to be able to issue raw read/write commands straight to the bus from the switch driver. And that brings me back to my question: How do I request the dev object of the mdio_bus from the device tree by name?
Thanks,
Brian
After hunting around, fruitlessly, for a way to retrieve a device pointer to an mii_bus object, I ended up coming up with the following solution. I'm not sure its the best way to go about it, but it seems pretty clean. I basically ended up adding a helper function to mdio_bus.c that allows another driver to search for a bus by name using class_find_device(). I'm sure there is better way to do this, that doesn't involve adding onto the bus' driver, but it doesn't seem like the worst way either.
-Brian
Here are the functions I added to mdio_bus.c:
/**
* mdiobus_match_name - compares specified string to the device name
* #dev: device object to be examined
* #data: pointer to string to compare device name to
*
* Description: matching function used in call to class_find_device() to find
* a device with the specified name
*/
static int mdiobus_match_name( struct device * dev, void * data )
{
const char * name = data;
return sysfs_streq( name, dev_name( dev ) );
}
/**
* mdiobus_find_by_name - Convenience function for retrieving an mii_bus pointer
* by name
* #name: name of the bus being searched for
*/
struct mii_bus * mdiobus_find_by_name( char * name )
{
struct device * dev;
/* search devices registered for with the mdio_bus_class using the device
name as the matching criteria */
dev = class_find_device( &mdio_bus_class,
NULL,
(void *)name,
mdiobus_match_name );
/* return the mii_bus pointer or NULL if none was found */
return dev ? container_of( dev, struct mii_bus, dev ) : NULL;
}
EXPORT_SYMBOL( mdiobus_find_by_name );