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
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.