Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Type mismatch error in STM32Hardware.h #42

Open
tianyuZ opened this issue Sep 23, 2022 · 7 comments
Open

Type mismatch error in STM32Hardware.h #42

tianyuZ opened this issue Sep 23, 2022 · 7 comments

Comments

@tianyuZ
Copy link

tianyuZ commented Sep 23, 2022

HAL_UART_Transmit_DMA(huart, &(tbuf), twind);

Type mismatch,should be modified to HAL_UART_Transmit_DMA(huart, tbuf, twind);

@tianyuZ
Copy link
Author

tianyuZ commented Sep 23, 2022

After looking at it in detail,The second half of message in case of tx bufferoverflow will not be transferred to the serial port through DMA because the first part of the buffer has not been transferred, so the previous logic is correct.

@jaykorea
Copy link

jaykorea commented Sep 28, 2022

Hello, I've read your reply about that problem...

That problem came to me and It occurs compile error..

Can I fix the line to this

HAL_UART_Transmit_DMA(huart, tbuf, twind);

?? Waiting for your reply, thanks

@maxi-naeher
Copy link
Contributor

After looking at it in detail,The second half of message in case of tx bufferoverflow will not be transferred to the serial port through DMA because the first part of the buffer has not been transferred, so the previous logic is correct.

What do you mean with previous logic?
I suggested the second DMA transfer because of this problem -> #40

@jaykorea
Copy link

jaykorea commented Sep 28, 2022

After looking at it in detail,The second half of message in case of tx bufferoverflow will not be transferred to the serial port through DMA because the first part of the buffer has not been transferred, so the previous logic is correct.

What do you mean with previous logic?

I suggested the second DMA transfer because of this problem -> #40

Thanks for your information.
Simply I have a issue that I cannot compile that line.(mentioned on issue #43)
Compile error occurs in stm32f466re board, Firmware version 1.24.2

@maxi-naeher
Copy link
Contributor

maxi-naeher commented Sep 29, 2022

After looking at it in detail,The second half of message in case of tx bufferoverflow will not be transferred to the serial port through DMA because the first part of the buffer has not been transferred, so the previous logic is correct.

What do you mean with previous logic?
I suggested the second DMA transfer because of this problem -> #40

Thanks for your information. Simply I have a issue that I cannot compile that line.(mentioned on issue #43) Compile error occurs in stm32f466re board, Firmware version 1.24.2

Since @tianyuZ discovered a problem with the DMA transfer logic, you probably should checkout rosserial_stm32 from this commit:
0d1c48b

@tianyuZ
Copy link
Author

tianyuZ commented Nov 7, 2022

Hello, I've read your reply about that problem...

That problem came to me and It occurs compile error..

Can I fix the line to this

HAL_UART_Transmit_DMA(huart, tbuf, twind);

?? Waiting for your reply, thanks

Sorry, just saw your comment now, your fix is correct.

@tianyuZ
Copy link
Author

tianyuZ commented Nov 8, 2022

After looking at it in detail,The second half of message in case of tx bufferoverflow will not be transferred to the serial port through DMA because the first part of the buffer has not been transferred, so the previous logic is correct.

What do you mean with previous logic? I suggested the second DMA transfer because of this problem -> #40

When the DMA transfer is completed, it will enter the interrupt and finally call the HAL_UART_TxCpltCallback callback function to transfer the remaining data again, so there is no need to immediately send out the second half of the message in the front of the tx buffer after a buffer overflow occured.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants