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.

Open Source Compiler for CC2540

Other Parts Discussed in Thread: CC2540, CC2541S, CC2541, CC-DEBUGGER, CC2564, CC2430, CC2530, SEGGER, ENERGIA

Hi,

Is there any open source compiler available for CC2540? We have a small project where we would like to use CC2540 but it is not big enough to justify buying the IAR Workbench.

Best Regards,

Niclas

  • Hi,

    I think it's possible to use Keil or even gcc, as long as you won't be using BLE.

    Do a quick search on this subject in the bluetooth forum, I think this topic was

    previously discussed (several times) so you might find more informative answer

  • Hi,

    Problem is that I would need to do BLE.

    Best Regards,

    Niclas

  • You might need another host CPU to host an open source BTLE stack and talk to CC2540 over HCI. Look at btstack.

  • SDCC is the only opensource 80C51 compiler that I am aware of but you will probably have issues with the libraries that are needed for BLE . It is a pity that we are almost forced to buy the IAR compiler. It may be a good compiler but the IDE Editor  is little better than Notepad. REALLY BAD!!!. 

  • Yes, it is not good to be locked in to only one supplier of the development tools. I wonder how difficult it would be for TI to provide libraries for SDCC?

  • this is quite an old issue: http://e2e.ti.com/search/default.aspx#q=2540+compiler&g=90

    it seems that TI has either no interest in community-projects or there are issues with the cc2540 or the libraries which force them to use the IAR...

  • Yes, but if enough people complain maybe something happens. btw, I did reluctantly get the IAR development suite.

  • I'll add my complaint here as well.   I develop on OsX, and being locked into an expensive windows based development tool is painful.  After reluctantly deciding that there aren't viable alternatives, I download the IAR evaluation version to find that they've crippled it so that it won't run on a virtual machine...  ugh.

  • You'd need an IAR license that's locked to a USB dongle to work on a virtual machine, as the IAR support told me when I wanted to set up a Mac based development environment.

  • Thanks for the info, Gabe - IAR responded quickly to my support request and I am now evaluating an older version that still works with Parallels:

    http://supp.iar.com/Download/SW/?item=EW8051-EVAL-810

    I may buy a new machine just for IAR, it doesn't make sense to me, but we can buy a new computer for the price of the dongle.

  • We have the same issue. We can by IAR compilers, if thing work. But we use Mac and compile iPad apps, so why should we by Windows PC's?

    You can not make iPad or iPhone apps on a Windows PC.

    So we can NOT evaluate the CC2540, and thus we keep looking for a new vendor of  BLE devices.

    I believe this is a huge misstake by Texas...

    Support GCC and make examples in a cross platform word!!!!

    Terje

  • An age-old topic.

    An age-old answer - projects and libraries are IAR-designated. Any attempt to recreate stack on your own will be ridiculously tedious.

    And yes, I'm not happy with it either, but that's what we get with CC series.

    Honestly, guys, someone designing anything but a simplest sensor on SoC that uses low-speed MCU for both user application and RF real-time functionality has already gambled :)

     

  • Hi all,

     

    there still is an option to use bootcamp. You only need to buy a copy of Windows then and install ist on your MAC in a dual boot config. There also is an ( not to costly ) way to learn OSX to talk NTFS so you can access Data on the Windows Partition from within Finder ( eases File exchange )

     

    ANYWAY beeing stuck with IAR sucks... much to expansive for what you get...

  • I've got to the bottom of the facts of IAR on Mac, as I only use Mac.

    The demo can only be used with Bootcamp, but not with a virtual machine.

    If you buy a licence that is "locked to the machine" or "licenced by dongle" you CAN run in on a virtual machine.  We use VMWare Fusion, Windows 7 and IAR 8.20 with a dongle.  This works very well on a mac, and happily works with the debugger / programmer.

  •  

    The best open source compiler for our 8051 SoC is SDCC - Small Device C Compiler.
    It works great with banking support now.

    http://sdcc.sourceforge.net/

    LPRF Rocks the World

  • @LPRF - does it work for BLE?

    @this post: its age old question: CPU manufacturers are only that (hardware manufacturers). They make money selling hardware, not support tools. I been writing embedded code for entire my life and sw tools are very primitive (have not moved away from 1980). I do understand that it is somehow costly to software support the many processors TI have; but dont throw software engineers under the bus either.

  • @    I disagree. Apple sells phones, not software. Imagine where iPhone would be without XCode. But hey, we don't need IDE, we need a compiler. Ti sells cc2540 chip without a compiler or some sort of SDK. Very strange business model in my book.

  • @Boris:  Iphone is a system not a processor. Also they only have to worry about one processor at one point. Hence they dont have 50 kinds of processors in production at a time. Also, you missunderstood my gripe about what has been and still the case for processor manufactoring. ie. they dont take software development part of their chip-selling business..

  • Ideally, I hoped myself that we had support for 8051 with our CCS - Code Composer Studio. This is not the case.

    http://en.wikipedia.org/wiki/Code_Composer_Studio

    It is possible to use our BT Smart SoC radio as a network processor (bolt on Bluetooth Smart peripheral), and build the host app using another. You have the existing BT stack effort by Google.

    http://code.google.com/p/btstack/

    Maybe start an open source debate with Freaklabs.....

    www.freaklabs.org

    LPRF Rocks the World

  • So at least we would have SDCC as an usable basis.

    Any chance TI releases a Stack Object that is usable with SDCC? Can`t be to hard if one has the original souce to it :-)

  • It is a good point and feedback. I am not sure if we will build our stack for SDCC.
    It is an interesting topic, and I personally think we should investigate the idea for many reasons

    The support for our 8051 SoC is available with SDCC for other stacks., like IoT.

    LPRF Rocks the World

     

  • I've been following this discussion with great interest. Not trying to defend TI in the case of being locked to one IDE for the 8051-based RF SoC's, but I have a question: Isn't the cost of a software license peanuts compared to the total development cost of an RF product (hardware development, building prototypes, testing, tuning, FCC/CE certification, SW development, marketing etc.)? Yes, I know that it all adds up, but still...

  • The cost of software IDE is a smaller chunk of the development cost in an RF based prototype development, I agree to that.  SDCC support is available for the TI 8051 SoC for possible open source development if anyone is interested, but not with the TI BLE Stack which is bundled with the IAR EW8051 IDE.

    SDCC can be used under Linux, and a JAVA API exists on github for a specific HW module from BlueGiga with CC2540

    http://blog.bluetooth-smart.com/2011/10/05/bluetooth-low-energy-development-kits-2/

    Bluegiga provides a C API for the binary protocol and there is an open-source Java Implementation of it

    https://github.com/SINTEF-9012/bglib
    https://github.com/SINTEF-9012/traale


    LPRF Rocks the World 

        

  • I'd have to disagree with you here.

    My group of friends have the skill sets to design the hardware, build prototypes and test. And I have the SW development skills. So between us we have designed a peripheral that we hope to have prototypes available to show to potential investors for next to nothing (Just lots of our time and effort).

    The major hurdle we have is the cost of IAR. I managed to get the coding done within the 30 day free trial, but if we need modifications making then it's going to be very expensive for us.

  • Darren Jones1 said:

    I'd have to disagree with you here.

    My group of friends have the skill sets to design the hardware, build prototypes and test. And I have the SW development skills. So between us we have designed a peripheral that we hope to have prototypes available to show to potential investors for next to nothing (Just lots of our time and effort).

    The major hurdle we have is the cost of IAR. I managed to get the coding done within the 30 day free trial, but if we need modifications making then it's going to be very expensive for us.

    I second Darren on this.  While I agree that a few thousand dollars plus a windows machine to run it might be a small percentage for some people, it is a frustrating barrier  for creating prototype devices (and doesn't that cover pretty much all of the people using BLE at this point?).

  • Darren,

    Thank you for sharing your thoughts.
    What would be your preferred development environment?

    LPRF Rocks the World  

     

  • I'm afraid I can't answer that sorry. I'm an iPhone developer by day and was thrown in the deep end with our project but learned what I needed to get the job done (probably many more questions to come).

    I don't know what alternatives are available, I just learnt whatever was needed.

    We where really trying to aim for a different chip or module just so we didn't need IAR, however the CC2540 was the most cost effective.

    I think this is why a lot of hobbyist use things like the BlueGiga as the dev costs are cheaper although the modules are too expensive for production.

  •  This is very good feedback.

    Unfortunately, TI only support one of the multiple compilers available,

    8051 Compilers


    LPRF Rocks the World

  • Darren, Where are your team based?

  • How close to Coventry?

  • About 2 hours away. I'm up near Liverpool.

  • I have a spare IAR licence, that I'd be prepared to load you in the right circumstances.

    ben at scammell dot com, drop me a line.

  • Yes you are right for a corporate environment it is peanuts, but it still grates me that we have to pay so much for something that has such a disgustingly poor interface. There are so many better products out there. I curse this product every time I have to open it up, I find it strange that they need a dongle because I can't believe that anyone would willingly pirate this software except to compile in proprietary libraries. Its not only about the cost but what you get for it.

    Secondly and I feel this is more important, it is a huge barrier to entry for engineers who are NOT immediately involved with the product. It is a huge barrier to entry for start-ups where money is extremely tight and time is relatively plentiful. In addition as soon as you start exporting expensive software then every government wants their cut which is based again on cost.

    Thirdly do you think that Apple would have the store that they have now without hobbyists and free tools? Do you think Atmel's AVR would have the market penetration that it does if GCC hadn't rescued us from having to use the IAR compiler, or ARM if one was forced to buy the hideously expensive ARM suite. I personally doubt it. 

    There have been few products in recent years that are as ripe for the consumer market and as easy to innovate on as the BLE solution. I am sure that given the opportunity this product will capture the imagination of thousands of hobbyists and professionals. 

    TI has a chance here to saturate the market... but since I have forked out the sickening amount of money for this please give me some time to get my product to market so that I can get my investment back.

    Just for the record I use licensed Visual Studio Professional 2012 which is well worth its not insubstantial cost. A simply outstanding dev environment, closely followed by Eclipse and the Android suite. The IAR compiler belongs in the 80's with Windows 3.1. Yuch!

  • Thank you for your contribution, Jeremy.

    Do Atmel have an open source BLE stack for AVR + radio core build with gcc? This is new to me.

    As I mentioned earlier, we have a very vibrant open source SDCC community for our IEEE 802.15.4 based 8051 SoC radios with Contiki/6LoWPAN separate stack.

    https://github.com/g-oikonomou/contiki-sensinode/wiki

    However, on a separate note, there is an effort to implement BLE over 6LoWPAN, https://datatracker.ietf.org/doc/draft-ietf-6lowpan-btle/

    Why not started it for BLE and CC254x devices too? Anyway, it is still possible to try build the BlueZ Linux stack with SDCC for CC254x devices, http://www.bluez.org/ 
    Anybody is welcome to try this effort. To my knowledge this is all open, or use the effort started by SINTEF with BlueGiga module, see earlier thread for our kit.

    LPRF Rocks the World

  • Same here Darren.

     

    Im wroking as a pro electronic system designer as my day work but also do a lot of semi open source stuff on my spare time.

    Allmost all of the dicussions in this cummunity are targeting ideas that involve smart phones, more specific apples iPhone and iOS wich really cange the game in many perspectives to what we ( and especially small privat efford teams ) did in the last century. Today beeing small and fabless is very common. Beeing a 3 Person company that has internationally recognized success is a thing or reality. But Why?...

    because Apple got you in the game for only 99$ per year! Hardware whise Apple totally lost it with MfI...

    i tried to get in there for allmost 2 Years... my recomendation... save your time on this...

    And this is the reason why this community is so busy at all... FINALY THERE IS A GREAT WAY TO OVERCOME MFI!

     

    Everybody ho is not afiliated to Sony, Apple, IBM, Samsung, Logitech, Bang & Olofsen, (put your favorit big player here) please raise a hand!

    BLE could be, should be, IS the next big thing. ZigBee 6LowPAN etc.. might not be

    Inovation is driven by small Teams not big old companies...

     

    Thumbs up to all of you.....

  • Hi LPRF Rocks the World...

     

    no, you are right about Atmel & BLE, they are not in that game at all by now. But this has not been the point Jeremy was heading for.

    If you look back like 10+ years Atmel had no noticable buissines in the small embedded controll market. Microchip was ruling the house ( because of there mostly free or inexpensive tools ) Atmel made a genius move by adopting gcc and toping Micorchip in even having a free, full featured C Toolchain.

    Altough 10+ or even only 5+ years ago high end semiconductors simply weren`t availabe for small companies or students or hobbyists, devkits where pay in $K....

    Today i can get my lift of on a C24xx for 99$ ( wihtout a usable Toolchain sadly ) directly at TI`s website ( no distry involved ) wich, for example kills nordics product right now ( it`s a good BLE SOC for sure but try to get your hands on a dev kit or some samples ) same with the BlueCore or Broadcom stuff.

    Right now TI is only a very small step off from really head starting something that might change the way we use & interact with technologie. But many of those ideas are targeting for nieces that big(ger) companies never can and will head for ( but will strenghten the BLE Enviroment for all of us )

    See projects like Pebble ( 10.2 M$ on Kickstarter ) if they would have used a CC25xx instead of tha LPC + BlueCore combo TI would have sold 100K Units already.

    And im quit sure this project never would have been born if Eric would have been forced to pay 3000$ for only a (not too usefull) IDE and a C Compiler ( taht you get for free for allmost 95% of all products )

    I even do not utilize my licenced compilers with the build in IDE ( Keil ect. ) but pulg them into eclipse or Codewarrior and 3000$ for en embedded C Compiler with unkown ( at least to me ) abitilites in means of optimization ( wich most of the time is the only added value of those compilers ) is way of by any means.

  • Thank you Kai. You hit the nail on the head.

    10 years ago I was extremely interested in getting into DSP's esp TI's stuff - had all the thick yellow databooks I could lay my hands on, but the dev kits were so expensive there was no way that I could ever dream of spending that sort of money. I always wondered how you broke the chicken and egg cycle. No-one will hire you if you don't know DSP's but you can't afford a dev kit unless you work for a company that uses DSP's...  Needless to say I became proficient in Atmel devices... Low cost dev kits and cheap (Time + money) compiler GCC toolchain. 

    The CC254x is a really really great product but if someone else comes along with the new low energy ARM-Cortex core mated to a BLE stack / rf-front-end TI will be left out in the cold in a heartbeat. I for one really hope it's TI that brings out an ARM based solution as I don't think ARM based processors are going anywhere soon. 

  • @LPRF regarding Development Enviroment (IDE)

     

    As for my two cents...

     

    since there is a plugin already for SDCC -> http://sourceforge.net/projects/eclipse-sdcc/

     

     i would opt for eclipse ( and many other compilers / platforms / µC Toolchains are also supported so only one IDE for a lot of stuff )

     Is there Debugger support for the CC-Debug with Eclipse allready?

  • Thank you for your contribution Kai.

    Yes, SDCC and Eclipse is a good combination.  I use Eclipse for many of my side projects too. (I also prefer Ultra Edit even if it cost some money)  
    The SDCC debug capabilities are poor for our 8051 devices. I have been using the "cheap" approach with CLI and printf statement.

    Debugging provides some challenges in the open source community for our 8051 SoC.

    A possibility will be to investigate the time with the open source MicroMonitor (boot monitor) by Ed Sutter, http://www.umonfw.com/  with the build in support for his Monitor-Based Debugging, basically debugging the application residing on top of the uMonitor.

    I am not sure if all this will fit with a SDCC compile, and cannot of course compete with our CC Debugger and IAR EW8051 support.

    Some open source options are available, but it requires someone to investigate this as part of an open source effort for CC2540.

    LPRF Rocks the World

     

  • All, 

    Interesting reading, I have one additional comment to the original question. We have a "network processor" version of our BLE chip called the CC2541S, here the BLE stack is preloaded onto a device and some simple source API's needs to be implemented on a "system application processor" of your choosing. So then you will be able to choose say, MSP430 using MSP430-GCC as your apps processor.

    http://www.ti.com/product/cc2541s

    Regards,
    /TA 

  • BLE could be, should be, IS the next big thing. ZigBee 6LowPAN etc.. might not be

     

    Does not have to, IMO. Not with Chipcon startup-based stuff, anyway. I do support idea of having affordable compiler. Christ, I work part-time in small-scale avionics, and my FPGA toolkit is more affordable than a single IAR license (mandatory to produce single-chip CC solutions).

     

    I am afraid the technology itself severely lacks flexibility when it comes to anything but simple "smartphone - sensor" interaction. This is to be expected, considering BLE being targeted exactly at that while taking every effort to conserve power. But the winner will be much more friendly towards isotropic networks. Stuff like Pebble is not exemplary - it is mature and versatile technology that wins. Ethernet and 8b/10b is a testament to that.

  • @Oleg

    without going to much into details "Simple Smartphone - sensor interaction" is a big misconseption of the concept of BLE. While actually most pre defined UUID focus on Sensors and Measurements it is totaly OK to Comunicate anything you like or even work with SIG to get new UUIDs pre defined if usefull. TI allready did show how to do it with SimpleButtonClass and OAD. ( wich is non "Standart" ) or have a look at the 6LowPAN over BLE Projekt LPRF talked about earlier. On Top of GATT you can do anithing you like. Do your own Sub-Protocoll if needed. While BLE does not support Meshing by definition keep in mind that the connetion of Master and Slave doesn`t need to be permanent at all since it is quickly established as well as broken again. a Single Slave might now Hundrets of CLients and quickly connect to one after another if asked to. Or you can change roles...

    Big advantages of BLE: It is Ceap, It is allmost mature ( 1.3V of stack works reasonably reliable as is iOS, Android should get the job done someday soon [ Sadly Google whent for NFC in the first place :-( ]), and it will definitly become a de facto standart with future PC, MAC, Laptop, Notbooks, Tablets, Smartphones....

    At no extra cost for the customer ( wich is not true for any of the other Protocolls )

    I tought the same way after my first quick lock into the BLE stuff. I recomend reading Robert Haydons Book on BLE it is easily worth the money ( more then IAR to stay in topic )

     

    @LPRF

    Wouldn´t be debugging more an issue of Eclipse then SDCC? I´ll spend some time at lunch to invertigate dubugging options....

    A good package of IDE, Debugger, Compiler and Stack is esentiall for success and if we( as Community  and hopefully TI for the Stack and Community support ) invests into this it should be free and good :-)

     

    @TI12012

    this sure is a fallback option but:

    1) No help for a lot of people invetigating BLE that only have very basic EE skills ( connecting some LEDs, sensors, Buttons to a Ready made Module is not to hard ) but have good C Programming skills.

    2) Avaliability? ( i know i can use the non S version meanwhile but there seem to be some differences when it comes to firmware loading to CC2541(S) )

    3) I found the documentation on the Host_test_Mode somewhat lacking, is there a AppNote that focuses on this mode? How do i hock it up to the µC? What is neededt to Initialize it on startup ( not software )

    When will the Boster Pack for Launchpad be avaliable ( i think this would answer 99% of my questions :-) )

     

    Regards to all,

     

    Kai

     

     

  • Kai, 

    My generalization is not about UUIDs (the particularities), but basic principle of having separate roles. Justified in terms of current consumption, for sure. But it also led Chipcon guys to developing, honestly, crude implementation of master-slave coexistence and switching. Not to mention that example project on the issue has nothing to do with quick switching of roles, which is essential for mesh implementation. I fail to see an intended effort to work on this issue, though understand why TI may be more occupied with immediate issues concerning stack. After all, 99% of devices will have fixed roles, and there are viable alternatives for low-power mesh networking. We've had to do it using 2540s, but due to our poor design/planning. It worked in the end, but took disproportionate effort.

     

    a Single Slave might now Hundrets of CLients

    I also fail to see support for hundreds of connections. Do we still take it seriously? 

  • Hi Kai 

    Slightly off topic:

    Please could you give more information on  Robert Haydon's book, e.g. publisher and ISBN if possible. A cursory search on Google and Amazon did not show anything promising aside from a poet and some bluetooth accessories.

    Best regards

    Jeremy

  • I have to second you there. BLE may not rock the world on its own (sorry @LPRF) but due to its flexibility is definitely going to change how the world rocks. On a recent episode of This Week in Tech (TWIT) the panelists were counting the number of sensors on a modern mobile phone, they got up to nine. We are surrounded by gadgets that supply us with low bandwidth but very important data and this is where I see BLE changing the way we interact with devices around us.

    This is perhaps my biggest drive for being so vociferous at TI as I really like what they have done, but the job is only starting.

    What has Bluetooth 2.0 +EDR accomplished really in the years that it has been around? Compared to what the tech is capable of, virtually nothing. You get Bluetooth headsets, car kits and you can send a file with difficulty to another person. Anything with Bluetooth until recently cost a fortune to the point that you could really do without it. If you are buying a mobile phone and you see that it has Bluetooth what is your first impression as to its use? My guess is "Headset or car kit" not file sharing or music streaming or any of the myriads of un-thought of possibilities. NFC has already taken file sharing away from Bluetooth.

    Why is this? For one the barrier to entry for developers is huge. The dev-kits are massively expensive. The protocols are ambiguous and unwieldy and no-one is willingly to speak to you unliess you want to buy a trillion dollars worth of IC's. Nearly all the Bluetooth 2.0 devices I have bought have virtually identical layouts and all have dodgy drivers?

    I for one will be extremely annoyed if BLE goes the way of Beta-max and other "better" technologies that have been sidelined to their lesser cousins because of manufacturers' stubborness to listen to the market. Sony refused to make their tapes longer... VHS won with their 3hr tape.

  • Hi Jeremy,

     

    Ups! I Mixed it up ( was talking / chating about other things at the same time ) its ROBIN HEYDON not Robert Haydon :-).

    Was chating about Space Citizen made by Chris Roberts at the same time as well as some other things so my natually buggy human brain mixed up the name:

    The Title is "Bluetooth Low Energy: The Developer's Handbook" and there is a Paperback as well as a Kindle Edition of it.

    Brain Failed! Request Coffee :-)

  • @LPRF

    i investigated the options for and Eclipse based IDE over the weekend. As there is a somewhat ( but as far as i could learn unsupported ) Plugin for SDCC that could be used as a starting point. However, there is no usable debugging with SDCC + Eclipse ( partly caused by SDCC itself ). Since the primary debuggin tool used with Eclipse CDT is GDB there is a way to get this working. For a lot of JTAG based Debuggers there is openOCD that lings to GBD as Stub for embedded debugging. And since SDCC is based on GCC in the first place pluging it into GDB on the other end via ELF Files sould be doable.

    I might have some people at hand to do this. What we are looking for right now is some In Deep information of the Firmware Internals ( communication ) of the CC-Debugger. While the Design itself seems to be open ( PCB,POM,Shematic can be had on TI´s website ) i did not find a lot of info regarding the inner workings of USB Communication as well as the communication of CC-Debugger <-> Target.

    If anyone his able / willing to help on this we might be able to get state of the art debugging with Eclipse + SDCC for all CC51 Based products. ( And then maybe BLE Stack Objects for SDCC :-) )

     

    Regards,

     

    Kai

     

    P.S. if there is intresst, we might start a new thread about a general Open Souce Toolchain for CC51 products.

    P.S.S anybody with the abilities to do something like this is wellcome to team up.

  • @Kai,

    If we google hard enough.....

    CC Debugger on github
    Program CC Debugger with Arduino

    I am not sure about the SDCC BLE object request.....

    LPRF Rocks the World

  • @Kai

    I have attached a library called CEBAL, which contains the driver and API to control the CC-Debugger from a PC (Windows only, for the moment). Please read the SLA carefully before starting to use the library.

    0020.Setup_Cebal_3.1.7.exe

    The documentation is what it is. Don't expect too much, but you should be able to figure out how it works.