• 2016.02.10: Manuvr Update!

    J. Ian Lindsay02/11/2016 at 06:29 0 comments

    We've had a busy January. The entire Manuvr team is now in the San Francisco Bay area. Josh and I are now working full-time on Manuvr and related technologies for a major telecom company that will likely be the first deployment-at-scale, and who has agreed to keep their efforts open-source, and developer friendly. That will warrant a separate in-depth post once they clear us to release details.

    We're very excited about our prospects of unifying some of the fractured landscape of standards, transports, protocols, and hardware; something the IoT realm sorely needs.


    For my part, I've been hard at work debugging threading Manuvr's firmware under different threading models and imparting concurrency safety. I've made builds with both FreeRTOS on the Teensy3.1, and pthreads on linux. At present, the pthreads version is much more complete, but once I resolve a few more library congruency mis-matches the two threading models can be coded for against the same API.


    Digitabulum has sat idle for the past few months as time was devoted to ManuvrOS and MHB. But that is changing as-of yesterday. We are back in communication with our fabricator, and they are eager to help us build the digit sensor circuits. The 3rd draft of the hardware has been sent to them for feasibility opinions. Realistically, we are probably 3 months away from having the full sensor package for r1 built, funds permitting.

    The non-circuit hardware tasks have also been advancing in the past few months. Here are some renders of the casing parts...

    ...and the digit mold for the sensor package...

    Major changes are underway. But we are still alive, and the project is still making steady progress. More to come!

  • Digitabulum's PMU

    J. Ian Lindsay11/28/2015 at 23:14 0 comments

    LOTS of time has been spent working on MHB these past few months, and it is about to pay off. In between that, and Digitabulum's CPLD, I've been writing firmware drivers for the power-management unit. Here is a picture of the PMU hooked up to Spatium Gestu's test-bed (the board on the far-left). The board in the middle is the LED driver (ADP8866).

    In this case Spatium Gestu is being used to prototype Digitabulum's hardware in small pieces. Everything checks out a-ok thus far....

  • Spatium Gestu lives

    J. Ian Lindsay06/22/2015 at 10:23 0 comments

    This is the EventManager debug output after running for some minutes capturing data.

    --- bootstrap_completed        yes                 
    --- scheduler present?         yes                    
    -- location of message_defs   0x00011b0c   
    -- Queue depth:               0
    -- Preallocation depth:       7
    -- Total subscriber count:    4
    -- Prealloc starves:          0
    -- events_destroyed:          0
    -- burden_of_being_specific   0
    -- idempotent_blocks          0
    -- Subscribers: (4 total):
             0: Scheduler
             1: StaticHub
             2: I2CAdapter
             3: MGC3130
             Message type:   USER_DEBUG_INPUT
             No arguments.
             Preallocated          yes
             Callback:             StaticHub
             specific_target:      StaticHub
             Argument count (ser): 0
             Bitstream length:     0
             total_events               9687
             total_events_dead          91
             max_queue_depth            7
             total_loops                108361042
             max_idle_loop_time         62
             max_events_p_loop          2
    -- Profiler dump:
            Fraction of prealloc hits: 0.000000
             (      4598)       SENSOR_MGC3130  
             (      4598)      I2C_QUEUE_READY   
             (       281)       GESTURE_NUANCE  
             (        15)     USER_DEBUG_INPUT    
             (         9)   GESTURE_RECOGNIZED  
             (         9)    GESTURE_DISASSERT  
             (         6)     GESTURE_ONE_SHOT  
    CPU use by clock: 0.007633

    GESTURE_RECOGNIZED == GESTURE_DISASSERT ---> Implies state-machine works correctly.

    SENSOR_MGC3130 == I2C_QUEUE_READY ---> Implies augmentations to the i2c system are working.

    This reflects a low over-all system load. This is running on a Teensy3.0 @48MHz. The event system will process a maximum of 2 events before servicing the scheduler (max_events_p_loop), and at that setting, we have a preallocation queue depth that exactly matches our peak system load (max_queue_depth). This is a nice number for the 16k of RAM that we have at hand. It represents a resting memory load of 252 bytes (each event is 32 bytes). Adding the 3 schedules (at 36 bytes each), the resting memory load to handle this level of asynchronicity is (252 + 108) = 360 bytes.

    Plenty of headroom in that little space....