PAN1760A firmware stack, BT driver, and RTOS / not options

I'm studying this module for Stand-alone use, and reading trough Toshiba and Panasonic docs, I'm not clear on the following.

The Bluetooth SDK developers Guide (v3.4.1) says the BT stack or driver is RTOS-agnostic, but also stays all Standalone demos use RTOS embedded in the firmware of the ICs.

So my first question is, I'm assuming the embedded firmware image in ROM is fixed, then this means the system always has to use BT stack and user app running on that Proprietary RTOS  - so the bare-metal or OS Less as manual says, that applies to the hosted (external MCU) case only ..?

For the proprietary embedded RTOS, why is the API exposed (as far as I see) seems so limited - the "app" entry point , the c2_task, is this the only app "task" which is allowed on the system?  One cannot add another task through that RTOS API ?

5replies Oldest first
  • Oldest first
  • Newest first
  • Active threads
  • Popular
  • Also, under 3.1.1 Using Bluetooth Driver, there are two stacks pictures - Host and Standalone based.

    What is the gray "Bluetooth Stack"  below the "TOSHIBA Bluetooth Driver"  in the Standalone case ..?

    Is the BT Driver part of the firmware embedded in the chip?

    Like
  • The Bluetooth SDK developers Guide (v3.4.1) says the BT stack or driver is RTOS-agnostic, but also stays all Standalone demos use RTOS embedded in the firmware of the ICs.

    Please use the latest Toshiba Bluetooth SDK for your reference, which as of today is v4.2.2.

    The Toshiba Bluetooth SDK is RTOS-agnostic. This is most visible when used for host-mode configurations. On the host, any RTOS can be used.

    When run in standalone mode, the Toshiba Bluetooth SDK is still RTOS-agnostic, but since Toshiba enforces the use of their own embedded RTOS, this is of little use.

    So my first question is, I'm assuming the embedded firmware image in ROM is fixed, then this means the system always has to use BT stack and user app running on that Proprietary RTOS  - so the bare-metal or OS Less as manual says, that applies to the hosted (external MCU) case only ..?

    That is true, it only applies to a host mode configuration.

    In a standalone configuration you must use the built-in Bluetooth stack and the built-in RTOS.

    In theory you are free to not use the Toshiba Bluetooth SDK. That - in theory - is an add-on. But then you would need to put your application directly on top of the internal Bluetooth stack interface layer, implementing all the nice features of the Bluetooth SDK on your own, ie. re-inventing the wheel.

    For the proprietary embedded RTOS, why is the API exposed (as far as I see) seems so limited - the "app" entry point , the c2_task, is this the only app "task" which is allowed on the system?  One cannot add another task through that RTOS API ?

    That is correct. There is only a single user task and other user tasks are not available and cannot be created.

    Also, under 3.1.1 Using Bluetooth Driver, there are two stacks pictures - Host and Standalone based.

    What is the gray "Bluetooth Stack"  below the "TOSHIBA Bluetooth Driver"  in the Standalone case ..?

    Is the BT Driver part of the firmware embedded in the chip?

    For all our Toshiba-based modules the Bluetooth stack is embedded in the chipset ROM.

    Regardless of whether a host mode or standalone mode configuration is chosen, this Bluetooth stack is accessed using so-called TCU messages.

    To make application development easier, Toshiba provides the Bluetooth SDK ("Toshiba Bluetooth driver" ) which includes the necessary utility code to craft these TCU messages and convenient functions to work on a higher level with the chipset.

    In a host mode configuration the Bluetooth stack in the module is accessed via UART from the host processor. That's why on the left side the lower box is separate and is labeled "Bluetooth LSI" - to indicate that this is a different chipset.

    In a standalone configuration the product code is run on the internal Cortex-M0 processor of the module, along with the Bluetooth stack itself. Because of this, everything is drawn in a single box. Communication needs still be done using TCU messages, but here they are transmitted via internal message queues.

    Like 1
  • The internal RTOS based firmware loads the User-App, and runs it as one of its (RTOS) tasks. (probably c2_task is a call from actual RTOS task..?)

    What about the C library , is it shared - I mean run-time (as both, firmware and app, run from same RAM ) - between the firmware and the app, or your app has to link-in it's own C library?

    Like
  • The internal RTOS based firmware loads the User-App, and runs it as one of its (RTOS) tasks. (probably c2_task is a call from actual RTOS task..?)

    Yes.

    What about the C library , is it shared - I mean run-time (as both, firmware and app, run from same RAM ) - between the firmware and the app, or your app has to link-in it's own C library?

    Only very few common functions are shared. For example, there are OS_Memcpy() and OS_Memset() and maybe some other.

    But in general the application needs to implement everything on it's own.

    Like
  • Michael Hunold  ah ok.

    Thank you

    Like
Like Follow
  • Status Answered
  • 11 mths agoLast active
  • 5Replies
  • 199Views
  • 2 Following