Jump to content

raging

Members
  • Content Count

    4
  • Joined

  • Last visited

About raging

  • Rank
    Noob Class

Contact Methods

  • Website URL
    https://ragingdist.org/

Profile Information

  • Gender
    Male
  • Location
    NC, USA
  • Interests
    Photography. Tennis. Skiing. Raging distribution/NUFR.
  • Github
    https://bitbucket.org/burnwood/raging-release/src/default/
  1. raging

    NUFR Port Complete

    The open-source RTOS called "NUFR" has been ported to the MSP430/MSP430X CPUs. NUFR is a full featured RTOS--not just a simple scheduler. Features: MSP430 and MSP430X 16- and 20-bit models Make system included; all free/open-source tools Prioritized & Preemptive multitasking; Round-Robin multitasking; context switching from interrupt handlers Low-power extensions: tickless OS; special logic for low power mode RNET IPv4/IPv6/UDP stack runs on NUFR Message-based, event-driven Example project for Launchpad board Small RAM footprint: OS itself consumes 600 bytes; example project (2 1/2 tasks) at 1800 bytes Offline development environment included; unit test strategy Uses latest GCC (Somnium, was Red Hat) compiler Includes a few manuals and how-to text files; document how to install GCC compiler, etc. Source code follows best-practice coding standards. Well-documented. Doxygen comments embedded Take it for a test drive! ragingdist.org https://bitbucket.org/burnwood/raging-release/
  2. raging

    NUFR port to MSP430

    The port has been published. Included is a prototype project called "Simple Project", which will run on a Launchpad. Features: o Full-featured RTOS--not just a scheduler. Preemptive multitasking; Round-Robin multitasking; context switch from interrupt handlers. o Both 16- and 20-bit models supported o Port done for latest GCC compiler (Somnium, successor to Red Hat) o Simple make included. Notes for installation of compiler and support packages on Ubuntu 18.04 LTS. Instructions to connect to Launchpad device over GDB. o Low-power strategy in place: Tickless-OS; power savings mode call from Background Task o Small RAM footprint: OS consumes 600 bytes; prototype "Simple Project" has 2 tasks + a background task: 1800 bytes RAM total in 20-bit mode. https://bitbucket.org/burnwood/raging-release
  3. raging

    NUFR port to MSP430

    Been busy on this port. I'll tell you, the 430 does not like hosting RTOS's. Current plans (subject to change) are to do a 16-bit port first, then the 20-bit. Plan is to make a tickless OS, to save battery life. Will stick an LPM call in NUFR's Background (BG) task--user-tweakable--so when the tasks have nothing to do, it gets called seamlessly. Port will compile on linux using latest 430 gcc from TI site. Should be able to port to another compiler. Inline assembler is the biggest delta on another compiler. Bare-minimum bringup/BSP will be supplied, will be easy to tweak or replace with one of your own. Simple app supplied which will have been tested on a LaunchPad kit. RAM consumption numbers from an ARM Cortex M4 project running NUFR. The numbers are divided by "tiny" and "small". On a platform this small, task stack sizes takes 50%+ of the RAM consumption by the OS. o 600 and 1000 bytes of OS overhead for tiny and small respectively o Add to that for each task: task stack size (256-768 bytes, typically) + 44 bytes for the task TCB So the tiny and small came out to 1100 and 3000 bytes, respectively. The tiny has 1 task at 256 bytes; the small has 3 tasks at 512 apiece. What would the RAM values look like on a 430? I'm guessing for 16-bit mode they'd be smaller, since there's a lot of 32-bit pointers used. For the 20-bit mode, don't think it'll be too far off. I'm guessing.
  4. raging

    NUFR port to MSP430

    I created an open-source RTOS called "NUFR" and I'm wanting to port it to the MSP430. So, first I'm advertising NUFR and second I'm soliciting advice for the port. NUFR is a small but nevertheless full-featured RTOS. It is ideal for the 430, that's why I'm porting it there. It already runs on the Cortex M's. Here's some approximate resource consumption numbers on the M3 /M4: - the NUFR kernel and services layers consume around 4-6k of flash. Basically, that's all the features turned on. - RAM consumption: Around 300 bytes of kernel and messaging overhead; Add for each task: TCB of around 50 bytes and task stack. ARM examples ran minimum of 150 bytes up to 500 bytes per task. Lots of variables to consider, mind you. Each semaphore is around 24 bytes. And there's a networking stack (RNET) that runs on NUFR. RNET is UDP over IPv4 or IPv6. Current L2 support is for PPP. ICMP echo requests (pings) supported. NUFR supports two packet buffer management schemes, and can squeeze a networking stack into a small RAM footprint (mind you, there's a tradeoff between RAM consumption and CPU usage, and packet MTU has a large impact on small RAM footprint systems). A key feature of NUFR is that it's mainly event driven (though doesn't have to be). This becomes important on larger codebases on battery-powered systems. NUFR also does its best to stay out of the way. A lot of RTOSs don't do that. NUFR doesn't take ownership of the interrupt vector table or anything like that. You pick your favorite BSP, etc. and NUFR will work with it. NUFR is flexible, adaptable, and as straightforward as possible. It's documented too. https://bitbucket.org/burnwood/raging-release/src/default/ That's my advertisement. Onto the solicitation for advice. I'm looking for recommendations on compilers to support. My plan was to support msg430-gcc. Raging uses all free/open-source tools. But I'm looking to get an easy path on a 430 port, since I only have a few hours of 430 knowledge. What's the best toolchain? Development platform? Is there a software emulation I can run, like QEMU? I'm planning on supporting the 16-bit variant of the 430, is that sufficient for a first pass, and do a 20-bit version later? Which do you think is better to do first, the 16-bit or 20-bit--or can I do both easily? I started the port, some of the 430 files are on Bitbucket. The port code is very early, hopefully there's enough for someone to tie all the pieces together. Anyone want to help out with this? Bernie
×