Spatium Gestu

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.

#ManuvrOS

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

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!

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....

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....