Jump to content
43oh

jpnorair

Members
  • Content Count

    718
  • 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/1981

Contact Methods

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

Profile Information

  • Gender
    Male
  • Location
    NY/SF
  • Interests
    Too many to list

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Have you open sourced this design yet? Yes, I need to put a UART-USB into a diptrace design, and I'm being lazy.
  2. 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.
  3. 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.
  4. 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
  5. 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.
  6. 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
  7. 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
  8. 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
  9. 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'
  10. 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.
  11. 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
  12. 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 an
  13. 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 a
  14. 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.
  15. 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 m
×
×
  • Create New...