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