Embedded Systems September 2000 Vol13_10

Issue link:

Contents of this Issue


Page 173 of 229

FIGURE 1 Release V1.4D_02 Filename Added: none Changed: analog.h audcntrl .c audcntrl.h audcurve.c audcurve.h display.h executive.h hardwr_def.h keybrd.h rds_tuner. c rds_tuner.h relay_cntrl. c system.h theft_detrnt.c uart_decod.h Removed: Lword_math.c Lword_math.h 4 4 AUTables AUTables This release has: : Fixed an improper call to EE_CopyBLock that slipped in the Last release RmtKB Loudness AU'lenu 19 17 17 20 22 34 28 25 24 32 32 20 37 8 19 21 20 19 25 29 39 30 28 26 35 34 22 40 10 21 Phone Loudness AUTables AUTables Al..f1enu VoL Phone Loudness AUTables Al..f1enu AUTables RmtKB Phone RmtKB ATCPS ATCPS Phone Phone AUTables Phone Phone Previous Version Current Version Feature ID vided by the SCM tool. If a bug is found and fi xed for the Indiana pro- j ect, and it applies equally to Kentucky and 28 othe r states, the effort of propagating the bug fix is very high when it must be done man- ually as compared to an automatic merge facili ty provided by most SCM tools. One practice th at requires a lot of ATCPS Phone AUTables Changed the key scanning Logic to be active Low Toggle Loudness on button press, instead after 2s hold set/clear LDN enable bit based upon user setting VOL is Last in the audio mode cycle first press of the audio button always brings up BASS menu holding the audio mode button 2s no Longer resets all the audio settings Added volume Limiting at power-on and also an absolute max in EE auto-preset tunes to PS1 when complete, and restores to PSO when canceled fixed preset overwriting when radio was powered-on added VOICE & MUSIC predefined settings for AM band added cell phone mute functionality fixed theft problem that wouldn't allow certain display modes to time-out remapped the audio tables per audio engineer's spec's add a Bass Limiting table as a function of percent volume made the Bass boost/cut DSP filter constant an EE parameter Note: files were merged in the order as they appear in the Feature ID List. ALLan Folz 23 Oct 98 172 SEPTEMBER 2000 Embedded Systems Programming branching, but is we ll wo rth the effo rt is th a t of th e Bran ched Deve lopment Model (BDM) . When using BDM, a branch is created for every development effort. All devel- ope rs have complete freedom for check-in and check-out in their development branches. Once their work is complete, th ey notify the build boss (discussed shortly) that their work is ready fo r merge. The build boss th en merges all the devel- opment branches en masse back to th e mainline for re lease . Often this me rge effo rt takes place in still anothe r branch before it merges into the mainline. This practice is ve ry benefi cial when multiple deve lope rs are making many small changes to the same sets of fil es. BDM also helps in supporting the practice of always having a mainline with a known-good re lease as the latest version. Highbrow SCM • Designate a "build boss" • Make use of change packages • Releases and release notes The build boss is the person respon- sible for all the operational SCM deci- sions. He "owns" the mainli ne and is responsible for any check-ins that occur to it. He ensures that the build and release process is working and all products can be reproduced. Likewise he is re ponsible for creat- ing releases. Should a release fail, it is his responsibil ity to track down the offending fil es, contact tl1e responsi- ble developer (s ), and work out a solu- tion. The build boss enforces th e SCM poli cy, and when developers request to circumvent stated policy,

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems September 2000 Vol13_10