MAX326xx: BLE updates, fixed sleep, open-drain LEDs #4398
Conversation
| }; | ||
|
|
||
| /*! WSF handler ID */ | ||
| wsfHandlerId_t maximHandlerId; | ||
| static volatile int reset_complete; | ||
|
|
||
| #ifdef BLE_HCI_UART |
There was a problem hiding this comment.
How does this work with the internal HCI driver ?
Is it possible to map the driver to other pins ?
There was a problem hiding this comment.
Currently there are two Maxim HCI drivers; one for SPI and the other UART. These are separate files and do not require the use of ifdef's. Until something changes the HCI driver initialization is the common point within MaximBLE.cpp and thus needs to know what type of mbed objects are needed to reserve peripherals for HCI use.
The HCI drivers use HAL pin mapping to determine the peripheral instance associated with the given SPI slave select or UART transmit pin. With the peripheral instance the other peripheral pins can be determined programmatically. The other pin arguments represent a single pin that can be used without issue. So yes the pins can be mapped to other pins with the same functionality, although this has not been tested.
| @@ -144,6 +144,10 @@ typedef enum { | |||
| OWM = P4_0, | |||
|
|
|||
| // BTLE Module hardwired | |||
| BT_TX = P0_0, | |||
|
@jessexm Thanks for the PR. Also, we recommend our contributors follow Chris Beam’s seven rules of great commit messages to keep the commit history clear. We find the commit.template feature particularly helpful. To match this format, please change your subject line to the imperative mood. We suggest changing it to: Thanks for your contributions. |
|
Thanks for the feedback. Commit message updated and tabs removed. |
|
@jessexm There is an issue with the HCIDrive on |
|
Nice catch of dual timer usage. MAX32630FTHR HCI updated to use timer peripheral 5. |
|
/morph test |
Result: SUCCESSYour command has finished executing! Here's what you wrote!
OutputAll builds and test passed! |
|
@0xc0170 I'm still running internal tests on this PR so I've removed the ready for merge tag. |
|
@pan- Update? |
|
There is several issues with the serial driver (one of the reason it is not used by the CC2564 BLE driver). Those can be easily solved but I need an answer to that question: #4574 . |
|
I have commented on #4574 and agree that a more detailed specification is a good thing and will help avoid differences in HAL implementations. |
|
@pan- any news on those internal tests? |
|
retest uvisor |
|
@jessexm UART clarification and fix can be done outside this PR, I will open ticket to track those. The Wicentric stack shall signal BLE API when an event is available for processing. It is done in the Beetle port of BLE API:
|
|
I've created a PR which solves some issues of the UART driver (#4696), there might be more. |
|
retest uvisor |
|
This cannot be merged without #4696. We will wait for that to come it first. |
MAX32630FTHR gets BLE, uses timer peripheral 5 for HCI timing libexactLE update for 610,620 Fixup hal_sleep and hal_deepsleep for 620 LEDn outputs now forced to open-drain
|
Per @pan-'s guidance the Wicentric stack has been updated to signal BLE API when an event is available. |
theotherjimmy
changed the title
|
Preceding PR merged. |
|
/morph test |
Result: FAILUREYour command has finished executing! Here's what you wrote!
OutputBuild failed! |
|
/morph test |
Result: FAILUREYour command has finished executing! Here's what you wrote!
OutputExample Build failed! |
|
/morph test |
Result: SUCCESSYour command has finished executing! Here's what you wrote!
OutputAll builds and test passed! |
Adding BLE support to MAX32630FTHR platform. BLE library updated to latest upstream API.
MAX32630FTHR gets BLE
libexactLE update for 610,620
Fixup hal_sleep and hal_deepsleep for 620
LEDn outputs now forced to open-drain
Depends on #4696