Close

Spatium Gestu lives

A project log for Spatium Gestu

Spatium Gestu (latin: "Space Gesture") is a project demonstrating how to create a Manuvrable with the MGC3130.

j-ian-lindsayJ. Ian Lindsay 06/22/2015 at 10:230 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....

Discussions