• State
  • Locked Locked
  • Replies 20 replies
  • Subscribers 56 subscribers
  • Views 3864 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

RTOS with BLE-Stack

pixbroker
Genius 5820 points
Other Parts Discussed in Thread: BLE-STACK, CC2540, CC2541, CC2640

Can the Ti BLE-Stack be used with a RTOS? Can you please point me to some examples or documentation of how one would use the stack in context of a larger, RTOS infrastructure on a CC2540?

Thanks.

  • 0
    Guru 735685 points
    TI BLE deploys a tiny OS in it but is is not a RTOS. You can refer to osal_xxx related functions.
  • 0 in reply to YiKai Chen
    Genius 5820 points

    Thank you YK. Does this mean the BLE-Stack cannot be used with an RTOS?

  • 0 in reply to pixbroker
    Guru 735685 points

    Do you mean to run RTOS on CC254x? If so, the answer is no.

  • 0
    Guru 22270 points

    Hello pixbroker,

    I wouldn't say that an RTOS cannot be used with the BLE-Stack.  As YiKai mentioned, the BLE OSAL is basically an OS.  It does have to perform certain operations in a specific time frame to maintain a connection and stay compliant with the BLE Standard.  This means that execution of some of you events will be delayed and the smallest resolution it can be is 1ms

    You could implement a RTOS, but it wouldn't be that straightforward and there are no documents or examples to my knowledge to do so.  To get the OSAL to operate as an RTOS, you would have to be able to live with constant loss of connection between BLE Devices.  The OSAL enters into "critical states" where interrupts are disabled.  You would have to circumvent this by allowing your RTOS to supersede the critical state.

    To be honest, unless you are performing something that really shouldn't be done on an 8-bit MCU running a BLE-Stack, you don't need an RTOS.  As long as the input for your interrupt is held for a period greater than the the time it takes to execute the critical state, you will be able to perform your task.  Keep the task executed in the interrupt routine to a few instructions and you ahouldn't have a problem.

    Thanks,

  • 0 in reply to Greenja
    Prodigy 70 points
    The current BLE and OSAL implementations will kill any attempt at a hard real time system. But it depends on what you are doing.

    To get any consistent performance for a sensor system you have to get the peripheral subsystems to work as autonomously as possible from the MCU, and don't try and get lots of real work done in any interrupts, as they will be late and occasionally missed completely anyway.

    Use for example auto rearming DMA and Time PWM subsystems, and implementing a missed data strategy is your best bet.

    So it isn't software like an RTOS you need but a really cleaver approach to use all the great peripherals to do most of what you want without using support code.

    Years ago I implemented Midi Music Keyboard controllers for Roland Japan. OSAL just makes doing the same thing now almost impossible, even though the MCU is much more powerful.
  • 0 in reply to Adrian Bruce
    Guru 22270 points

    Hello Adrian,

    Thanks for the input.  Indeed, the proper implementation of sensor input and utilization of DMA wherever possible should satisfy most requirements that you would use an 8-bit MCU on.  Where you using the CC2540 for the Roland Project?

    As for the OSAL, the good thing about it is that you can turn it off so to speak.  To be more precise, you can use preemption as a way to yield to another scheduling method.  You could also just disable all tasks.  The problem as I had mentioned is that you will lose your current BLE connection.

    If you really wanted to, I suppose you could just rewrite the scheduling and taskEvent process to suit your needs.  The only issue there is that on the CC2540 you don't have access to the 24-bit timer and therefore you would be limited to using a 16-bit timer for your OS. (Unless you somehow get access to the ROM API or decode the library files)

    One trick you can use is to not create an event and have a function (a small one) run in the _ProcessEvent routine.  It will get called everytime this functions runs so you are no longer limited to the 1ms timer Event.  I use this to test if there is data available from the USB so that data can be streamed through the USB.

    There are many ways to get it to work.  It just won't conform to BLE standards anymore.

    Thanks,

  • 0 in reply to Greenja
    Prodigy 70 points
    Hi
    That real-time stuff was done with a lowly 2Mhz 6802 (the Roland A-50 and A-80 units in 1988) and know that I couldn't get the same performance with a CC2541 if you used the TI BLE stack and OSAL today.

    I know where TI was coming from with their OSAL, and the way BLE connections work, but they have added unnecessary hurdles (and even brick walls) in their system implementation for cool real-time stuff.
  • 0 in reply to Adrian Bruce
    Genius 5820 points

    I should have probably been a bit more descriptive with my original post. so i would like to provide some more details:

    we are designing a system that is using BLE only "sometimes", i.e. about 5% of the total uptime of the system. while using BLE, we have no problem using the stack as is, with osal. 

    My question was more geared toward the other (majority) of the time where we would like to use the 2540 just as a plain old 8051 MCU and were wondering how an RTOS could be used for that portion of the runtime. 

    i.e. would it be feasible to "switch on the BLE stack" when we need it and otherwise run on some other code?

    thanks

  • 0 in reply to pixbroker
    Guru 22270 points

    Well in that case, you would want to use the CC2541 which has a proprietary mode.  You can switch between BLE and proprietary and run you RTOS.  

    Thanks,

  • 0 in reply to pixbroker
    TI__Mastermind 29650 points
    Hi pixbroker,

    The new Cortex M3-based CC2640 supports (and requires) TI RTOS as the base for the new BLE stack v2. This should allow you a lot more freedom when it comes to rolling your own tasks independently of the stack.

    Best regards,
    Svend
  • 0 in reply to svendbt
    Genius 5820 points

    Wow, the CC2640 looks great, finally a ARM solution for BLE. When is it available? A quick stock search didn't show anything.

  • 0 in reply to pixbroker
    Guru 735685 points
    You can buy www.ti.com/.../cc2650dk which is dual chip for both BLE and Zigbee.
  • 0 in reply to pixbroker
    TI__Mastermind 29650 points
    The CC2650DK includes 2x SmartRF06EB (with onboard XDS100v3 debugger): store.ti.com/cc2650dk.aspx

    A cheaper options as a dev tool is the new SensorTag and a standalone debugger DevPack though this limits the pin count available. The debugger should be available later this week.

    store.ti.com/cc2650stk.aspx
    www.ti.com/.../cc-devpack-debug

    Regards,
    Svend
  • 0 in reply to svendbt
    Guru 735685 points
    These are good suggestions.
  • 0 in reply to YiKai Chen
    Mastermind 8695 points
    The CC2640 only has 128KB of programmable flash. How will applications, RTOS, and the wireless stack fit in 128KB?

    "The debugger should be available later this week" Will the CC2640 not use the CC debugger?
  • 0 in reply to Peter Borenstein
    TI__Mastermind 29650 points
    Peter,

    Much of the BLE link layer is in ROM as well as most of the generic RTOS modules.

    .:svend
  • 0 in reply to svendbt
    Genius 5820 points
    Thats great news. Can you give an estimate of how much of the 128k we can expect to have available for user application code?
  • 0 in reply to Peter Borenstein
    Guru 735685 points
    CC2640 has ARM cortex-m3 embedded and need to use XDS100V3 for debugger. CC debugger is only for CC254x and CC253x.
  • 0 in reply to svendbt
    Prodigy 90 points

    Svend,

    The link for cc-devpack-debug is not valid. Is the standalone debugger DevPack ready for order?

    Yeao-Nan

  • 0 in reply to yeao-nan hsieh
    Mastermind 8695 points

    Check svendbt's FAQ sticky on the front of this forum:  http://e2e.ti.com/support/wireless_connectivity/f/538/t/404236. The links have moved around a bit.