Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Posts posted by jpnorair

  1. Yeah, with RF devices you don't just wire-em-up.  Frankly, you don't even go with 2-layer PCB, you really need an internal ground plane (so 4-layer).  The CC13xx has a lot more electrical requirements, as well.  For one thing, there's a DC-DC converter on it that will be radiating a ton of noise if you're not ultra-miniaturizing the component layout (and paying attention to trace design & component selection).  


    Everything is a learning experience.  In this case, I'd say you should try to sell-off as much of your breadboarding kits to some makers, and buy a bunch of launchpads instead.  RF circuit prototyping requires a good soldering iron, a microscope, and a lot of proto boards you can destroy in the name of analog network analysis.  It's not a huge expense once you figure it out, but it's more than makers tend to want to spend.  And at the end of the day, radio waves are invisible and make for a lousy demo!  So it's usually a lot more practical to buy someone else's dev kit.  FWIW, wireless SoC dev kits used to be like $1000.  They would get delivered in a custom case from your local TI (or ST, Semtech, etc) rep!  Now, $80 for 4 launchpads.  INSANELY GREAT.

  2. Hi jpnorair,


    Did you check this ? http://www.ti.com/tool/download/SIMPLELINK-CC13X0-SDK

    I think, you can find some useful information under doc folder. It seems TI will officially support both FreeRTOS and non-RTOS'ers.


    Thanks, it's a decent reference.  FreeRTOS is supported through the "Driver Ports" mechanism.


    I've already implemented the "at" feature for OpenTag which will take care of the ClockP requirements.  The other requirements are Mutex, Semaphore, etc, which are more or less compatible with CMSIS-RTOS interface requirements, so ok there, too.  For Hwi, it's just busy-work.


    Frankly, the TI drivers are high latency and suboptimal, but for now they will do.  It beats trying to implement an asynchronous driver on a tight schedule, for the modules I don't care about so much.

  3. TI-RTOS is such a mess.  The files are different because some people go out of their way to try to hook-up everything in a build interdependently rather than to have some redundancies, and you're suffering because you don't know much about building code.  Sorry about that, but it's not my doing.


    Try looking at the file included in your linker command.


    INCLUDE "ti/platforms/emt13xx//include_gnu/CC1310.lds"


    You need to change the memory areas from 128KB to 64KB.  I'm not going to do this for you, and it might be a journey for you that takes some time to figure out (for the first time).  


    Another option is to replace your 64KB chip with a 128KB chip.  Assuming you know what you're doing and have a hot-air rework kit, that's a 30 minute job, max.  Assuming you don't want to do this, I recommend taking a look at the "memory map" section of the CC1310 Technical Reference Manual to make sure all your sections are declared properly.  Welcome to embedded!

  4. Do a comparison of the two linker files: the one from the Energia distribution and the one from the TI-RTOS distro (I attached this one).


    1. Do quick visual inspection.


    2. Run a diff on the files if they are mostly similar.  Filemerge is on OS X, there are others on Linux and Windows.  You should learn how to use diff in any case.

  5. Answering some of my own questions (for posterity):


    Turns out that all I need to do to port most TI-RTOS drivers to another OS is to provide an interface to five headers.  So that's good news for Energia-MT.


    Here's a link, describing more.  You can see the driver support matrix, but scroll down to the "Driver Ports" section to see the specific method for attacking a port job.  I tip my hat to TI, they did a nice thing, here.

    Drivers: TI-RTOS Full Driver API Reference

  6. Where would I place this linker file?


    On some path that Energia config script finds.  Looks like you can change this path (see below).  Maybe just call it linker-64KB.cmd and toss it in the same directory -- up to you.



  7. What about FreeRTOS?

    What about MicroPython?


    My opinions:


    1. There's a reason FreeRTOS is invisible in IoT -- too slow for networking applications.  API is also cumbersome.  The point of adding an upper-level OS is to make it easier to program applications than it is now.  So "POSIX-like" is an important attribute, or alternatively "Arduino-like."


    2. MicroPython is way too heavy, won't fit on the device.


    Yesterday I took a look at "RIOT."  My first opinion is that the website and marketing are more impressive than the actual product, but I'm giving them a chance to contact me and set it all straight.  I actually hope that it's workable for me.

  8. Energia-MT runs atop TI-RTOS.  It could be made to run atop something else.


    I have two issues with TI-RTOS:


    1. The build environment is such a disaster.  If there were a standard build environment, not so burdened by eclipse, that would help a lot.  As it stands, it is not something that can be distributed in the way I need to distribute (which is open source with licensable closed-source tie-ins).


    2. It's too general purpose.  The number one job I need to do is MAC and network processing.  Some of the MAC is offloaded to the radio core in the CC13xx implementation, but nonetheless I need a certain degree of asynchronous task management, and usage of ISRs, that isn't worth the trouble of TI-RTOS.


    NuttX is easier to integrate than TI-RTOS, since it is organized like a normal project.  But there's a lot of work to port it.


    Another option is "RIOT," which I need to evaluate.


    eLua was a thought.  It would be a more serious thought if someone was already working on it, for CC13xx/CC26xx.


    Forth is something I've used in the past, and it can be added as a bonus nonetheless.  Forth is ideal for doing embedded shells.


    Getting back to TI-RTOS, a lot of the work is already done, but it will be such a headache to manage in the future.  At the moment, it's only good for reference purposes.  Again, if someone knows of a normally organized source distribution, I'd love to know.

  9. Hey folks:


    I've been working on CC13xx for some time now, porting OpenTag and various other new stuff to it.  I'm not using TI-RTOS -- too clunky.  As usual (for those who know me), I've pushed the RF to the limit and it is shaping up to be a formidable LPWAN/LAN option.


    Anyway, I'm trying to decide how I want to enable 3rd party applications.  NuttX is one option, but someone (or I) will need to port that, too.  Energia/MT might be another option -- we'll still need to port that.  I'd be happy to take any information on this topic.  What would be best?


    1. Network processor with another MCU for application FW

    2. NuttX

    3. Energia-MT

    4. Something else

  10. Just for the record, the STM32L4 is preferable to the MSP432 for systems requiring ultra low noise and/or fast wakeup from deep sleep, because it has better low-power performance without the buck converter.  The MSP432 has an integrated buck converter -- so does Atmel's L0+ chip they market the hell out of (it's actually worse than both TI and ST in IoT usage).  MSP432 is better for anything that can tolerate a bit of noise from the buck DC-DC, and which can tolerate 100 us latency from deep sleep (alternatively, you can spend a bit of extra money and clever design time to shield all the I's and C's used by the buck).


    It's an interesting time for low power embedded.  These M4 chips with crazy fast ADCs (MSP432 and STM32L4) can do a certain degree of SDR and FFT jobs on renewable power.  Very cool.

  11. It seems to me like it's in a bit of a no-man's-land, between MCU RTOS options and Linux.  I can't think of what I want to do with it: I'm either doing things for M0/M3, a few rare things for M4 that benefit from floating point (or fast ADCs that typically come with the M4 MCUs), or else I want Linux.  I guess I hold-out hope that there's a roadmap where M7 MCUs get enough RAM & ROM to start running lightweight Linuxes.

  12. NuttX is one of the better MCU RTOS's I've encountered.  It is designed and written by a team of experts, it comes from the private-sector (so they have to keep focused on things that matter), and the support is good.  And it's open source.



    I'd like to port to MSP432.  I would also like to integrate a low-power BIOS into it, because at present the scheduling architecture isn't well-suited to using the ultra-low-power sleep modes on ARM.  This second task, I've already done in large part for OpenTag on STM32L, but integration is never plug-and-play with this stuff.


    Ping me if interested!  I'll set-up a GitHub repo momentarily.  You should have an MSP432 Launchpad, as that will be the target board.  If you've worked on NuttX, even better.

  13. Kapton (polyimide) has high resistance to chemicals, and it can take a lot of heat without melting.  It is sort-of default for copper etched films and things that are exposed to chemicals and/or heat, but imidized plastics are quite pricey.  If you can find polyester/PET/mylar tape, you'll probably get a better deal and, practically, no worse performance.

  14. Good vindication, but I thing you forget something important, I'll use these nodes in outdoor throughout the city and after a while the dust might degrade the performance of the solar panel below the threshold of operation. So I hesitated before going ahead with this option.

    Do a test.  It should be quite easy.  You will want to do the test with the MPPT controller attached. 

  15. Low price solar panel with a variety of output voltage are available now. So, I can either using step-down voltage regulator with 5V solar panel or using boost voltage regulator with 3v. I have no experience about which one is preferred in my case.

    Boost is easier.  At night the panel will be low-voltage.  At dawn it will increase voltage.  If you use a low-voltage solar cell, then you can keep the entire voltage range in the boost regime.  This is easier than buck-boost and more efficient.


    I designed a WSN device using a 1.9V solar cell.  In maximum California-summer sunlight it was 1.8V.  Indoors next to a window it was between 0.4-1.0V depending on the time of day.  With office lighting, it was between 0.2-0.8V.  The point here is that the whole voltage range will be observed during the operation of the device.

  16. I plan to design durable wireless sensor node that long-lasting (many years) without any maintenance, so I prefer to use super capacitor instead of rechargeable battery. There is no problem with storage capacity because the sunlight is available almost all days throughout the year in my country. 

    Let's say you use the BQ25570, you run your Vdd at 2V, and your mean power is 1mW.  This means your charge cycle is about 10 days, with a 70mAh LiPoly pack.  You are charging at <0.5C.  The Li-polys are rated for 10% capacity degradation after 300 charge cycles at 0.5C, which in your case equates to 8 years.  LiPoly cells degrade more rapidly when they are charged or discharged at high amperages, which you are not doing.


    More importantly, you need to worry about heat.  I bet it gets hot in the desert.  Both supercaps and LiPoly cells are sensitive to heat.  You should look into this.

  17. Hi,

    I need to provide my launchpad with solar panel energy harvesting with 500F supercapacitor. 50 - 100 ma charging current is sufficient and the solar panel provides 2.5V.


    input voltage 0.5 - 3 volt

    output voltage 3 volt


    Any suggestion about the voltage regulator to be used?



    If you're committed to the boost converter with MPPT, then a small Li-Ion is a way better storage unit than a supercap is.  There is a sweet-spot around 70mAh, because these are used in a lot of bluetooth headsets and FitBits and things like these.  You can find these on aliexpress for really low prices, but you can use Powerstream if you want a US distributor who has English datasheets.  At least use powerstream for the datasheets.



  18. I'm not sure what it is, apart from the fact that it's an antenna designed to fit into some particular enclosure.  You'll need to attach the little grommet to your board's ground.  If you don't have a proper connector for this, you can just cut it off and solder directly.

  19. Looking at CC2540 as an example, it looks like TI's price guidance is around the $3 mark more or less (at 1ku).

    ZigBee is the real cost-add.  I have some exposure to wireless technology licensing.  Let's just say, $3 is a stratospheric royalty, most of which goes to Freescale/NXP.  And people wonder why [almost] no-one uses ZigBee...

  20. The technical reference manual provides some insight.  There is an 115KB ROM that contains the PHY control and partial MAC for 802.15.4 and BLE.  I suppose on the ZigBee model it contains some additional ZigBee stuff.  BLE and ZigBee aren't free.  They bear a royalty that TI has to pay.  On top of that, TI is charging a premium for the convenience.


    As nice as these chips are, they won't get designed-in to anything until the volume cost is around $3, or lower.  Maybe it is already there.

  • Create New...