2024-04-12 01:47 AM
Hi everybody,
Actually I start a new project with a ST7567 driver for LCD 128x64.
I have create my project with CubeIDE . CubeIDE generate my code in the main.c like this :
/* Private variables ---------------------------------------------------------*/
RTC_HandleTypeDef hrtc;
SPI_HandleTypeDef hspi1;
/* USER CODE BEGIN PV */
/* USER CODE END PV */
/* Private function prototypes -----------------------------------------------*/
void SystemClock_Config(void);
static void MX_GPIO_Init(void);
static void MX_RTC_Init(void);
static void MX_SPI1_Init(void);
/* USER CODE BEGIN PFP */
/* USER CODE END PFP */
It's ok .
Now to drive my screen I would like to create files like st7567_driver.h and a st7567_driver.c file.
This way I could create my functions relating to the driver in these files. Functions such as "draw pixel", "send command", "send data", etc....
But to communicate with the driver I have to use SPI1 create in my main.c.
So I get an error when I try to use the HAL_SPI_Transmit function in st7567_driver.c
I don't know how to declare to my st7567_driver.c file as I use the SPI1 declare in my main.c
Thank you for your help
Solved! Go to Solution.
2024-04-12 02:39 AM
You need to add
extern SPI_HandleTypeDef hspi1;
in st7567_driver.c
2024-04-12 01:51 AM
"So I get an error when I try to use the HAL_SPI_Transmit function in st7567_driver.c"
Can you show us the error ?
2024-04-12 02:14 AM
Hello,
You need to provide details about the error.
Meanwhile, did you include stm32l0xx_hal.h in st7567_driver.h or st7567_driver.c?
2024-04-12 02:21 AM
@JJoao.1 wrote:I don't know how to declare to my st7567_driver.c file as I use the SPI1 declare in my main.c
Thank you for your help
This is standard C programming stuff - nothing specifically to do with STM32.
Detailed example in this post:
and note this follow-up:
@JJoao.1 wrote:I get an error
As the others have said, we need to know what error you get (and where) in order to help you to solve that error!
If it's a build error, copy & paste the full text of the message from the 'Console' window; post it as for source code.
2024-04-12 02:36 AM
of course,
My code in the st7567_driver.c :
#include <stdint.h>
#include <stdbool.h>
#include <string.h>
#include <errno.h>
#include "st7567_driver.h"
void st7567_write_cmd(uint8_t cmd)
{
HAL_GPIO_WritePin(A0_GPIO_Port, A0_Pin, 0);
HAL_SPI_Transmit(&hspi1, cmd, 1, 10);
}
and the error
../Core/Src/st7567_driver.c: In function 'st7567_write_cmd':
../Core/Src/st7567_driver.c:39:27: error: 'hspi1' undeclared (first use in this function)
39 | HAL_SPI_Transmit(&hspi1, cmd, 1, 10);
| ^~~~~
../Core/Src/st7567_driver.c:39:27: note: each undeclared identifier is reported only once for each function it appears in
../Core/Src/st7567_driver.c:39:34: warning: passing argument 2 of 'HAL_SPI_Transmit' makes pointer from integer without a cast [-Wint-conversion]
39 | HAL_SPI_Transmit(&hspi1, cmd, 1, 10);
2024-04-12 02:39 AM
You need to add
extern SPI_HandleTypeDef hspi1;
in st7567_driver.c
2024-04-12 02:42 AM
And maybe cast the second parameters of HAL_SPI_Transmit to (uint8_t *), or change the prototype of
void st7567_write_cmd(uint8_t cmd)
to
void st7567_write_cmd(uint8_t *cmd)
2024-04-12 02:55 AM
Okay thank you so much. That works !
which is the best solution of the two cast
solution1
void st7567_write_cmd(uint8_t cmd)
{
HAL_GPIO_WritePin(A0_GPIO_Port, A0_Pin, 0);
HAL_SPI_Transmit(&hspi1, (uint8_t*)&cmd, 1, 10);
}
Or solution 2
void st7567_write_cmd(uint8_t * cmd)
{
HAL_GPIO_WritePin(A0_GPIO_Port, A0_Pin, 0);
HAL_SPI_Transmit(&hspi1, cmd, 1, 10);
}
Maybe it's similar ?
2024-04-12 02:59 AM
I would say that two is more readable, make more sense
2024-04-12 02:59 AM - edited 2024-04-12 03:04 AM
@JJoao.1 wrote:Maybe it's similar ?
yes - they both achieve the same end.
The question is really which one is most convenient for you to use in your application. Only you can answer that.
EDIT
There's really no need for the cast here:
void st7567_write_cmd(uint8_t cmd)
{
HAL_GPIO_WritePin(A0_GPIO_Port, A0_Pin, 0);
HAL_SPI_Transmit(&hspi1, (uint8_t*)&cmd, 1, 10);
}
cmd is defined as a uint8_t, therefore &cmd will naturally give a uint8_t* result - no need to cast it.
In fact, I might venture to say that it's best not to cast it - as that could hide future errors; eg, if you later changed the definition of cmd to a uint16_t...