-
Notifications
You must be signed in to change notification settings - Fork 3k
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
CYW43XXX: Add generic transport layer #14227
Conversation
@pennam, thank you for your changes. |
@ARMmbed/team-cypress please review |
++i; | ||
} | ||
#if defined(CYW43XXX_UNBUFFERED_UART) | ||
while (uart.writeable() == 0); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't necessarily do the same thing as the HAL counterpart. At least on PSoC devices, uart.writeable() just indicate whether there is space in the serial adapter's FIFO to write a character.
Similarly, putc will block until the character can written to the adapter, but does not wait until it the byte has been sent out over the wire.
I don't know how other MCUs function, but the Mbed HAL documentation for putc doesn't explicitly state that the data will be sent over the wire before it returns:
This is a blocking call, waiting for a peripheral to be available for writing
This is important because deasserting bt_dev_wake before the write to the radio completes can cause communication failures.
The equivalent Mbed HAL-level function to cyhal_uart_is_tx_active
would be serial_tx_active
, but I don't know of any way in current Mbed to access this function from the UnbufferedSerial class.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Am I correct in supposing that it is important to know that all the bytes have been transmitted before calling deassert_bt_dev_wake
?
@kjbracey-arm Is there anything we can do to know when the hardware queue is empty ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Correct. Calling serial_tx_active
should provide that answer; the question is how to access that when all you have is an UnbufferedSerial object.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
serial_tx_active
is only available if async is enabled, unfortunate that this is not always enabled and implemented.
I wonder if using the HAL function in this case, here in this component, would cause the trouble (the requirement would be to have async serial available) ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
on our platform uart FIFO is disabled by default,
mbed-os/targets/TARGET_STM/serial_api.c
Line 633 in 77638f9
#if defined(UART_FIFOMODE_DISABLE) // G0/H7/L4/L5/WB |
uart.writable()
and serial_tx_active
have the same (opposite) meaning, but this is not true for other platforms using the serial hardware FIFO.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just for the purpose of trying i've made some changes to be able to use serial_tx_active
. But something is not working and the application is crashing. I will investigate further on it also running ble integration tests.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just discovered that the problem was me, and serial_tx_active
is working as expected, but i cannot found a way to call serial_tx_active
hal function directly from CyH4TransportDriver
.
Any suggestion to how retrive serial_t *obj
from there is really appreciated.
So with 4c7d7e7 i've made small changes to SerialBase
and UnbufferedUart
to reach serial_tx_active
function if DEVICE_SERIAL_ASYNCH
is defined.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@0xc0170 @kyle-cypress is 4c7d7e7 an acceptable solution ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The changes in the BLE HCI driver look reasonable to me.
As do the changes in the SerialBase and UnbufferedSerial, but @0xc0170 may have stronger opinions there than I do.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@0xc0170 @kyle-cypress is 4c7d7e7 an acceptable solution ?
Please send the extension to SerialBase/UnbufferedSerial via new PR (as it's feature update).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the submission, have you run the integration test on the new platform ?
connectivity/drivers/ble/FEATURE_BLE/COMPONENT_CYW43XXX/CyH4TransportDriver.h
Show resolved
Hide resolved
Hi @pan- if you are referring to mbed-os-bluetooth-integration-testsuite i didn't run them on our platform. I will try to get another hardware to run them and report the results. At the moment we are using BLE functionality through ArduinoCore-mbed and Arduino sketches. In the meanwile i attach test_report.html.zip (Network tests are failing because no connection was available). |
This pull request has automatically been marked as stale because it has had no recent activity. @ARMmbed/mbed-os-maintainers, please complete review of the changes to move the PR forward. Thank you for your contributions. |
What's the status of this pull request? |
@0xc0170 i've just received the hardware to run ble integration tests. If everything works today/tomorrow i will post results. |
@pan- here the results of ble-integration-tests
|
9bec1b8
to
40a3636
Compare
40a3636
to
4c7d7e7
Compare
This pull request has automatically been marked as stale because it has had no recent activity. @pennam, please carry out any necessary work to get the changes merged. Thank you for your contributions. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's keep this as target update and have new active serial via new pull request (feature update)
@ifyall do you have any update on this? Increasing the timeout to 16ms @115200 and to 400us @3000000 should be enough to ensure the 128 byte FIFO worst case. If you agree we can temporary merge this pr with the increased timeout until #14600 gets merged and then substitute the timeout with the sync call. |
@pennam, let's merge this. I want my team to run the tests on our hardware, but we won't get to that until next week at the earliest. Ian |
caaf54d
to
dc4fb8d
Compare
I've dropped this commit ae2d79a from this pr cause it was only related to PORTENTA target. I will open another pr that will add BLE support to PORTENTA using this changes. |
CI started |
Jenkins CI Test : ✔️ SUCCESSBuild Number: 1 | 🔒 Jenkins CI Job | 🌐 Logs & ArtifactsCLICK for Detailed Summary
|
Summary of changes
Aim of this pr is to add a generic transport layer to
COMPONENT_CYW43XXX
using unbuffered uart.CYW43XXX_UNBUFFERED_UART
directive has been added to keep Cypress hal support available.40fd126 Adds then
CYW43XXX
support toPORTENTA_H7
target./cc @facchinm
Impact of changes
COMPONENT_CYW43XXX
Migration actions required
Documentation
Pull request type
Test results
Reviewers