jpnorair

Members
  • Content count

    717
  • Joined

  • Last visited

  • Days Won

    18

jpnorair last won the day on November 18 2016

jpnorair had the most liked content!

About jpnorair

  • Rank
    Level 3
  • Birthday 07/20/81

Contact Methods

  • Website URL
    http://www.indigresso.com

Profile Information

  • Gender
    Male
  • Location
    NY/SF
  • Interests
    Too many to list
  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. 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. 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. LAUNCHXL_CC1310.build.ldscript=ti/runtime/wiring/cc13xx/linker.cmd
  7. Here is the package of 64KB linker files from the TI-RTOS distro. Give these a try. Most likely you want the .cmd variant. CC13xx-64KB-linker.zip
  8. 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.
  9. I'm not familiar with Energia, but you'll need to change the linker file for the appropriate one, and you can easily change 131072 to 65536. If you don't have the linker file, I can send you one that comes from TI-RTOS. It probably works.
  10. 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.
  11. 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
  12. 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.
  13. 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.
  14. 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. www.nuttx.org 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.
  15. 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.