CS 452/652 Spring 2022 - Lecture 8
May 26, 2022
- train control assignments need velocity information
- preparatory measurements can be taken without full kernel
- start early before the tracks fill up!
- default turnout setting - use trap loops: small (left/right), medium, large
- middle turnouts: do not set to C/C! (can lead to derailment)
- word length 32 bits
- no floating point!
- if necessary, use fixed-point integer instead
- if necessary, use 64-bit 'long long' integers to hold temporary results during computation
- fastest clock: 508 kHz
- 32 bit can represent > 2 hours ⇒ sufficient
- small numbers: 10ms tick
- location, distance
- millimetre granularity sufficient
- longest short path (without reverse): ~10.5m
⇒ 32-bit integer sufficient
- keep in mind: size of train, location of pickup!
- distance in mm; velocity in mm/s
- distance/velocity? fraction of second → scale up / rearrange
- example: travel time in ticks for 10ms ticks
- distance / (velocity / 100)
- (distance / velocity) x 100
- compute: (distance x 100) / velocity
Speed / Velocity
- speed: train setting 0-14
- velocity: actual travel distance per time
- non-linear with speed
- different for different trains
- different for different parts of track?
- changes over time (wear and tear)
- two velocities per speed level 1-13 - previous lower vs. higher
- handle at least 1. and 2. by measuring and storing velocity data
- offline experiments → start now!
- continuous online measurements?
- data import/export?
- assume ~70ms continuous sensor polling loop
- unknown (hopefully constant) measurement error
- train controller box
- signal latency
- variable measurement error: sensor trigger relative to polling loop → 0-70ms
- processing delays? later... (should be small with dedicated measurement program)
- velocity = distance / (stop - start)
- constant error in 'stop' and 'start' cancels out
- maximum variable error: up to 2x 70ms = 140ms (in theory)
- at speed of 0.5m/sec, this corresponds to 7cm
- use averaging (and deviations) to deal with uncertainty
- to be revisited...
- often ad-hoc activity - reflect on it...
- software: model ↔ implementation
- debugging: reconcile model and implementation
- (your) program vs. environment (soft- and hardware)
- what's in a bug?
- error in model?
- incorrect implementation?
- potential problems
- design: your model is incorrect
- coding: your implementation does not realize your model
- interface: your understanding of the environment is incorrect
- internals: there is an unknown bug in the environment (unlikely)
- debugging helps with
- verifying design/interface
- verifying coding/internals
- basic technique: inspect and compare → alert
- debugging strategy
- rule out or confirm problems
- start with most likely problem?
- or start with most easy to rule out?
- debugging fundamentally uses scientific methodology
- build model → gather data → compare
- no amount of experimentation can ever prove a model correct!
- tracing, logging (print)
- checking (assert)
- snapshot inspection
- interactive debugging: breakpoints, single-stepping
- post-mortem (reset keeps most RAM): gdb or custom software
- source or binary instrumentation
- stack backtrace? see 'man backtrace' on Linux
- not available in newlib, you could re-implement...
- execution trace: str pc, <location>